gtme:
I wrote that I wanted to bypass the Bridge and use direct serial communication between Linux and Atmel for the reason that I assumed that the Bridge has a lot of overhead.
I read that, and I was keying in on your comment that you "assumed" there was overhead. Of course there's overhead, there's overhead in everything you do, even if you write your own communications protocol. The real question is whether that overhead is too much? Have you tried to quantify it in your application and found the overhead to be intolerable? By your "assume" comment it would appear that you haven't.
Sure, there are high bandwidth or very low latency applications where every microsecond counts. For such an application, you need to take extreme measures, and writing your own direct protocol may be part of it. But for most applications, it's probably not necessary. Of course, if you want to write your protocol, just for the sake of writing it, go for it. But don't be too quick to dismiss the Bridge, there is a lot there that can make your life easier.
By using the Bridge as starting point for communication between Linux and Atmel, one accepts a program design where the centre of the system which you want to program is the Atmel (Linux as Atmel slave).
I wholeheartedly disagree with this statement - the Bridge forces no such architecture. My design goals when developing Yun projects is to have the Linux side be the master - it's does all of the heavy processing and communications, and makes all of the decisions - the sketch is the slave and acts as a dumb I/O processor. And this is all done using the Bridge library, so clearly it does not force the sketch to be the master.
I can think of applications where a Linux program is the centre of the system from where one can make calls (through serial communication) to the Atmel part. So the Atmel just executes commands issued from the Linux part (Atmel as Linux slave).
And I have written several systems using just that paradigm, except that the Linux processes (one of my projects has three independent processes) sends those commands through Process objects, not the raw serial port.
When the time is there, the program just has to send a message to the Atmel to start a pump and open a valve. When the time is over, the program just sends the message to the Atmel to close a specific valve and if necessary to stop the pump.
So this clearly is NOT one of the high bandwidth or low latency exceptions that I mentioned earlier. You are not sending a lot of data, so transmission speed is not an issue. It will likely take a few seconds for the pump to get up to speed and build pressure, the valves to open, and the lines to pressurize and water to start flowing, so a few tens or even hundreds of milliseconds of latency will make no difference.
This sounds just like my lighting controller project: the Linux processes are in charge, the sketch only receives on/off commands and sends raw analog current readings, and the Linux side is also acting as a web server and web application, plus sends out alert emails and text messages, and also processes incoming email commands and status requests. All using the Bridge.
This way the program-code for the Atmel can be kept very simple apart from the fact that one has to write a simple command-interpreter in order to make the Atmel understand the meaning of the commands sent from the C-program on the Linux-part.
I fully agree that limiting the code and the intelligence in the sketch is the way to go. But you don't have to write your own custom communications handler to do so.
Before I found out that Linux and Atmel can directly communicate through /dev/ATH0, the communication went through files. So I'm glad that this direct serial communication is possible because communication through files is not so fast.
Ouch! Using files is most certainly not the way to do it. If you think that's what you have to do when using the Bridge library, it's no wonder it left a bad taste in your mouth.
You really owe it to yourself to do a little experimenting with the Process class. Once you get the process started, the sketch talks to the Process in exactly the same way as the Serial and Serial1 interfaces - they all derive from Stream, so once the object is created, you interface to all of them the same way. The advantage over rolling your own communications really comes into play on the Linux side: instead of having to set up and configure the serial port, and explicitly sending data through it, the Linux process simply reads from STDIN and writes to STDOUT. This makes it real easy to test by simply running the process on the SSH command line: you can see everything that is sent to the sketch, and can manually type in responses from the sketch to test various situations. The only caveat us that you probably have to enable unbuffered mode, which is usually pretty easy: for example, in Python, it's simply a matter of adding the "-u" option to the shebang on the first line of the script.
So, using a Process object over rolling your own really doesn't change anything in the script. And it simplifies the Linux process I/O. But where it really shines is when you want more than one process to talk to the sketch: to do it your way, you need to write an overall process that manages the communications, and then it must creat additional threads or sub-processes and pass the communications on to them. With the Bridge library, just create another Process instance, and it keeps everything straight - it's as if each had their own dedicated serial port.
Now, while it is true that the sketch must initially launch the Process object, rather than having Linux launch it, that does not mean that the sketch is the master. I launch the Process object to run asynchronously, and the Linux process is set up to run indefinitely. You may think that having the sketch launch the process is a disadvantage, but I see it as an advantage: you don't have to mess with cron, rc.local, or have to manually SSH in to start the process, and the sketch can act as a watchdog where it monitors whether the process is still running and automatically restarts it if it crashed - that's easy to do in the sketch, and much more difficult to do locally in Linux.
I'm not saying that the Bridge library is perfect and is always the way to go - it depends on the application. But I haven't heard anything yet in your descriptions that precludes using the bridge - it can do everything you've stated in this thread, and can do it well. Don't be so quick to dismiss it.
