|Anonymous | Login | Signup for a new account||2017-03-24 06:14 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000027||Firmware||Flash Burning||public||2008-11-02 18:53||2014-03-31 00:58|
|Target Version||Future||Fixed in Version|
|Summary||0000027: Create EEPROM Write Functions|
|Description||It would be nice if we had access to the EEPROM for recording stuff while running, a sort of rolling datalog even.|
These should be written in C with the usual GPL header file format etc.
I would imagine this would be a lot easier than the flash stuff due to being pure C and not having to sod around with memory management etc.
The following should be available :
* write word (this is the raw unit of eeprom)
* write byte (wrapper for write word that reads one byte out first and puts it and the new one back)
* write block (takes care of the misalignment without complaining and can write any size of block inside the EEPROM area)
We need to take care of the EPAGE register, perhaps internally or perhaps externally, I'm not sure which makes sense as I haven't read the docs thoroughly.
|Tags||No tags attached.|
|Risk of Breakage||low|
|Dealing with EEPROM firmware upgrade related issues on another project. We need to think about a upgrade path strategy. For tunes it'll be handled externally to the device, however eeprom will very likely be handled onboard for various reasons. One strategy is a flat structure that is only ever added to the end of, and if things are pulled out of the middle, they're padded back in. This still raises the question of what to do when a field is updated. I suspect the best approach is to carry code in each version that knows how to upgrade from the previous one such that there can be a daisy chained upgrade path without excessive version-handling code on board at all times.|
|Copyright © 2000 - 2011 MantisBT Group|