Hello [long mail]
> I don't know is the above idea reasonable at all? It is. The current code is not very friendly wrt write operations for both flash and eeprom. And yes, both flash and eeprom do have narrow margins: 100,000 erase cycles for eeprom, 10,000 for flash. You're suspecting something a but? Yes. You fear of a ghost, IMHO. I still use the atmega16 for development on which amforth was born 7 years ago. The chips was (and is) really tortured with reflashes and source code uploads. I did not track the numbers, but I'm sure that they're far beyond the guaranteed cycles. Not bad for a 2€ chip. Your ideas are all good ones. They have only one downside: They need (code) space. Something that really matters (at least to me). In my private repository I've created some branches for delayed operations such as a buffered compile or a buffered value. Another idea is a trim command for marker-like operations. All nice all fine, to some degree. The code is not finished and full of errors (most of the time it even does not compile) so I wont publish it yet. Progress is slow and some ideas need time to grow.. btw: thanks for measuring the eeprom write operations, I wasn't sure that my patch did it right :=) Matthias ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
