Saving a variable in between runs.

[colt527]

Hi, since our senior coder has graduated (=/), I will be taking over the programming for team 527. I know a good deal of C Syntax but I have a few questions about what the chip can and can not do.

First Question:
Can I save variables in between runnings of the robot. For example we are using a gyro for the control code and I want to store the PWM values that make the robot go strait after the gyro calculates this. Is there any way to do this? Maby saving them into the memory as a file or something, idk.

I'll have plenty of more questions later! Thx in advance for the help.

[Alan Anderson]

Can I save variables in between runnings of the robot.
Yes, you can.

You need to use the internal EEPROM of the PIC. I found a set of utility functions that claim to make it easy, but they didn't work reliably for me, and I never made the effort to find out why. I eventually "rolled my own" to save a couple of calibration values for position feedback.

Search the forums for "EEPROM" and you'll see what's already been done.

[Max Lobovsky]

There is also another solution for your problem. Place a printf() in your program to output the value of the variable you want to store then hardcore it in and remove the printf(). Unless you are planning to recalculate this value every few runs, or something, this will work for you.

[Rickertsen2]

There are 2 ways to store data permanently:
1.)Flash memory(AKA: program memory)
2.)EEPROM memory

The first is ridiculously complicated and i'm not going to bother to explain it. EEPROM is relatively simple. EEPROM Is a special 1kilobyte region of memory. It cannot be read or written to through conventional methods. There are special procedures for this (detailed in the PIC datasheet). It must be read/written to one byte at a time. You will need to either devise your own file system to keep track of where you put things or be very careful not to put things in the same place. We have written both a library which has basic read buffer/write buffer functions as well as a basic file system. Neither has been been tested yet but their testing is on our agenda of thigns to do this week. Once we are sure they work i would be more than happy to post the code for the basic read/write. I won't post the file system because its rather specific to our robot, but if you need any help I will be more than happy to give it.

The best resources i have found about writing to the EEPROM are the PIC18F8520 datasheet (available from the microchip website. It assumes you are programming in assembly but still VERY helpful) and the following thread:
http://www.chiefdelphi.com/forums/showthread.php?t=22655&

One thing worth mentioning:
*EEPROM can be read from instantaneously but writing takes time.... Enough time that the robot can easily time out if you try to write too much data at a time. The good thing is that this writing can be handled in the background. You can initiate a write and set up an interrupt to be called when writing is finished.

You know what... screw it.. I will post my untested code. I can't guarentee it works( and it probably doesn't), but i will release a version that does soon.
It can be found here: http://geargrinders.pictar.net/EEPROM.zip

I will explain the basics of how to use it:
*during your initialization or sometime before using my EEPROM library, you
must call EEInit.

*add the following to the end of the function InterruptHandlerLow () in user_routines_fast.c:
HandleEEPROMInterrupts();

*include EEPROM.h in any files that use the EEPROM library.

Other than that, I think the methods are pretty self explanatory. If not just let me know and i will explain them. Look in EEPROM.h for a list of them.

[colt527]

Does the EDU bot have the same functionality with using the EEPROM memory?

[Mark McLeod]

Does the EDU bot have the same functionality with using the EEPROM memory?
Yes. The Microchip PIC is the same in both and that's what's providing the functionality.

[Rickertsen2]

There were a few bugs in my original code. If anybody is interested i will post the working version.

[pi_guy578]

Am I mistaken by saying if you initialize a static variable such as static int inBetween and it will store the varaible into the program, instead of the RAM. That is the ANSI C standard AFAIK, I'm not sure if its different on PIC chips... Can someone clarify?

Jake

[colt527]

Am I mistaken by saying if you initialize a static variable such as static int inBetween and it will store the varaible into the program, instead of the RAM. That is the ANSI C standard AFAIK, I'm not sure if its different on PIC chips... Can someone clarify?

Jake

Yes this is all well and good if you variable is not going to change in mid run, then use that same value again in the next rounds. This EEPROM is used for people who need to dynamically change variables and use them at a different time.

