EzScrn - With Charts - simple PC / smartphone interface for your Arduino program

12 April 2015 - The latest Version in Reply #10 now includes the ability to show charts based on data sent from your Arduino program.

EzScrn is a Python program that works with your Arduino program to provide a simple way to create a GUI screen on a PC (or phone or tablet). The Python program is a small webserver so the GUI screen is accessed through your Browser.

The idea is that all of the design of the GUI is generated with a few lines of Arduino code and all you need to know about Python is how to run the program and access the GUI with your browser.

For example, these few lines of Arduino code create this GUI screen.

Serial.println("<+newScrn, size=40x30, tleft=0x0, bg=green, fg=black>");
Serial.println("<+tOut, name=outA, size=38x10, tleft=1x1, bg=yellow, fg=black>");
Serial.println("<+btn, name=ledA, size=8x3, tleft=10x12, bg=black, fg=orange>");
Serial.println("<+slid, name=slidA, size=15x1, tleft=2x16, range=30x150x90x10>");
Serial.println("<+tOut, name=outB, size=38x2, tleft=1x18, bg=yellow, fg=black>");
Serial.println("<+quit, name=Quit, size=8x2, tleft=30x25, bg=red, fg=black>");
Serial.println("<+endScrn>");

create this GUI screen.

The Arduino code is attached below and the Python code, the Arduino code and the User Manual are in the ZIP file.

This is very much Version 0.1 and feedback is very welcome

Keen coders will notice that I am re-using several pieces of code from my existing Threads.

...R

EzScrnDemoA.ino (3.46 KB)

EzScrn.zip (476 KB)

Update.

I have now slightly modified EzScrn so that it can be used on a Yun as well as on a regular PC. Whether on a PC or a Yun the revised versions attached here should be used rather than the attachments in my Original Post.

For convenience I have four attachments here. The Arduino code (a regular version and a Yun version), the Python code in the ZIP file and the instructions in the PDF.

As usual, comments are very welcome.
I would also be very interested to hear from any Windows user who tries (and hopefully succeeds) to use EzScrn on a Yun.

...R

EzScrnDemoB.ino (3.77 KB)

EzScrnDemoYunB.ino (3.79 KB)

EzScrn02.zip (305 KB)

EzScrn02-Manual.pdf (195 KB)

Interesting. I will have to look into it more when I have a bit of time. (Anybody know where I can pick up a six-pack -- or better yet a case -- of extra hours?)

For those Yun users who don't want to lose the Bridge functionality, is there any reason the Python code couldn't just read from STDIN and write to STDOUT instead of opening ttyATH0? That way, the Python code could be started using a Process object. (Do realize that I haven't looked at the code yet, just the doc.)

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.

There is also a small philosophical issue here which I may develop in another Thread in the Yun section. In the EzScrn project the Linux side is dominant. It's relationship with the 32u4 is the same as (say) the relationship between a laptop and an Uno or Leonardo. This allows all the heavy lifting to happen on the Python/Linux side and requires no more on the Arduino (32u4) side than you would need on an Uno that was "slave" to a PC.

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. It also means that a Yun and an Uno program (for the same functionality) are not as easily interchangeable as (say) between an Uno and a Leonardo.

And, of course, the other advantage of using Python and the Linux side this way is that I can completely develop the project in comfort on my laptop and Uno and just port it to the Yun for final testing.

...R

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...

ShapeShifter:
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.

Sounds like you know a LOT more about this than I do. I will certainly spend some time thinking about what you have said. (Would you be prepared to wite an example?)

You have not mentioned whether what you have in mind will also work unchanged on a Windows PC?

One thing that feels important to me is to be able to treat the Yun as very small PC (a cut down RPi, perhaps) which just happens to have a Leonardo as a close neighbour. It has the HUGE advantage over an RPI that out-of-the-box you don't need a TV (which I don't own) to see its output, you an just use SSH and an existing laptop.

...R

Robin2:
(Would you be prepared to wite an example?)

I'll give it some thought. I've not used the Arduino Stream class like that (I'm quite new to Arduino, but not to embedded programming in general) but I have done plenty of Polymorphism in the past (which is the buzz-word for this technique.)

As an example, I picture a function that does a set of stream I/O (like your example screen code in the first post) using a Stream object that is passed in as a parameter. Then, call that function using Serial, a YunClient connection, and a Process object. I would think that should prove the point on the sketch side.

You have not mentioned whether what you have in mind will also work unchanged on a Windows PC?

The core Python code should work just fine unchanged. I don't have enough experience with Python on Windows to know if the low-level wrapper for the serial port will work without changing (but if the serial port code works now on Windows, there's no reason it shouldn't work as a wrapper.) Stream redirection and pipes have been a part of MS-DOS since the PC came out, and the functionality is there just like it would be in just about any operating system.

It has the HUGE advantage over an RPI that out-of-the-box you don't need a TV (which I don't own) to see its output, you an just use SSH and an existing laptop.

Of course, you can also use SSH and a laptop with an RPi, you don't have to use the video output.

The HUGE advantage I see that the Yun has over the RPi is the combination of on-board WiFi, and an integrated embedded microcontroller to handle real time I/O and processing. That's where I see the Yun's greatest strength: write an Arduino sketch to handle those parts that require low-level hardware I/O and hard real time control, and do the rest of the work (heavy computations, networking, storage, etc) on the Linux side. The limitation of the Raspberry Pi and Beagle Bone Black (and similar micro Linux systems) is that Linux is not real-time: therefore any hard real-time processing (things requiring microsecond level control, for example) don't work well in a non-deterministic operating system like Linux.

One of the real jewels in the Yun's crown is the ease of being able to do everything in a sketch, and the power of being able use the Linux side for the heavy lifting. You can divide up the task in many ways depending on your needs and abilities.

@ShapeShifter, thanks again.

My idea is to have both Python and Arduino code that is easy to use, and easy to be understood, by someone without much programming experience.

I'm struggling to decide whether what you have in mind fits within that category or whether (even if it may be technically superior) it would introduce too much complexity for an inexperienced programmer.

I will sleep on it.

...R

PS I think I understand why you were looking for a 6-pack of time - you give yours away too generously. Thank you.

Robin2:
I'm struggling to decide whether what you have in mind fits within that category or whether (even if it may be technically superior) it would introduce too much complexity for an inexperienced programmer.

Yes, that is the conundrum...

Like so much in life, there are trade-offs.

I have started a Thread in the Yun section to follow on with this discussion about STDIN and STDOUT and the Yun Linux to Arduino communication process

...R

Here is version 0.3 which now has the ability to display a chart based on data sent from the Arduino.

...R

EzScrn03.zip (337 KB)

EzScrn03-Manual.pdf (212 KB)

EzScrnDemoChrt2.ino (5.37 KB)

Hello Robin,

Great ideas here! Now to RTFM... (OK Back...)

Basic question: You say "To the best of my knowledge EzScrn needs nothing on your PC apart from the Python 2.7 interpreter." Where do I get that? How do I install it??

I see this:

with LOTS of choices.. (OK, I got 2.7.9 as suggested there. Installed it.

Update: Got this sort of working.

  • The LED button does dontrol the LED
  • The graph does not appear
  • The slider does not move the servo..

Any suggestions appreciated!

THANKS!

terryking228:
(OK, I got 2.7.9 as suggested there. Installed it.

Update: Got this sort of working.

  • The LED button does dontrol the LED
  • The graph does not appear
  • The slider does not move the servo..

First thing, I thought Windows automatically included Python. Anyway you seem to have now.

Second thing - you are the first person that I have heard from who tried it on Windows.

I presume (from your description) that you have Python 2.7.9 and all of my code installed without any changes whatever,

Wha browser are you using - it may well be that it does not work with Internet Explorer. If that is what you are using please try Firefox. AFAIK the graph and the slider use HTML5 features and, for some reason best known to themselves, the IE developers seem determined to do things differently from the normal web standards.

If it does not work with Firefox do let me know.

I note that you are also looking at the RemoteXY product - which I like very much.
Although EzScrn needs a server it does mean that it should work on anything with a suitable browser. I have only tried it with my Android phone - can't afford any of that Apple stuff.

...R

Can you post a Python 3.1.4 version? I don't want to install 2 versions of Python.

Isaac96:
Can you post a Python 3.1.4 version? I don't want to install 2 versions of Python.

I have no experience with Python3. I chose 2.7 because it seems most common.

What have you got that has 3.1.4 and not 2.7 ?

Now that you have put the idea in my head I might explore Python3 over the next few weeks.

...R

Well, I am running Windows which doesn't come with Python. A long time ago I read a book "write your own computer games with python" which used 3.1.4. So now I am stuck with that.

It should not be difficult to add Python 2.7 without affecting your 3.1.4

...R

Ok. I will try it.

Last night I installed Python 3.4 alongside 2.7 without any problems.

My first impression (when trying some of my old code with 3.4) is that 2.7 is still the "most standard" Python.

...R