super clear explanation noblepepper and I love the airbag metaphor. It would be nice to have a "yun boot up explained" paragraph on the playground, do you mind pasting your post there?
I like the explanation too.
And I do not feel very comfortable about changing inittab and removing the tty entry.
But what is a better solution if I want to attach to Serial1 and listen for incoming data?
So I'm not sure after reading through the posts if I definitively understand the process.
-
Does the tty HAVE to be disabled in inittab for the connection between the two sides to work? If not, do I correctly understand that once the boot process is finished you then must reset the baud rate?
-
Can the Bridge app be left alone or should it be disabled from starting as well?
1)a No, definitely not true, the bridge operates fine with this enabled. I haven't studied it enough to tell you exactly how it does this, but this is where I would start. I believe Federico said that the bridge filters out some "chatter" that the kernel will send to the console from time to time.
1)b There are some that say 250,000 is too fast but the bridge seems to operate there fine.
- I think if you want to use this connection without going through the bridge you will need to disable the bridge since it is using it. You will lose all the functionality of the bridge if you do.
@noblepepper Thanks for comments. I realize I wasn't clear on 1) I was asking this question with regard to establishing a serial connection from Python, not using the Bridge.
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:
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.
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.
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.
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.
priority:
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".
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
mamu:
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.
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
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:
...
// 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();
...
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!
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? ....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.
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?
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?
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
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.
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.
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"