You make valid points. And of course it's your project, so you cal the shots. I'm just trying to offer suggestions about how to make it useful to a wider audience.
Robin2:
The reason I have disabled the Bridge capability is that I wanted to explore whether identical code can run on a Yun and on a PC. The first thing the code does is get a list of the serial ports so the user can select the appropriate one. The Python code is entirely unchanged for the Yun apart from telling it that it is using a Yun so it can use the correct 32u4 reset process.
Just trying to provoke some thoughts... For ultimate flexibility, I would think it's valuable to have the major part of the Python code simply read from STDIN and write to STDOUT. That increases versatility in usage and testing: it lets you use other stream devices for I/O rather than just tty serial ports, and it allows simple testing: initial unit testing can be done by running it on a command line, then you can simply type the commands that the Arduino would send, and immediately see the response. And for regression testing, it lets you send a stream of commands from a file, and log the output to a file.
What you would need is a low level wrapper: some code that finds and opens the tty port, and redirects it to STDIN/STDOUT, then calls the core code. This is what the Uno/Leonardo would access, and what the Yun would access if you had disabled the serial port.
For unit testing (or running on a Yun through the bridge) you would just run the core module directly.
For regression testing, you would have another low level wrapper that opens the input and output files, redirects them to STDIN and STDOUT, and then calls the core module.
For a remote network interface, you would have a low level wrapper that makes the network socket connections, redirects them to STDIN and STDOUT, and then calls the core module.
The possibilities are virtually limitless, and very much in line with generally accepted Unix coding conventions where the process uses only STDIN/STDOUT/STDERR and the operating system redirects various data streams to it.
The whole idea is to decouple the core code from the concept of working with serial ports, and make it just work with standard streams. Then, all you need is a thin wrapper layer to connect the logical streams with whatever physical communications method you want.
And of course, all of this would still run on a PC without modification (although the names of the devices will likely change.)
As far as I can see the out-of-the-box concept for the Yun is that the Arduino is dominant which seems to require considerably more programming on the Arduino side.
Yes and No. The main focus does seem to be to "do it all" in the sketch. I believe this makes it easier for an experienced Arduino programmer to move to the Yun, in that it doesn't require a different way of thinking, and it doesn't require learning Linux right away. However, that doesn't mean it's the only way to use the Yun or the Bridge.
You are putting the Linux side in control, and you are also using a Linux mechanism to start the Python process. If you are willing to give up that one part of control and hand it over to the sketch, you can have the sketch start the Python code using the Process class. After that point, everything else can be controlled by the Python side.
You want to be able to handle multiple Arduino hardware types without having to rewrite the sketch. Well, you already have to change the sketch when moving from Uno to Yun, because you have to access Serial1 instead of Serial.
Well, what if you didn't access either? Create a Stream object, and do all of your I/O with that. Now, on the Uno, you open Serial, and then assign that to the Stream object. On the Yun, you open Serial1, and then assign that to the Stream object. Or, if you don't want to disable the Bridge, start the Python code using the Process class, and assign the Process object to the Stream object. All of those classes: HardwareSerial, SoftwareSerial, EthernetClient (Ethernet shield library) and WifiWebClient (WiFi shield library) all derive from the Stream class. And, as it turns out, Process and YunClient from the Yun's Bridge library also derive from the Stream class.
So, if you want to write portable code, it should be written so that it expects to talk through a Stream object. Then, the only platform specific part of it is actually opening up that stream (Serial, Serial1, SoftwareSerial, Process, etc.) The core code doesn't change at all, regardless of the physical connection.
So, on both the Linux and Arduino side, if you write the code to use the standard streams, then all you need is a thin wrapper layer to make it work with any hardware on any platform, and not just hardware serial ports.
Like I said, just trying to promote thinking...
