On Thu, May 4, 2017 at 9:32 AM, David Howlett <[email protected]> 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. > That good, something less to get in your way to fixing your problem. > 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. > So, you've actually delved further into using the UARTs on this platform than I ever have. Even with other( bare metal ) platforms, I only really use UARTs for a printf() style serial debug output. With this platform, we do not need it, unless you're troublshooting the boot process. Anyway, my first instinct wants to say baud rate is involved somehow. It's very unlikely a baud rate difference between systems, because usually when this occurs, your transmission will be garbled. At least a few characters here and there will be different between send, and receive. So this leads me to speculate that you're somehow exceeding your maximum baud rate. Another thing I'm noticing from what your code is outputting. is that your "data loss" is not consistent. Which immediately makes me want to jump to the conclusion that you code is somehow being preempted. Almost as if you're data is on the stack, something preempts your code, and by the time the part of your code is given control back, the data on the stack is no longer there. This sort of situation is what I refer to as "stepping all over the stack". e.g. some of those routines you're using could be stack unfriendly. Granted, I know very little about Python, or the libraries Python uses. But I've personally experienced this effect first hand, when using a third party web server API, when dealing with a lot of data fast. CANBUS at 1Mbit, while decoding PGNs in real time, and attempting to send this data in real time using this third part web server API. I wonder if you run the application that failing for you there is you pipe that data to a file, instead of to stdout, if you would be experiencing the same problem ? Why don't you humor me, and give that a try ? e.g. run your application as such: $ myapp > some_log_file.txt Run it for a few hundred iterations and see if you get any blank transmission, and if you do, if they are fewer. If this stops your blank tramissions, or lessens them a fair bit. Then your problem could either be python not being able to keep up( I'm kind of doubting that ), or Windows for whatever reason is preempting your code mid transmission. Or even something else not yet considered. -- 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/CALHSORrMbrWmS22aaJbObbhbp-PXx3h04bfEvNkS_aj1zxwmaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
