Re: [Amforth-devel] Serial - CTS - word compilation

[pito <pi...@vo...>]

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....@na...>
Komu: "Everything around amforth"
<amf...@li...>
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
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel