Re: [Amforth-devel] amforth application development cycle

[Matthias T. <mt...@we...>]

Hi,

First: I do development on my desk, not in the forest
or beneth the roof. Whenever I'm satisfied with a new
version, I copy the flash/eeprom content from the
working controller to hex files (avrdude can do reads 
as well as writes) and transfer those files to the final 
target systems (one by one, just in case).

> - try out wording at the amforth prompt.

This and with the help of marker which can reset the
controller state. 

> - transfer changes to a dictionary file.

I do my terminal work with minicom (a linux
application), it saves everything to a logfile, which
can be edited afterwards. For smaller test cases even 
a cut/paste from the terminal window to the editor 
window works well (X11 is much better then Windows ;=) )

Finally all code go into a code repository which tracks
any changes (subversion and recently git).

I do use the appl/... directories, the published
files are a small subset of my internal file system,
stripped down for simplicity. core/ is almost identical, 
lib/ as well.

Whenever I need some library code, I use the python scripts
for uploading them and do a backup to hexfiles afterwards.
These hex files can be used to re-flash the customized
setup easily. But marker does basically the same is is 
faster.

> - flash the device with the standard image.

as mentioned above: marker does its job (well, most of
the time). Therefore I reflash the controller only if
I make changes to the core system. Currently I'm playing
more with the core system and this leads to frequent re-flashing
of the controllers. With a proper programmer this is done
within a minute, or faster. Uploading the libs afterwards
takes more time. (the hayes test for core needs approx 400 
seconds to complete, a good coffee break).

Whenever I work on applications, the amforth core is almost never
re-flashed. Maybe, I circumvent all pitfalls..

HTH
Matthias