[sdiy] Rotary Switch -> illuminated PB w/ multicolor LED?

[sleepy_dog at gmx.de]

grant musictechnologiesgroup.com:
> Well in this application I'm only concerned with a few bits total, but I
> wonder one thing about wear leveling: since changing a single byte means
> erasing a whole page (bank/block whatever you want to call it), don't
> you need to implement multiple pages (banks/blocks) to see a benefit?
> Or, where is the weakness? Writing or erasing?

I used multiple pages, but I also had the requirement of having
different files of different sizes and saved in arbitrary order etc.
If you only store one byte for all your info, I guess it can be simpler.
Depending on your flash layout.
Having something prepared in advance and only needing to erase a little
bit "new", not the whole area designated for storage, can be nice.
There arise different kinds of drawbacks / compromises, depending on the
exact flash architecture of your MCU.
If you have relatively big flash pages, the time when you need to
prepare a new one by erasing, may be noticeable. Especially if it's a
design where no instructions can be fetched during erase/program, the
device may be unresponsive for a noticeable amount of time.
This gets less bad with, say, 256 byte blocks vs. if you only have 64K
blocks.
(on some MCUs you could execute code from RAM instead, but given how
small that usually is vs. flash, ... well, limited scenarios I guess)
Then, there are some of the bigger STM32s I've used with two independent
flash banks, which allow you to program one, while executing code from
the other. That's a lot nicer.
Now that's talking internal flash - I didn start reading the thread
early enough to know whether it's (strictly) about internal MCU flash,
where this is a concern.

"since changing a single byte means erasing a whole page..."

I wouldn't put it that way. A page must have been erased before you can
change a unit of data in it.
Sometimes one can prepare a new page when convenient & the user won't
notice / be disturbed, instead of exactly when you are running out of
fresh flash and the user would very much notice. (all depending on your
particular architecture, and application structure)
On a prepared page, you can *program* every byte individually, so if you
only write 1 byte, and have a 1K page, you can write 1024 times one byte
(if that is the programming unit of your flash. Some have 16bits, some
32, etc)


>
> It's kind of funny now seeing this issue pop up for synths. Back in the
> old days, that battery backed RAM was much more convenient!

And I guess an unpleasant surprise when the battery was dead :D

>
> GB
>
> ------ Original Message ------
> From: "Steve via Synth-diy" <synth-diy at synth-diy.org>
> To: "synth-diy at synth-diy.org" <synth-diy at synth-diy.org>
> Sent: 2/16/2022 12:39:07 PM
> Subject: Re: [sdiy] Rotary Switch -> illuminated PB w/ multicolor LED?
>
>> Flash wear:
>> One can heavily mitigate the problem by implementing a wear leveling
>> algorithm, though.
>> Depending on the concrete hardware & application requirements, one might
>> get away with a pretty simple scheme. I've done that in the past and it
>> worked very well.
>> If you only have very limited flash size, it's of not much help, but if
>> you have, say, 10x the amount you need to save, you can reduce the wear
>> of the flash to 1/10, by spreading it out perfectly evenly.
>>
>>
>> Jay Schwichtenberg via Synth-diy:
>>>   Yes you have to pay attention to the number of writes to flash. I did
>>>   embedded/bare metal work before I retired and there were 2 times I
>>>   wore out the program flash in uCs. These were NXP chips and they were
>>>   probably programmed 10-20 times over 9-12 months.
>>>
>>>   Jay S.
>>>
>>>   On 2/15/2022 10:10 PM, Brian Willoughby wrote:
>>>>   The replies about EEPROM versus Flash are correct. An EEPROM will
>>>>   last through 10 times as many writes as a Flash device. Some of the
>>>>   high capacity devices are actually 1/100 of an EEPROM's duration, but
>>>>   I doubt anyone is putting 16GB of NV memory in a module. The only
>>>>   downside is thet EEPROM memory sizes are much smaller, but that won't
>>>>   affect storage of a 2-bit or 3-bit setting. Many PIC and other micro
>>>>   controllers have both Flash and EEPROM for code and settings,
>>>>   respectively.
>>>>
>>>>   Brian
>>>>   _______________________________________________
>>>>   Synth-diy mailing list
>>>> Synth-diy at synth-diy.org
>>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>>>   Selling or trading? Use marketplace at synth-diy.org
>>
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
>> http://synth-diy.org/mailman/listinfo/synth-diy
>> Selling or trading? Use marketplace at synth-diy.org