From: Matthias T. <mt...@we...> - 2010-10-21 18:41:08
|
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 |