> > $ python3.6 ~/reusable/BBB_pressure_streamer.py > some_log_file.txt > > When I view the log file I can't see any errors >
So, actually, scripting languages in general can be far slower, that their native code counterparts. Firstly, because there is an interpreter, and secondly because of code bloat, through using libraries. Almost as a rule, larger executables will lead to poorer performing code. Python in particular is one of if not the slowest languages also when bench marked in some tests. And I do not mean by a second or two. I mean by a huge margin in seconds, for specific tests. Just as an example though, in a few tests I remember reading, Compared to Nodejs, Python was behind by a minute or more. My point here is not to say Nodejs is better or not though. Nodejs is pretty terrible it's self. This is meant demonstrate in general that scripting languages can be terrible when your app is I/O intensive. The reason why I suggested piping the output of your script to a file was to see if there was potentially any "normal" I/O bottlenecks involved. All languages can suffer from this however, because printing to screen( stdout ) is, or can be very I/O intensive. In C, you're maybe going to max out around a couple hundred "samples" to stdout a second, before your application will noticeably slow down. With Nodejs, it's actually far less. I do not know if Python is slower than Nodejs in this case. It's been a while since I've read the benchmarks, but actually the benchmarks were not testing this capability anyhow. Maybe they should have been ? All in all, I'm still not convinced this is the problem in whole. But I do feel that it could be a contributing factor. It still would not explain why you seem to be getting your full amount of transmissions. Just that some of those transmissions are "empty". Especially when those empty transmissions are not consistent in timing / frequency. I would suggest that you do keep this in mind, and perhaps at least consider testing output to a file further. Instead of testing while output is to stdout. At minimum, this will allow you to rule out, output to stdout as a contributing factor in your code. With very little wasted time on your behalf. On Sat, May 6, 2017 at 8:25 AM, David Howlett <[email protected]> wrote: > Sorry for double posting last time, this is my first time using google > groups. > > >> 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 ? > > The data loss problem also happens when the yes command is just repeating > a string over and over to stdout so I don't think the problem is python > related. > > >> Why don't you humor me, and give that a try ? > > I tried: > $ python3.6 ~/reusable/BBB_pressure_streamer.py > some_log_file.txt > > When I view the log file I can't see any errors > > >> Have you tried reducing the receive FIFO level? > > I had not thought of that. Today I tried setting the Tx and Rx buffers to > 1, 8 and 14 bytes. Data continued to be lost on all settings. > > >> Suspect I'd start with > >> stty ixon ixoff -ixany > >> and ensure the other end is set for equivalent. > > I tried: > > root@beaglebone:~# stty --file=/dev/ttyGS0 ixon ixoff -ixany > root@beaglebone:~# 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 > > and I also turned on flow control on the python side at the same time but > I still got data loss. > > >> Recommend you specify /which/ serial port > > I was originally running stty while connected to the virtual serial port > but I forgot to mention that detail. > > >> I can't duplicate your results as > >> debian@beaglebone:~$ python3.6 -c "while True: print(sum(i for i in > range(10000)))" > > I previously installed python3.6 on all my boards. I should have given an > example that only depended on base Debian. > > >> #flush input buffer (where did .read_all() come from?) > > It is from https://github.com/pyserial/pyserial/blob/master/serial/ > serialutil.py > I was using it to clear the serial buffer of all data. Calling > .reset_input_buffer() is better > > >> OKAY -- THIS PRODUCED a drop-out 2574..2659 > > Thanks, it is nice to know that someone else can replicate the issue, it > is not just me doing something stupid. > > >> For a stable system, I would recommend considering doing the data > transfer over a real hardware serial port > > Today I purchased two connectors for the hardware serial pins from: > https://www.dfrobot.com/product-147.html > I will see if that helps. > > >> You never have been specific about how many bits per second of data > that you have to move. > > Today I measured the average data rate of my application to be 69,218 > bytes/second. > > >> This seems to me that you are indeed overflowing your buffer. > >> How or why I'm not sure, but if sending 6 characters all is fine, > >> and 7 characters does not transmit properly then obviously something is > wrong. > > When I send: > x.write(b'yes "123456"\n') > I receive 8 bytes per line not 6 due to the addition of /r/n. I don't > think this is terribly important though > > >> I'm suspecting you're not showing us all your code > > My working repository is here: > https://github.com/DavidHowlett/BBB_fault_demo > A permanent link to the relevant commit is here: > https://github.com/DavidHowlett/BBB_fault_demo/blob/ > 389785ec4e50af35fd78673d338063458da6be04/on_PC.py > > There is not much to see in the repository but you are welcome to have a > look. > The only thing worth noting is I use python 3.6 on the PC side too. > > >> Here you can see the source code of USB serial gadged driver > > Thankyou > > >> The easiest solution is to do a simple handshake > > That is a good idea for avoiding data loss, the troublesome buffer would > never fill so there would be no data loss. > > >> Why you want to use RS232, i would choose TCP ,UDP or WebServer > > Personal preexisting skill set. I have been using serial connections for 4 > years on multiple projects with multiple pieces of hardware. I wrongly > believed that it would be easy to just use serial again. > > In the future I plan to use the hardware serial connection. > >> -- > 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/d14843cc-8eb0-4fbb-bec1-3e9052c272ae%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/d14843cc-8eb0-4fbb-bec1-3e9052c272ae%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CALHSORpUPfyX3_BoY66BXc8j8aMp6H05FRwMcxaOsX6h3Nz%3DWw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
