No mechanism for accessing flash memory
dvhdr opened this issue · 11 comments
Left out for simplicity and safety. We need a safe and simple API for this, including code to prevent accidental flash burnout.
How much storage can we safely expose? We need to decide.
Would it be feasible to expose access to any of the EEPROM on the MCU, so that custom apps can store settings when the power is off? or is that the kind of use case you're thinking of for the flash here?
Cheers/Jason
That's exactly it. How much do you want to store? If it could be restricted to a single page of flash with an anti-thrash timer mechanism that would be simplest and safest IMHO.
Aha I didn't realise the chip was without eeprom separate from the flash... Maybe some kind of "filing system" abstraction would be good, maybe where you could save small fixed size data "files" to flash memory, each labelled with some kind of numeric (app defined) "name" rather than an absolute address, so the firmware can move the files around to reduce flash wear, and can perhaps conflate rapid sequences of API writes to the same file so the physical write happens only once.
For most applications I guess only a small amount of space would be needed for settings etc, such as a few 10's of bytes, but if you used small fixed size blocks, an app could use several of them if needed.
It would be good if the "files" can outlive the app that created them, so say I have firmware apps A,B and C I load up A after running C and it would pick up the last settings saved from A. Once space is run out though, old files could be overwritten.
"File name" clashes might be an issue in this approach but maybe some registry in github etc could work
Anyways, just a few ideas :)
I would also appreciate this feature. A single page to store settings would definitely be needed imho. More storage to e.g. store sequences or stuff like that would be very nice, but not that critical.
Any progress made on this? Finally pulling the trigger on an LP pro and some form of memory would be useful, especially as many people seem to be interested in building sequencers. Thanks!
Hi @brendanclarke - sorry for the silence. I'm stuck by that perfect gumption trap of it being risky and non-trivial. So in short - no progress. However, we have a company hackday next week, when I'll get back on it!
@dvhdr Thanks for the reply! Seems like there's lots of enthusiasm on here for something. Looking forward to see what you come up with!
Well, here goes. I pushed the flash-storage branch! It's as simple as could be - a single page (currently, I hope to expand it later) that you can write and read using a very simple interface.
I've given it a pretty good testing, but it's still possible that this could cause problems, so do be careful.
The example app shows you how to use it. Feedback welcome!
Note that this really is as dumb as can be. Different apps written against it will fight for the same user storage area, as @hotchk155 pointed out. The implications of trying to fix this bend my head...
fantastic! Sounds ok to leave it up to developers to write/check some header bytes and include some warning/erase code.
Just wrapped up some LXR features and thought I would get some life back, now this is gonna suck me back in :)
Gonna close this seeing as now we have the flash branch. Will merge that at some point!