Increasing available program memory

[DanDon]

Is it possible to increase the amount of memory availavle for your program in any way? Perhaps through the use of a custom circuit?

Thank you in advance,

[miketwalker]

I know several teams (I know WildStang has done this for awhile, and we can see how they've been quite successful) have done this in the past. I would suggest contacting teams like that for more information about how to do the custom circuit boards.

[ConKbot of Doom]

program memory? No. The PIC's use a modified Harvard style data bus, seperate data pipelines for the command and for the data. So you aren't going to extend the program memory no matter how creative you get.

However with creative coding you could use an EEPROM to store data on it. and free up space that way somehow.

Or by memory do you mean ram? If that is it you can get some sram and use that for extra memory.

Or you could offload some of the work to another PIC/µC to minimize what the user processor has to do.

[Mike Betts]

Jon is correct. You can not expand program memory. What 111 and others have done is to add a second processor which has a different amount of program memory.

BTW, IFI has hinted that a new PIC chip might be available with 4X the program memory space (link) and compatible with the RC design. Maybe next year?

Mike

[DanDon]

If I add another processor, will I be able to access data from it? Will I be able to send out pwm outputs (Don't I need a motor controller or an H-bridge)?

Thanks,

[Kevin Sevcik]

The robot rules clearly state that any custom circuits can only interface with the RC and sensors, so you can't connect any speed controllers to the outboard PIC. I believe the typical MO is to interface with the it through the TTL serial port on the robot. You could theoretically pass all the processing off to it by sending it all the data received by the RC and having it do all the work while the RC just does what the outboard tells it.

[DanDon]

So, lets say that I am using the navigation code provided by Kevin watson, I can have the offboard PIC do all the gyro, encoder, and PID calculations, and then pass it all along to the RC? How would I interface through the TTL port?

Thanks,

[ConKbot of Doom]

You would use another PIC with a USART/UART to communicate via asynchronous (no clock signal) serial with the RC. If you are going to get this going for next year, start learning now, it is a lot to learn. Most of the PICs with higher pin counts have a USART module, and a few of the smaller ones do too. If you have good resources, you could use one of the PIC30F's which are the DSPic line of chips. Then you open up a whole new can of worms... Quadrature encoder interface... hardware 17bit X 17bit multiplier... multiple work registers... CAN bus.

Frankly it would be quite feasible to take a 30F and make an 8-bit parallel bus to it with the IO's, and a few more control lines. You could then hook up all your sensors to the 30F, and have the RC send it the OI data, let that do everything, and then send back PWM and relay values to the RC, which outputs them to the victors.

Though 6-weeks is one heck of a short time to do that, let alone build a robot to go with it.


Oh and about IFI's hint at 4x more memory, the current user processor is an 18F8520. That can handle 16k instruction words, and 2KB of ram. If IFI goes to the 18F8720, there is up to 64k instruction words, and 3.75KB of ram.

If you are feeling really lucky, they are pin-compatible, and all you would have to do is change the processor definition in the program, and you might be able to desolder a 8520 and replace it with a 8720. that would give you 4x the memory if you could get it to work, however you would lose your warranty, and for some reason I don't think FIRST would like it. So maybe I was wrong earlier, you could get really creative

[DanDon]

Originally Posted by ConKbot of Doom

You would use another PIC with a USART/UART to communicate via asynchronous (no clock signal) serial with the RC. If you are going to get this going for next year, start learning now, it is a lot to learn. Most of the PICs with higher pin counts have a USART module, and a few of the smaller ones do too. If you have good resources, you could use one of the PIC30F's which are the DSPic line of chips. Then you open up a whole new can of worms... Quadrature encoder interface... hardware 17bit X 17bit multiplier... multiple work registers... CAN bus.

Frankly it would be quite feasible to take a 30F and make an 8-bit parallel bus to it with the IO's, and a few more control lines. You could then hook up all your sensors to the 30F, and have the RC send it the OI data, let that do everything, and then send back PWM and relay values to the RC, which outputs them to the victors.

Though 6-weeks is one heck of a short time to do that, let alone build a robot to go with it.


Oh and about IFI's hint at 4x more memory, the current user processor is an 18F8520. That can handle 16k instruction words, and 2KB of ram. If IFI goes to the 18F8720, there is up to 64k instruction words, and 3.75KB of ram.

If you are feeling really lucky, they are pin-compatible, and all you would have to do is change the processor definition in the program, and you might be able to desolder a 8520 and replace it with a 8720. that would give you 4x the memory if you could get it to work, however you would lose your warranty, and for some reason I don't think FIRST would like it. So maybe I was wrong earlier, you could get really creative

Thanks for the reply Jon. How would I go about implementing an 8-bit parallel bus between a 30F and the RC? And after the bus is set up, how would I go about accessing data from it?

Thanks again,

[Dave Flowerday]

Originally Posted by dhoizner

Thanks for the reply Jon. How would I go about implementing an 8-bit parallel bus between a 30F and the RC? And after the bus is set up, how would I go about accessing data from it?

I'd strongly recommend skipping the parallel bus and just hooking up an external microprocessor using RS232. Use the TLL serial port available on the RC and connect it to a serial interface on whatever processor you're adding. Much, much easier to implement and debug.

[DanDon]

Hi Dave, do you know of any documentation or source code showing and/or explaining how to interface the TTL port with regards to interfacing with another microprocessor?

Thanks,

[ConKbot of Doom]

http://kevin.org/frc/

Kevin has serial port routines, that should get the serial port on the RC working. It doesn't really matter if you use parallel or serial interface, once you get it transparent to you, so that all you do is tell it to send the byte, and it doesnt matter how it gets sent.

A lot of the microcontrollers have onboard serial ports, with hardware control, and some have more than one... as you see with the 18F that is in the RC.

As for the code for the other processor, you have to know what you are going to do with the processor before you worry about that.

[Kevin Watson]

Originally Posted by ConKbot of Doom

If you are feeling really lucky, they are pin-compatible, and all you would have to do is change the processor definition in the program, and you might be able to desolder a 8520 and replace it with a 8720. that would give you 4x the memory if you could get it to work, however you would lose your warranty, and for some reason I don't think FIRST would like it. So maybe I was wrong earlier, you could get really creative

Because the maximum (internal) clock rate of the 18F8720 is 25MHz, you'd have to swap out the crystal/oscillator too.

-Kevin

[Kevin Watson]

Originally Posted by dhoizner

Hi Dave, do you know of any documentation or source code showing and/or explaining how to interface the TTL port with regards to interfacing with another microprocessor?

Thanks,

I'll write some example code that shows how to send packetized data between the FRC-RC and EDU-RC. It'll be a few days before I can get to it.

-Kevin

[DanDon]

Originally Posted by Kevin Watson

I'll write some example code that shows how to send packetized data between the FRC-RC and EDU-RC. It'll be a few days before I can get to it.

-Kevin

Thanks Kevin, I'm looking forward to it. There's no rush (I have till build season to get it working, right?) With regards to your serial port code, would i just load the a modified version of the default code to both microprocessors?

Thanks again,