I've thought about this issue, and have concluded that it's rather simple, if you are building your own hardware, and you are willing to be a little bit tricky.
Receiving data too fast from an atmel generally isn't the problem, as I'm assuming your PC can handle incoming data as fast as it can travel; rather, the issue is to throttle pc->atmel to a rate it can handle, as it may be busy writing flash or something. So please consider this approach. Choose the "don't send to me" line you want to use. Connect this to the appropriate output of an edge triggered JK flipflop. These have both Q and Q-not outputs, so you can connect to the pin you need without risk of need for an inverter. Wire the data input of the flipflop to V+ so it always wants to assert "don't send". Now is where we get tricky. Wire the flipflop's clock to incoming data line, and the clear/reset line to one pin on the atmel cpu, so the processor can de-assert the flipflop when it wants. Your atmel system will need to do two things in software. On init, it will have to toggle the clear pin to de-assert the "don't send" signal, just to make sure it's in the permissive state. And whenever it gets around to reading an arriving character, it must also toggle that pin. But the timing is not critical, it can do that whenever it pleases. The tricky bit is connecting the flipflop's clock line to incoming data. Remember that it is an edge triggered flipflop. Whenever a character begins to arrive, the flipflop will see changes on that line, a rising or falling edge, whichever flipflop type you chose, will trigger the flipflop, and it will latch in the permanently asserted "data" bit, which asserts the "don't send any more" signal without any cpu intervention. When the processor gets around to receiving the character, it toggles the clear/reset pin, de-asserting the handshake signal. In this fashion, you, at the cost of a single small, usually 14 pin package, get an automatically asserted outgoing handshake which does not need processor attention to assert, and can be de-asserted whenever the cpu gets around to reading the character. Further, it's quick, because it will assert "don't send" as soon as a character's start bit arrives. Sound good? > Date: Wed, 23 Jul 2014 11:16:14 -0400 > From: Enoch <i...@hotmail.com> > Subject: Re: [Amforth] HW flow control > To: amforth-devel@lists.sourceforge.net > Message-ID: <87bnsgyukh....@hotmail.com> > Content-Type: text/plain; charset=utf-8 > > Hello Paolo, > ... > > As for serial port RTS/CTS handshking, please be advised that such code > exists in amforth-shadow repository <http://tinyurl.com/ldkuouw> and > waiting for some day inclusion into AmForth HQ by its BDFL :-) > > Regards, Enoch. > > > Paolo Garro <paolo.ga...@fastwebnet.it> > writes: > >> Hi Matthias, >> I'm writing a wxpython GUI for AMforth. >> It's a serial terminal capable of upload files and include. >> I'm dealing with timeouts to guest if the micro is ready or busy. >> The echo mechanism is ok but it lacks? >> >> Inviato da Samsung Mobile ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
