Thanks for your efforts. On Fri, May 6, 2022, 3:37 PM Erich Wälde <ew.fo...@nassur.net> wrote:
> > 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 > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
