Hi Wojtek, Just to inform you that FlashForth buffers the DPs and LATEST in ram during compilation. This lessens the wear on the EEPROM and makes the compilation go faster !
BR Mikael On 11/20/2013 12:31 AM, wzab wrote: > Sorry, I've sent my message from another address, not registered to the > list. Therefore I resend it from the proper one - Wojtek > > On 14.11.2013 19:48, Matthias Trute wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> >>> What's absolutely strange to me, is that definition of single word >>> causes eeprom cells 2 and 3 to be rewritten 8 times (?!). >> I just committed a change that should not write anything >> to the EEPROM if nothing will change. In your example the >> address 2 should not be rewritten over and over again with >> the same number. Its not that well tested however, feedback >> would be very welcome. >> >> >> Matthias > Hi, > > I have checked the last trunk version (r1470), and it seems, that number > of writes to the EEPROM is slightly reduced. > However still the value at address 0x0002 is incremented after any > single word is added to the FLASH. > Only the higher word ad 0x0003 is not written unnecessarily. > Wouldn't it be reasonable to update the whole word at 0x0002,0x0003 only > after the whole compilation of a new word is finished? > > Yet more EEPROM friendly would be the solution (which I shortly > described in the initial post in this thread), where the EE_DP > and EE_FORTHWORDLIST are not located in the EEPROM, but in the RAM. > Of course in this case their correct values should be calculated when > AVR is booted. > It could be done by scanning the FLASH, but in this case the list > of compiled words should be a doubly-linked list (as the begining of the > list only could be stored in the FLASH or EEPROM, and the list should be > traversable in both directions - from the begining, when the FLASH is > scanned after RESET, and from the end, when the word is looked up). > > So decreased wear of the FLASH would come at price of increased FLASH > consumption for each word (additional pointer to the NEXT word should be > added). If this pointer was located at the end of the compiled word, and > value 0xffff denoted the last word, then it could be conveniently > updated when the next word is compiled). > > I don't know is the above idea reasonable at all? ------------------------------------------------------------------------------ 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
