On 9/30/23 05:25, Mark Roth wrote:
Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the
way back when) because it had slipped my mind to get back to trying it.
I've gotten so used to using e4thcom that the tool in the repo is just
collecting figurative dust for me. Tristan W brought it up into the python3
realm some time back and I think sorted some bug or another after that.
I get the feeling there are a number of the back in the old days folks
doing the same and glancing at the mailing list. One would hope anyway.
Seeing the dates on the really old commits this past week really drove it
home just how long this project has been around. :)
Thanks! I'm not familiar with e4thcom. It looks interesting.
I'm curious if it also solves the primary reason I had for writing
amforth-shell.py in the first place, which had to do with making higher
baud rates work reliably without overrunning the very small serial input
buffer amforth uses. When using a terminal emulator file transfer that
just sent at maximum baud rate I frequently had problems with this on
ATMega 328 based arduinos if the baud rate was greater than 19200
because amforth would fall behind as it was storing new words.
amforth-shell.py solves this problem by waiting for a positive echo of
the character it sent before sending the next which let me run at 115k
and greatly sped up larger file transfers while ensuring they were
reliable. For my project I had 12+ microcontrollers I had to regularly
reprogram with a fairly large forth program and this was necessary to
keep myself going crazy while waiting during updates. :-)
--- Keith
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
