Go Down

Topic: Tty for serial port to Arduino from Linino (Read 66206 times) previous topic - next topic

mamu

Regarding my experience from doing a bi-directional / full duplex Serial1 based communication between a python script and an Arduino sketch, I had to comment the following line in iinittab to get the communication to work without problems:
Code: [Select]
ttyATH0::askfirst:/bin/ash --login
The reason is that with leaving the above line in place, some parts of my data send from Arduino to  Linino got lost. The other way round works perfectly.
Currently I'm making tests with leaving the line in inittab and disabling the tty echo. I'll post about my progress here.

mamu

Only get duplex Serial1 communication to work properly when modifying inttab by commenting the ttyATH0 line.
Maybe some of the tty experts can explain it to me. I still don't understand how it all plays together.

priority


Only get duplex Serial1 communication to work properly when modifying inttab by commenting the ttyATH0 line.
Maybe some of the tty experts can explain it to me. I still don't understand how it all plays together.


The answer to your question is quite clear: 
If the Bridge is running while your Python program is running, there is no mechanism to decide whether your Python program or the Bridge gets incoming data on the serial port resulting in data loss.




mamu

#48
Dec 24, 2013, 08:43 am Last Edit: Dec 24, 2013, 11:17 am by mamu Reason: 1

The answer to your question is quite clear:  
If the Bridge is running while your Python program is running, there is no mechanism to decide whether your Python program or the Bridge gets incoming data on the serial port resulting in data loss.


So I will give it a try and stop bridge before launching my python script. Maybe this will make it unnecessary to modify inittab.

Edit: No, it's not the bridge, because calling /usr/bin/kill-bridge right before starting my python script does not solve my problem. Looks like I really have to get rid of the "ash --login".

spdonegan

I have not found where bridge.py is being started in the system - given what I am trying to do I prefer to completely defuse the Bridge/Process/etc code and simply let the 32U4 and the AR9331 talk directly via ttyATH0/Serial1.

TIA

steve at donegan dot org

priority


Edit: No, it's not the bridge, because calling /usr/bin/kill-bridge right before starting my python script does not solve my problem. Looks like I really have to get rid of the "ash --login".


Sorry, I should have been more clear. 

If the ANYTHING (including the console, Bridge, or any other program) is using tty on the linux side while your Python program that is trying to use tty is running, there is no mechanism to decide whether your Python program or the other program gets incoming data on the serial port resulting in data loss.

So, YES, you must disable console on tty in order for your Python program to reliably receive data from the 32u4.

priority


I have not found where bridge.py is being started in the system - given what I am trying to do I prefer to completely defuse the Bridge/Process/etc code and simply let the 32U4 and the AR9331 talk directly via ttyATH0/Serial1.

TIA

steve at donegan dot org

The 32u4 sends the bridge startup command over the serial port to start the bridge process.   If the serial console is enabled, the linux side will execute this command just as if someone had typed it from a keyboard and hit enter.  Thus, if the serial console is disabled, the Bridge is effectively disabled.

The relevant portion of code from bridge.cpp in the Bridge library:
Code: [Select]

  ...
    // Bridge startup:
    // - If the bridge is not running starts it safely
    stream.print(CTRL_C);
    delay(250);
    stream.print(F("\n"));
    delay(250);
    stream.print(F("\n"));
    delay(500);
    // Wait for OpenWRT message
    // "Press enter to activate console"
    stream.print(F("run-bridge\n"));
    delay(500);
    dropAll();
...

spdonegan

Thank you Priority. So if I do not include bridge.h/do any 32U4 side bridge related calls, and comment out the serial port in inittab then no process should run on either processor which uses Serial1? If so I will proceed with my little project - Arduino captures GPS data, Hall sensor data (vehicle speed) and calculates some basic speed/distance/time/location data and sends that as a single line to the AR9331/Linino side. I am trying to replace a Raspberry Pi for my application (Open Road Rally computer).

Thanks! And Merry Christmas!

priority


Thank you Priority. So if I do not include bridge.h/do any 32U4 side bridge related calls, and comment out the serial port in inittab then no process should run on either processor which uses Serial1? ....

Thanks! And Merry Christmas!


Merry Christmas as well!

Glad this was some help; took me a while to get my head wrapped around how the Bridge did its magic and then another bit of time to understand how to prevent the Bridge from doing its magic.  I wish the Bridge worked better; the transfer rate between Linux and 32U4 is just abysmal from my experience.

The only other pitfall that I am aware of wrt to using the serial connection between the 32U4 and Linino is during the period of time that Linino is booting.  During u-boot, printk is enabled and will spew quite a bit of text on the serial port.  The inittab disabling does not affect printk.  The big issue here is that you do NOT want to respond to any of the uboot text as you will cause the boot process to halt and wait for further input.   The second page of this thread has very good info (wayoda/scrot/me -- replies 16-18) about this issue and what the Bridge tries to do to ensure it is not affected.  Scrot has code that works for his needs in Reply 23 that leverages the Bridge u-boot pitfall avoidance loop.

mediamad

Thanks to everyone for the input here.  Scratching my head on something though... now that I have this set up how can I monitor the incoming data to Serial1 on the Arduino?

Gernby

I intended to post in this thread first, since it's really what got me thinking about this, but since so many of you guys proved that the serial connection between the 2 Yun processors doesn't work well above 115200, it seems to me that maybe the whole reason why the Bridge library is so slow and flaky.  When I looked in the source code for the Bridge library, the default baudrate for Bridge.Begin() is 250000.  However, it looks like you can specify override that with Bridge.Begin(115200).  Has anyone tried this to see if it might improve the performance of the Bridge by reducing the number of CRC failures and retries?

nickgammon

I think I deleted your other 10 or so posts on the exact same subject. Stick to one thread please.

Please do not cross-post. This wastes time and resources as people attempt to answer your question on multiple threads.

- Moderator
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

Gernby

Sorry for cross-posting, but I really think my posts were relevant to those threads.  I think the OP's of all of those threads would have wanted to see it ... :(

On another note, I was able to test the bridge at various baud rates, but I haven't determined for sure if it is more "stable" at 115200.  It took a while for me to figure out how to programatically change the speed of the UART on the Linino side, since I'm a total NOOB to Arduino and Linux "stuff", but it was a whole lot easier than customizing the Kernel!

I wrote a simple app in .NET that would repeatedly call REST commands in a loop, and executed that at 4800, 115200, and 250000 for hundreds of iterations.  The average time for each loop at 4800 wound up at 1.6 seconds, and the other 2 speeds were identical at 0.56 seconds.  This was over WiFi, so I will think about writing a test that eliminates some of the network latency.

federicofissore

The latency in REST calls is not related to Bridge speed but rather to how each http request in handled: each http call needs to start a new lua process (linux side)., that handles the request and then ends. Such process start-end loop is what is slowing down the REST api: the bottleneck is on the linux side.

mwalimu

#59
Jan 16, 2014, 02:29 am Last Edit: Jan 19, 2014, 07:30 pm by mwalimu Reason: 1
How exactly does one install pyfirmata?  I can't do it from opkg (or can I?).  I've tried copying and pasting the source, but that doesn't seem to work.

EDIT: I figured it out "pip install pyfirmata"

Go Up