I'm using it to store p1_x values that a gyro calculated to make it go strait. Then next time I hit forward on the joystick it would start off with the calculated p1_x value instead of default 127. This (hopefully) will eliminate any beggining turning while the gyro is building up error.

[pi_guy578]

Yes this is all well and good if you variable is not going to change in mid run, then use that same value again in the next rounds. This EEPROM is used for people who need to dynamically change variables and use them at a different time.

I'm using it to store p1_x values that a gyro calculated to make it go strait. Then next time I hit forward on the joystick it would start off with the calculated p1_x value instead of default 127. This (hopefully) will eliminate any beggining turning while the gyro is building up error.

As far as I can tell it would make no difference then b/c the program memory is also an EEPROM (or similar, can't remember) except the storing is auto handled instead of doing it manually using the user EEPROM where you can make errors.

[Mark McLeod]

Am I mistaken by saying if you initialize a static variable such as static int inBetween and it will store the varaible into the program, instead of the RAM. That is the ANSI C standard AFAIK, I'm not sure if its different on PIC chips... Can someone clarify?

JakeThere are three basic types of storage available to you on the PIC.

1) "static int x;" uses RAM or data space just as "int x;" does. You can change the value of x from within your program while it's executing (e.g. "x=y+2;"), but the value only lasts as long as the RC is on. All data is lost or returns to initialized values when the RC is turned off or reset.

2) "rom const int x=10;" uses ROM or program space. You cannot change the value of x from within your program as it's running (the compiler will reject "x=y+2;" as an error). The value at program load is permanent and unchanging, only by downloading a new program can x be modified. I believe this is what you were thinking of.

3) EEPROM requires special read/write commands to access as noted above. The value can be changed from within the program while it's running and the latest value is still there after the RC has been turned off or reset. This retention of a changable value is the reason people go to so much trouble to use the EEPROM r/w commands.

[Fat Alex]

There are 2 ways to store data permanently:
1.)Flash memory(AKA: program memory)
2.)EEPROM memory

The first is ridiculously complicated and i'm not going to bother to explain it.

so... uh, where would i learn how to do that?

[pi_guy578]

"static int x;" uses RAM or data space just as "int x;" does. You can change the value of x from within your program while it's executing (e.g. "x=y+2;"), but the value only lasts as long as the RC is on. All data is lost or returns to initialized values when the RC is turned off or reset.

Whoops, my mistake, a static variable stays initialized between function calls but not neccessarily program runs.

[Rickertsen2]

so... uh, where would i learn how to do that?
Unless you are writing a bootloader(program to allow the pic to program itself without a programmer), i can't really see why it would ever be a good idea to store anything to flash. The only advantage is that it is big... If you need to store alot of data, I would use an external EEPROM..

*Anything you write to flash will be erased if you upload a new program
*It is difficult to both read and write from
*It can cause VERY odd errors if you are not careful (you are writing to the same space as your program is executing from and if you overlap bad things will happen)
*you can only write blocks of 8 bytes at a time
*you can only erase in blocks of 64 bytes at a time
*Flash memory is only rated for 100,000 write/erase cycles. EEPROM is rated for 1,000,000

If you really have your heart set on it, the datasheet will tell you how.


2) "rom const int x=10;" uses ROM or program space. You cannot change the value of x from within your program as it's running (the compiler will reject "x=y+2;" as an error). The value at program load is permanent and unchanging, only by downloading a new program can x be modified.

you CAN write to ROM at runtime but its difficult and i wouldnt' advise it.

[Mark McLeod]

you CAN write to ROM at runtime but its difficult and i wouldnt' advise it.
Yes. I'm guilty of posting the "accepted" techniques rather than what is potentially possible. I've done my experimenting with self-modifying code, but I don't believe it has a place on FIRST robots, so I advise against it as well.
The big issue isn't how to do the physical write, but how to avoid clobbering your code while doing so. Your code changes size and placement in memory every time you modify it. Even if you place the bytes to be modified at the high-end of memory there is no self protect mechanism that will prevent the linker from claiming that space for code on some future date. Just wait until you try executing your variables!:ahh: