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 (http://www.ifirobotics.com/forum/viewtopic.php?p=431#431)) 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?:confused:

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]

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]

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]

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]

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]

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,

[Kevin Watson]

With regards to your serial port code, would i just load the a modified version of the default code to both microprocessors?Yes, you'll need to have a full-duplex serial port driver (like mine) running on each of the processors. Then you'll need to design a state machine that parses the messages as they come in. Here's an example of a very simple packet:

Byte 1: 'P' ; First synchronization byte. I use my younger son's first initial
Byte 2: 'B' ; Second synchronization byte. I use my oldest son's first initial
Byte 3: Command byte ; i.e., 01 = start motor #n, 02 = stop motor #n...
Byte 4: Data needed for command; e.g., motor number
Byte 5: Eight-bit checksum; Least significant eight bits of the summation of bytes 1-4. This is used to make sure the packet isn't corrupted.

-Kevin

[DanDon]

When you write the example code on how to send packetized data between the FRC-RC and EDU-RC can you include an example of how to create a packet such as the one outlined in your last reply (Or any type of packet for that matter)?

Thanks again,

[Kevin Watson]

When you write the example code on how to send packetized data between the FRC-RC and EDU-RC can you include an example of how to create a packet such as the one outlined in your last reply (Or any type of packet for that matter)?

Thanks again,Yes, I intend to.

-Kevin

[DanDon]

Yes, I intend to.

-Kevin

Thank you so much. Have you written (Or know of) any documentation (Or tutorials) on how to use the serial ports on the RC or transmitting and parsing packet data?

Thank you very much,

[DanDon]

Hey Kevin,

Any news on how its going with the example interface code between the EDU-RC and the FRC-RC?

Thanks,

[Mike Betts]

Dan,

Reading over your posts in this thread, it looks like you have never programmed a serial link before... It is not really so hard.

A simple Google search will yield thousands of hits. The issue is digging through them until you find a simple example...

Start by reading the sections "Typical Protocols" and "Serial Client & Server Example Programs" at this link (http://www.htservices.com/Tools/VBandC/SerialCommunications.htm). Personally, I prefer the full or "complete" packet with a checksum after the ETX for data integrity.

Now look at the specification and code for the CMU2cam we used this year. You will see that it is a very simple protocol. For example SV 1 200r is a command from one CPU to another to move servo #1 to position 200. Also, you have the default code which implements 1/2 of the protocol definition.

Just as the CMU definition is specific to the requirements of the camera, your definition will be specific to your requirements. The biggest job that you have to do is to sit down and write the interface definition. After that, the coding is cake...

You do not need to wait for Mr. Watson to do this for you. And as always, you can post here if you have more questions.

Regards,

Mike

[Kevin Watson]

Hey Kevin,

Any news on how its going with the example interface code between the EDU-RC and the FRC-RC?

Thanks,I'm working on something that I'll be releasing in the future. In the meantime, have a look at the attached code that I wrote for IFI's breaker panel. The code parses the incoming telemetry and updates global variables with the state of individual breakers. I should point out that there is a weakness in IFI's telemetry packet in that they don't include somthing like a checksum at the end of the packet, which could be used to validate the data within the packet. The attached code makes the assumption that once the two synchronization bytes are received, the next four data bytes are valid. A better solution (left to the student :) ) would be to update the system variables after the data has been received *and* the next two bytes are validated as synchronization bytes.

-Kevin