One way under Linux I have gotten around the issues of software flow control is to use screen for my serial terminal sessions. It has software flow control support built in. A must if you want to use ssh or another app that doesn't play well with stty.
Brian On Fri, Sep 23, 2022, 5:59 AM Brian White <b.kenyo...@gmail.com> wrote: > I don't believe this is enough to ensure clean data. I must have a dozen > real ftdi adapters from different manufacturers and I keep having to > increase the per-byte sleep in dlplus' bootstrapper and tsend.ps1 and > PDDuino as I discover new basic programs to feed in. > > Some programs will ingest fine at 5ms/byte, some will fail on some > particular part of one line, always the same spot, unless the sleep is > increased to 6ms. > > Then I discover some other code that fails at 6 but succeeds at 7. > > Some of the problem code I just found in the M100SIG, some were new things > like the REX setup utils, some I created the new problem by refactoring > existing tpdd client loaders to make them smaller. This made them > apparently more difficult to ingest, but they are still legal correct > BASIC, so any procedure needs to be able to handle the worst case or else > it's no good. > > For an example, one of the loaders I re-worked, used to work fine before, > and then the reworked version would always be missing a : in the middle of > one long line of code. Always the same byte missing. And it didn't cause > the transfer to fail immediately, it tokenized on the fly without apparent > error. But the program was broken and didn't work when you try to run it. > > This is all with real ftdi adapters and with xon/off enabled on both ends. > > It may work at 1200 or something where the low baud rate does the same job > as a sleep between bytes, but no way at 19200. > > I will put together a few test cases that expose the problem. And if this > method does somehow work then that would indeed be pretty interesting and > good to know. > > I believe all the right chip does is help, and make more code more likely > to make it through, but not actually guarantee it. It probably does make a > large improvement, and you can probably show numerous examples of data that > fails on one adapter and succeeds on an ftdi chip. > > -- > bkw > > On Thu, Sep 22, 2022, 8:57 PM John R. Hogerhuis <jho...@pobox.com> wrote: > >> >> >> On Thu, Sep 22, 2022 at 5:32 PM B 9 <hacke...@gmail.com> wrote: >> >>> >>> Of particular note for troubleshooting is that, if some of the data gets >>> transferred, but it is garbled or you get a ?DS ERROR, then the problem >>> is that your PC's serial port does not support "ON CHIP SOFTWARE FLOW >>> CONTROL". One solution is to buy a serial card or USB cable with an FTDI >>> chip in it. (Other companies make ICs that support on chip software flow >>> control, I even have a cheap Prolific 2303 device that does, but FTDI is >>> the only company I know of whose chips are supposed to always work. ) >>> >>> >> I've never heard of this on-chip software flow control.All I knew was >> that software flow does not work under Linux. My experience is software >> flow control with a Model T *does* work on Windows. >> >> Is that something you have to enable? Seems awfully strange to have the >> chip interceding in-band. Automatic hardware flow control I have heard of. >> >> This failure on Linux is why I made HTERM to use hardware flow control >> >> If there's a consistent way to make it work on Linux, it would be good to >> know. Even just with FTDI chipset. Windows prolific drivers are trash. I >> don't know about Prolific on Linux. >> >> Is the stty command you put supposed to enable on-chip software flow >> control? Which part? >> >> *s**tty -F /dev/ttyUSB0 ixon ixoff stop ^S start ^Q -onlcr -icrnl eof >> ^Z 19200* >> >> -- John. >> >>>
