Hi Erich, my idea was to stop FTDI (or PC when none usb is used) during critical activities amforth does. Without any special tools like python apps.
So ideally I need to know the points I have to pull CTS of the FTDI high. One is the flashing. The second would be the parsing. And so on. I am sure by this kind of handshake you may eliminate special tools. My goal is 115k baud with any terminal programme. Other issue is to have a small rx buffer implemented. However, the cooperation of experts is required.. Pito ----- PŮVODNÍ ZPRÁVA ----- Od: "Erich Waelde" <ew.fo...@nassur.net> Komu: "Everything around amforth" <amforth-devel@lists.sourceforge.net> Předmět: Re: [Amforth-devel] Serial - CTS - word compilation Datum: 13.8.2010 - 20:48:02 > Hello Pito, > > On 08/13/2010 02:17 PM, pito wrote: > > ... > > > > However, when using Terraterm, HW handshake, no > > delays, no waiting > > > on 'ok', it does not work. The question is > > whether amforth needs to > > > stop receiving after each character in order to > > process it, and - > > > whether there is a input buffer, as the FTDI may > > shoot few bytes > > > (from its buffer)even CTS is pulled high - so > > one need tu pull CTS > > > high before the input buffer is full. > > So it is not so easy as I assumed...Pito. > > Well, the character need to be stored and are > echoed back. > On receiving CRLF amforth will start to parse the > received line > and execute it accordingly. After that a new > prompt is issued. > > This is the reason, why amforth-upload.py waits > for the echoed > character to be received, and after a CRLF waits > for the ok prompt. > This is a handshake of sorts. > > > >... > >> I hope the code is correct.. > >> When upload e.g. the _sieve_ you can see how > >> the > >> >> amforth flashes. > >> Quite surprised - so many flashes to see.. So > >> you > >> >> do not buffer the > >> whole word to be compiled but do flashes line > >> by > >> > If you look into the code, you will find that the > inner workings > of i! will check, whether there are any bits, > which will go from > 0 (zero) to 1 (one). IFF that is the case, the > correspondig block > is copied to a separate area and updated, the > original block is > erased and then rewritten. "block" refers to a > logical chunk of > flash memory. This is as good as it can get in > order to write > into flash, but not loosing too much time by > rewriting every > block every time. > > > Cheers, > Erich > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Amforth-devel mailing list Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
