Menu
▾
▴
amforth-devel
|
From: Wojciech Z. <wz...@is...> - 2013-11-14 10:32:46
|
Investigating the problem of the failed simulation of Amforth in simavr I have added printing of every read and write operation to the FLASH and to the EEPROM. Afterwards I've found, that when I define a very simple word: > : test 12 ; ok > It gives the following sequence of writes in the simavr (I attach the whole dump in gzipped format, together with bzipped .lst file from compilation, so it is possible to identify addresses): AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01 AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73 AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800 AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870 AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ff04 AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff [...] eeprom read 0002 : 87 eeprom read 0003 : 0d eeprom write 0002 <- 88 eeprom write 0003 <- 0d [...] AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01 AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73 AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800 AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870 AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:6574 AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff [...] eeprom read 0002 : 88 eeprom read 0003 : 0d eeprom write 0002 <- 89 eeprom write 0003 <- 0d [...] AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01 AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73 AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800 AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870 AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:7473 AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff [...] eeprom read 0002 : 89 eeprom read 0003 : 0d eeprom write 0002 <- 8a eeprom write 0003 <- 0d [...] AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01 AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73 AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800 AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870 AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:3bb6 AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff [...] eeprom read 0002 : 8a eeprom read 0003 : 0d eeprom write 0002 <- 8b eeprom write 0003 <- 0d [...] AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01 AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73 AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800 AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870 AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:3800 AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff [...] eeprom read 0002 : 8b eeprom read 0003 : 0d eeprom write 0002 <- 8c eeprom write 0003 <- 0d [...] AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01 AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73 AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800 AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870 AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:3837 AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff [...] eeprom read 0002 : 8c eeprom read 0003 : 0d eeprom write 0002 <- 8d eeprom write 0003 <- 0d [...] AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01 AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73 AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800 AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870 AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:000c AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff eeprom read 0002 : 8d eeprom read 0003 : 0d eeprom write 0002 <- 8e eeprom write 0003 <- 0d [...] AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01 AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73 AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800 AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870 AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:381a AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff [...] eeprom read 0002 : 8e eeprom read 0003 : 0d eeprom write 0002 <- 8f eeprom write 0003 <- 0d [...] What's absolutely strange to me, is that definition of single word causes eeprom cells 2 and 3 to be rewritten 8 times (?!). It will result in fast wear of the EEPROM. Maybe the value stored in cells 2 and 3 of the EEPROM shpuld be stored in RAM (and recreated after power up by scanning of the FLASH? It should be relatively easy to do?) Additionally (and this is probably the simavr's bug) when new words are written, the previoulsy written values are again 0xffff. Regards, Wojtek |
|
From: wzab <wz...@is...> - 2013-11-14 18:11:03
|
It seems, that I've found the problem leading to inappropriate simulation of writing to the FLASH. The patch for simavr, allowing to simulate amforth is available here: https://groups.google.com/group/simavr/attach/e2ad4dc5abd1ef4/patch.txt?part=4&authuser=0&view=1 and description here: https://groups.google.com/d/msg/simavr/iuYM6bOf_OY/9B69WtzUKg4J Simavr may be a good tool to analyze efficiency of words. E.g. the problem with multiple writes to EEPROM when defining a new word still remains... -- Regards, Wojtek |
|
From: Matthias T. <mt...@we...> - 2013-11-14 18:49:09
|
-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKFGxYACgkQ9bEHdGEMFjNh1wCgwV+HNi64CRY67HBB/jr9WuNO XQsAoKF0FSCw3XcJQNKwUhHOm7UgQK17 =j5ax -----END PGP SIGNATURE----- |
|
From: wzab <wz...@is...> - 2013-11-19 22:31:59
|
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? -- Regards, Wojtek |
|
From: Matthias T. <mt...@we...> - 2013-11-20 18:49:16
|
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 |
|
From: Mikael N. <mik...@pp...> - 2013-11-20 19:06:47
|
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? |
|
From: Enoch <ix...@ho...> - 2013-11-22 00:53:52
|
Mikael Nordman <mik...@pp...> writes: > 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 Hello Mikael & All: I agree, AmForth should follow suit. The change seems trivial, a simple rewrite of words/dp.asm, etc. I like the recent interest in simavr as a standard devel platform. Can it be used to benchmark, say, AmForth vs. FlashForth? Thanks, Enoch. |
|
From: Enoch <ix...@ho...> - 2013-11-24 18:14:20
|
Dear Matthias,
I understand that Mikael ("FlashForth") represents "the competition" but
his point, in my opinion, cannot be ignored. All those frequently
changing variables from amforth-eprom.inc should not stay just EEPROM
based:
EE_DP: ; Dictionary Pointer
EE_HERE: ; Memory Allocation
EE_EDP: ; EEProm Memory Allocation
I intend to fix that in my amforth-shadow git but I prefer that you
would take the lead.
The solution is simple, XT_DP, XT_HERE and XT_EDP should be RAM
variables that are initialized from the EEPROM on cold start. A new
immediate word, let's say "eesy" (EEPROM sync), would do the RAM to EE
sync. To be on the safe side let tools/amforth-shell.py issue this
"eesy" for us automatically before exit...
Sincerely, Enoch.
Enoch <ix...@ho...> writes:
> Mikael Nordman <mik...@pp...>
> writes:
>
>> 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
>
> Hello Mikael & All:
>
> I agree, AmForth should follow suit.
> The change seems trivial, a simple rewrite of words/dp.asm, etc.
>
> I like the recent interest in simavr as a standard devel platform.
> Can it be used to benchmark, say, AmForth vs. FlashForth?
>
> Thanks, Enoch.
|
|
From: Erich W. <ew....@na...> - 2013-11-24 18:49:51
|
Hi,
On 11/24/2013 07:13 PM, Enoch wrote:
> Dear Matthias,
>
> I understand that Mikael ("FlashForth") represents "the competition" but
> his point, in my opinion, cannot be ignored. All those frequently
> changing variables from amforth-eprom.inc should not stay just EEPROM
> based:
>
> EE_DP: ; Dictionary Pointer
> EE_HERE: ; Memory Allocation
> EE_EDP: ; EEProm Memory Allocation
>
> I intend to fix that in my amforth-shadow git but I prefer that you
> would take the lead.
>
> The solution is simple, XT_DP, XT_HERE and XT_EDP should be RAM
> variables that are initialized from the EEPROM on cold start. A new
> immediate word, let's say "eesy" (EEPROM sync), would do the RAM to EE
> sync. To be on the safe side let tools/amforth-shell.py issue this
> "eesy" for us automatically before exit...
Hmm. If I understand your approach correctly: *I* have to call eesy before
powering down the controller. Otherwise my newly compiled words are lost?
And *frequently* means exactly: every time the compiler is run or , and friends
are called (I use up flash space).
Do I miss something?
I can confirm what Matthias said earlier:
I have a bunch of atmega32 controllers, which I use since I started with avr
controllers 10 years ago. They are thus far not exhibiting any behaviour that would
point to bad eeprom or flash.
Just my 2 cent.
Cheers,
Erich
|
|
From: Matthias T. <mt...@we...> - 2013-11-24 19:23:58
|
Enoch,
> I understand that Mikael ("FlashForth") represents "the competition" but
> his point, in my opinion, cannot be ignored.
I did not ignore his opinion. I was a little surprised that he
uses the amforth mailing list to place an advertisement for his
system, but its ok.
> The solution is simple, XT_DP, XT_HERE and XT_EDP should be RAM
> variables that are initialized from the EEPROM on cold start. A new
> immediate word, let's say "eesy" (EEPROM sync), would do the RAM to EE
> sync. To be on the safe side let tools/amforth-shell.py issue this
> "eesy" for us automatically before exit...
I absolutely dislike a "savesystem" or whatever these words are
called. Regardless of how many systems utilize them in one way or
another. I'm not a mainstream opportunist, see my reluctance to
unified memory models... I'll think about caches but don't expect
a quick solution. Ideally it will be a loadable module, that people
that fear of ghosts may use ;)
IMHO (!!) there is a plethora of things that could be done for the
benefit of both amforth and flashforth. Lowlevel system internals is
not.
Matthias
|
|
From: Mikael N. <mik...@pp...> - 2013-11-24 19:47:35
|
Just as a reference, this is how it works in FF.
The DPs and LATEST is kept in ram during interpretation
of a line and during compilation state.
It also gives a nice undo effect if the compilation fails.
ABORT will restart QUIT and copy the old values from eeprom again.
No half compiled words are left in the dictionary.
: quit
rpempty
[
begin
dp>ram \ copy DPs and LATEST to ram
begin
sp?
tib tibsize accept space interpret state @ 0=
until
dp>eeprom \ copy updated DPs and LATEST to eeprom
." ok"
again ;
BR Mikael
|
|
From: Mikael N. <mik...@pp...> - 2013-11-24 20:52:22
|
On 11/24/2013 09:23 PM, Matthias Trute wrote: > I was a little surprised that he uses the amforth mailing list to > place an advertisement for his system, but its ok. > Matthias I am sorry for that Matthias. I was trying to send the mail directly to Wojtek, but the mail client tricked me and it went to the list. Sorry /Mikael |
|
From: Enoch <ix...@ho...> - 2013-11-24 22:40:31
|
Mikael Nordman <mik...@pp...> writes: > On 11/24/2013 09:23 PM, Matthias Trute wrote: >> I was a little surprised that he uses the amforth mailing list to >> place an advertisement for his system, but its ok. >> Matthias > I am sorry for that Matthias. > I was trying to send the mail directly to Wojtek, but the mail client > tricked me and it went to the list. > > Sorry > /Mikael Hello Mikael, While I am not likely to desert AmForth I like competition of ideas and welcome your input. When disagreeing with Matthias my approach is to apply the patches to my amforth-shadow in the hope that the boss would change his mind :-) Cheers, Enoch. P/S Minimizing the number of EEPROM erase cycles is a worthy cause. |
|
From: Enoch <ix...@ho...> - 2013-11-24 22:55:33
|
Erich Waelde <ew....@na...> writes:
> Hi,
>
> On 11/24/2013 07:13 PM, Enoch wrote:
>> Dear Matthias,
>>
>> I understand that Mikael ("FlashForth") represents "the competition" but
>> his point, in my opinion, cannot be ignored. All those frequently
>> changing variables from amforth-eprom.inc should not stay just EEPROM
>> based:
>>
>> EE_DP: ; Dictionary Pointer
>> EE_HERE: ; Memory Allocation
>> EE_EDP: ; EEProm Memory Allocation
>>
>> I intend to fix that in my amforth-shadow git but I prefer that you
>> would take the lead.
>>
>> The solution is simple, XT_DP, XT_HERE and XT_EDP should be RAM
>> variables that are initialized from the EEPROM on cold start. A new
>> immediate word, let's say "eesy" (EEPROM sync), would do the RAM to EE
>> sync. To be on the safe side let tools/amforth-shell.py issue this
>> "eesy" for us automatically before exit...
>
> Hmm. If I understand your approach correctly: *I* have to call eesy before
> powering down the controller. Otherwise my newly compiled words are lost?
> And *frequently* means exactly: every time the compiler is run or , and friends
> are called (I use up flash space).
>
> Do I miss something?
My workflow is probably different than yours. I do programming and
simple word test via amforth-shell.py but leave it often for a full
system test with a connected ANSI terminal emulator. Each time I leave
the shell the EEPROM would get in sync with the RAM.
> I can confirm what Matthias said earlier:
> I have a bunch of atmega32 controllers, which I use since I started with avr
> controllers 10 years ago. They are thus far not exhibiting any behaviour that would
> point to bad eeprom or flash.
>
> Just my 2 cent.
What does it prove... that you are both some very lucky guys ;-)
Cheers, Enoch.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X