Hi David ... > I can of course do > > > > ." abcdefghijklmnopqrstuvwxyz" type > > > and it works fine. Is the interpreter reading the input buffer somewhere > esle?
The last line puzzled me at first. Some more thoughts combined the pieces to a picture: The line wait4key key emit waits for a keystroke, than searches the dictionary for key, executes it, searches for emit and executes it too. Now (!) the interpreter calls refill internally which copies from the input buffer (the one that the serial line fills) into the larger source buffer. The time needed for the above is longer than it needs to overrun the serial buffer. It is 16 bytes in size and is organized as a ring buffer. The refill loop (which continuously polls the input buffer until a CR is received) is fast enough for serial line wire speed, the dictionary search is not. I see 2 ways to circumvent the problem right now and a 3rd with more work to do 1. use a compiled version of the "wait4key key emit" sequence (than your code does work, really) 2. increase the serial line buffer (core/drivers/usart-isr-rx.asm) to catch even the larges piece of data in one run. the 3rd one (using flowcontrol on the serial line) depends on your hardware and requires cooperation from the data sender. Matthias ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
