Dear AmForthers,
I am herewith stepping down from the maintainer role of AmForth. For details, read on. If anyone is interested to take over, get in touch with me. In 2020 I received the logins of amforth.sourceforge.net, basically because I was lucky enough to have met Matthias personally a few times. At that time I had a lot of ideas on how to proceed. And while I managed to create an official release, there are a few obstacles in this path. First and foremost I am facing a health issue. It is subtle, but it seriously limits, what I can do. I still have to make several difficult decisions regarding my daily life. I have started to decrease the number of things on my list by cancelling items. I have to accept the fact, that I'm not in a position any more to advance the AmForth project in a meaningful way. Secondly, AmForth has become complex over time. Matthias added support for three more target platforms (msp430, arm, riscv32). Allthough access to these is easily achievable, I use only avr. And I use it less these days. Thirdly, AmForths tools are depending heavily on python code, a language I consider myself illiterate in. I have written a few small perl scripts around AmForth to serve my needs. I heavily depend on those and on a Makefile. Add the fact, that in 2020 I spent countless hours to port my data acquisition stuff at home from amforth 4.6 to 6.9 and it just did not become stable. To this day I still have no clue, why the thing hangs itself after some time, sometimes hours, sometimes several days. In other words: unusable. Step back: what would I have done, if I didn't know Matthias, and the project would just have become silent? Simplify. Simplify heavily. Very recently I have made a fork of AmForth release 5.0. That version is before support for msp430 was officially added (5.5). That version happens to compile with avra rather than wine/avrasm2.exe. Along the way I found, that avra has seen new releases, which add support for my beloved atmega644p and lots of fixes, which is nice! This removes the dependancy from wine and allows for smaller systems for development. So I have picked up my data acquisition project again with the fork mentioned above. Any Interrupt Service Routines are written in assembly to avoid the thing that I uncovered in 2017, namely a race condition 1 bit wide and 1 instruction cycle long. I pick missing bits and pieces from later releases. I would like to add a few features regarding sensors with different needs. A first experiment has run more than 10^6s (12d) without any failure. So I am moderately optimistic to continue along this simplified path. Thanks to all, who have answered the list, contributed code, ideas, documentation in one form or other. It has been an interesting experience. And should you still care to listen: if you have one or a few more important plans, do not delay them, you might be unable to pursue them later. Happy hacking, and use the Forth! Cheers Erich -- May the Forth be with you ... _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
