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 <[email protected]> wrote: > > > On Thu, Sep 22, 2022 at 5:32 PM B 9 <[email protected]> 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. > >>
