Is there any mechanism to save state data on the vesc?
I was thinking about the gyro bias compensation, and i though it would be better to save the calculated offsets so the next boot resumes from where they were rather than 0, as those are (i think, in many scenarios) more likely to be accurate.
Looking at the code the only thing i saw was writing settings and that stops the motor and apps and etc. Which wont work for values that are updated frequently.
I was also thinking this could be used to track the lifetime mileage of a vehicle as well, not sure what else it would be useful for. Changing some app settings or maybe even motor settings while riding could be cool too, but its not required for these cans of worms to be buy get one free.
You are here
Save state data on vesc?
Thu, 2020-04-09 06:44
#1
Save state data on vesc?
It's something Ben and I have discussed regarding the lifetime mileage before. In the interest of saving Ben's time this is what he responded when I asked something similar:
"A persistent odometer would be nice to have. I though about adding a EEPROM for that, but it might be possible to utilize flash. Currently all sectors are used, but it would be possible to move the application down two sectors and only use three 128 kb sectors. That requires changing the bootloader though. That would leave one 16 kb sector and one 64 kb sector unused.
The thing that wears out the flash and takes a long time is erasing sectors, which sets all bits to 1. Writing to flash is relatively fast and does not wear it out. Flash can always be written, but if it is not erased the bits can only be turned from 1 to 0, and not 0 to 1. This is what the eeprom emulation takes advantage of; it keeps track of where in the sector a variable was last written and writes to the next empty place. It only erases when the sector is full, which is when it swaps sectors. I think the odometer can do something similar with one sector, which allows checking and updating it relatively often without wearing out flash and causing a long delay. As the odometer never will be 0xFFFFFFFF, it is possible to just go backwards in the sector until the last written value of it is found, and writing it to the next empty location when storing it. Then the write can be done independent of the power switch, as soon as the input voltage drop below some threshold. When the sector is almost full, it could be erased at the next boot. So the logic would be:
At boot:
* Read the last odometer value. If the whole sector is OxFF (e.g. on a new STM32), initialize it to 0.
* If the sector is almost full, erase it and write the last odometer back.
At power down (voltage drops below some value):
* Write odometer to last empty place in flash. As an erase is not required, this should be really fast."
Jeff
Thanks for the info, tho after doing more debugging I think im pretty convinced that the auto comp for the IMU is actually causing problems, currently im using a manually calibrated one and while not perfect it has held fairly well for 2 days.
So instead I'm going to work on a wizard that'll run in the vesc tool, set your rotation and acc/gyro offsets automatically. Running this out in the field every now again doesn't seem that painful.
Another thought i had was that if everyone used the power button, we could just modify settings during runtime and save them on a power down. If you loose power then you'll loose some data, but I think that's reasonable. It's going to be some time before power switches are standard tho, but perhaps thats an easier future.
There should be plenty of time when you see voltage line falling to store the data without advanced notice.
Jeff
Can we use the function conf_general_store_eeprom_var_custom to save the odometer value at shutdown? It seems like the EEPROM emulation described by Jfriesen exists in eeprom.c.
Writes: Firefly blog