David: I am confused as to what your actual hardware configuration is, with respect to the "serial communications."
Are you using a COM port in Windows to talk to a USB to serial cable, which is talking to a hardware serial port in the BBB? Or, are you doing something else? If so, please describe. I have never seen these kinds of problems when dealing with hardware serial ports. --- Graham == On Thursday, May 4, 2017 at 11:32:04 AM UTC-5, David Howlett wrote: > > >> First, you're going to need to learn how to use systemd, and > specifically, you're going to need to learn how to create, and use a > startup service. > > I happen to have used systemd startup services in a previous project so I > can see how it would be useful for setting settings on startup. > > >> Second, you need a tool that is capable of working with serial devices > at a "low level". Such as: > https://manpages.debian.org/jessie/coreutils/stty.1.en.html and > specifically this setting: > > This is the tool I was looking for and could not find, thank you. The > default settings for the serial connection I am using are: > > root@beaglebone:~/reusable# stty --all > speed 9600 baud; rows 0; columns 0; line = 0; > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; > eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = > ^R; > werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; > -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts > -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon > -ixoff > -iuclc -ixany imaxbel -iutf8 > opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 > vt0 ff0 > isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt > echoctl echoke > > I can now use the stty command to set ixon on or off. > > root@beaglebone:~/reusable# stty -ixon > root@beaglebone:~/reusable# stty --all > speed 9600 baud; rows 0; columns 0; line = 0; > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; > eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = > ^R; > werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; > -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts > -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon > -ixoff > -iuclc -ixany imaxbel -iutf8 > opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 > vt0 ff0 > isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt > echoctl echoke > > Unfortunately the data loss is the same regardless of whether ixon is > enabled or disabled. Changing ixoff does not affect the data loss either. > I tried setting crtscts and cdtrdsr but this is not permitted. > > root@beaglebone:~/reusable# stty crtscts > stty: standard input: unable to perform all requested operations > root@beaglebone:~/reusable# stty cdtrdsr > stty: invalid argument `cdtrdsr' > > There is flow control regardless of what I do > ============================================= > > There does appear to be flow control of some sort. I realised I can get > debug information with the CPU LED. I can make the CPU light on the BBB > light up for 2.4 seconds by running the following program on the PC. The > fact that the CPU light turns off again indicates that there is some kind > of flow control that pauses the computation when the buffer fills up. > > import time > import serial.tools.list_ports > > # connect to the BBB serial port on Windows > x = serial.Serial('COM9') > x.read_all() > x.write(b'python3.6 -c "while True: print(sum(i for i in range(1000)))"\n') > # pause forever > time.sleep(1_000_000) > > If I slow down the CPU wasting command like this: > > import time > import serial.tools.list_ports > > # connect to the BBB serial port on Windows > x = serial.Serial('COM9') > x.read_all() > x.write(b'python3.6 -c "while True: print(sum(i for i in > range(10_000)))"\n') > # pause forever > time.sleep(1_000_000) > > Then the CPU LED stays lit for about 10x as long. This demonstrates that > streaming on the beagle bone is stopped by a buffer filling up rather than > a timer. > > Data loss only happens when the length of the data being written is not a > multiple of 4 bytes > > ============================================================================================= > > As an example if I run the following program there is no data loss: > > import serial.tools.list_ports > > # connect to the BBB serial port on Windows > x = serial.Serial('COM9') > x.write(b'yes "123456"\n') > > while True: > received = x.readline() > if received != b'123456\r\n': > print(received) > > But there is data loss if I run this: > > import serial.tools.list_ports > > # connect to the BBB serial port on Windows > x = serial.Serial('COM9') > > x.write(b'yes "1234567"\n') > > while True: > received = x.readline() > if received != b'1234567\r\n': > print(received) > > It prints: > > b'yes "1234567"\r\n' > b'11234567\r\n' > b'11234567\r\n' > b'12234567\r\n' > b'12334567\r\n' > b'12345677\r\n' > b'\n' > b'\n' > b'\n' > b'\n' > b'\n' > b'\n' > b'12345567\r\n' > b'\n' > b'12234567\r\n' > b'\n' > b'12334567\r\n' > b'12344567\r\n' > b'12344567\r\n' > b'\n' > b'\n' > b'12344567\r\n' > b'12234567\r\n' > b'12345567\r\n' > b'12345667\r\n' > b'\n' > b'\n' > b'12234567\r\n' > b'12334567\r\n' > b'12234567\r\n' > b'12345677\r\n' > b'12334567\r\n' > b'\n' > b'12345677\r\n' > b'1234567\r\r\n' > b'\n' > b'11234567\r\n' > b'12234567\r\n' > b'123234567\r\n' > b'12234567\r\n' > b'12334567\r\n' > b'\n' > b'12345677\r\n' > b'1234567\r\r\n' > b'12344567\r\n' > b'\n' > b'11234567\r\n' > b'\n' > b'12334567\r\n' > b'12345667\r\n' > b'12234567\r\n' > > Note that every error printed only contains single byte errors > > Conclusions > =========== > > - The virtual serial port provided is a poor imitation of a real serial > port. Every command to change any property of either end of the connection > either fails or is ignored. > > - There is undocumented flow control somewhere behind the scenes outside > my control. It is probably in a driver. > > - The flow control mechanism loses data if the data is not a multiple of 4 > bytes long. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d070cf0c-6522-4ed3-ba3b-d8b3dbeb9a9f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
