Saving Settings to the Cortex?

Using robotc is it possible to right code that allow a user to change settings with input from an LCD or anything else and it will remember these settings next time it powers on?

For example, say my team has 2 matches in a row, 1st we are blue the 2nd we are red. The code is blue by default, no problem, we play the match, press the button to switch to red but we forget to switch batteries, so we switch batteries but forget to press the button for red again and we remember as the match is starting to press it, but no problem the robot remembers it’s red this round.

So is this possible?

I think it might be theoretically possible to write such data to the internal flash memory but I don’t think it’s something a non-expert would want to try. Check out the following to see what I mean https://vexforum.com/t/robotc-file-system/25007/1

In the example you give, what would happen if you swapped main batteries without turning off the Cortex? Would the 9 volt backup battery keep the Cortex alive long enough to swap the batteries? I’ve never checked it myself, and I don’t know the answer, but if that’s your actual concern, then maybe try it as an experiment?

I’m not really concerned about the 9 volt battery, we’ve had it connected to the robot awhile without the main battery before we realized the cortex was still running on the 9v battery. The reason I want this isn’t even for autonomous selection (it’s just an example of where it would be useful). It’s for a project that I don’t want to say anything about until I’ve finished it, but I want settings for this project to be stay set even when the cortex is completely powered off. It isn’t even a big deal if it can’t be done (the setting can be changed in the code pretty easily) but it would be nice.

It is possible, I have done it but never got around to releasing the ROBOTC version of the code. Here was the ConVEX version that explains how it worked.

https://vexforum.com/showpost.php?p=337593&postcount=23

I will have a look tomorrow and see if it is in a releasable format for ROBOTC.

in that post you say that a write shouldn’t be preformed while the robot is “running”. What do you mean by that? Because if the robot is powered down how would you write to the flash?

What I meant was avoid writing to the flash during autonomous or driver control periods. Only write to the flash during non-critical periods, for example, in the pre-auton function before the match starts. If I have time today I will release the code and an example.

So I’m positing a link to some code that does what you want, however, I worry that code like this may be a bit advanced for many student programmers. On the surface it’s pretty easy to use, under the hood this is probably some of the most complex ROBOTC code you will see.

I added the new functionality to the code I released last year to access the ROBOTC file system. The new functions allow you to store 32 user bytes in a page of flash at a high memory address. There are really only two functions that you need to use. Include the library at the top of your ROBOTC program.


#include <FlashLib.h>

All the source files will need to be in the same directory as your program as FlashLib.h includes other files.

To read the 32 user bytes, do the following.

// pointer to user parameters
flash_user  *u;
// Read the user parameters
u = FlashUserRead();

The parameters can then be accessed in the “flash_user” structure as follows. The array index should be in the range 0 to 31, to access or store variables larger than one byte you will need to type cast.

int  value1, value2;
value1 = u->data[0];
value2 = u->data[1];

To save the user bytes do the following.

FlashUserWrite( u );

you can check the return value to make sure the write was successful. Only 32 writes per cortex power cycle are allowed, this should be more than enough, most of the time you should only need to do one write.


if( FlashUserWrite( u ) )
    displayLCDString(0, 0, "write ok        ");
else
    displayLCDString(0, 0, "write error     ");

There is a small demo program included that shows how to use the above functions, it is called “flashUserDemo.c”. There is also an updated version on one of my LCD autonomous selection programs that I posted in this thread (the code for demo 2) ROBOTC LCD autonomous selection it’s called lcdAutonDemo_2_1.c

The github repo is here.
https://github.com/jpearman/rcfs

Thanks! I have another question, if I write to flash while the robot is running, would the side effects last until the power is cycled?

Again, by running I mean “driving the robot around” and “using the values returned by the sensors”, things like that.

I thought I explained it pretty well in the post FullMetalMentor linked. As he said, this type of code is probably best used by “experts”, take the time to read that post and the others on the forum relating to non-volatile memory.

When programming (ie. writing to) and erasing the flash interrupts are not serviced. This time will vary from 53uS (for a single word write) to potentially 40mS for a full page erase. You may drop encoder counts, you may corrupt communication to the master processor, with ROBOTC other effects are unknown as I didn’t write the underlying ROBOTC code. Most likely this will not require a power cycle (never has) but there may be boundary cases I don’t know about.

So my advice is write to flash at non-critical times, before the match in the pits, before the match when waiting for it to start, not during autonomous or driver control periods, why would you want to anyway?.

Sorry, your right, I should take more time to read things before I ask question, I’ll try to work on that. I’m not saying I want to to write during those periods, the code I’m
working on where writing to flash would be useful won’t necessarily be used in a competition setting. I’m just trying to decide if I really want/need to write to flash, and i’m leaning towards no. It’s more complicated than I hoped, also the cortex only has 10,000 write cycles. And these settings are not something that would need to be changed often and are not crucial to operation, so forgetting to change something isn’t a big deal. Still, really cool code you wrote!

The write cycle thing is not a huge concern, that an erase/program cycle and happens every time you download new code anyway. My code is setup to only allow 32 writes per power cycle and a single erase, under normal operation, setting autonomous etc. it’s really not a concern.

Ok, thanks for the clarification, I still don’t think I want to use this code write now(see what I did there?).