Hello,
Could somebody advice me on the library to have python talking to the Arduino? I would like to get the DHT22 temperature and humidity values readable by python and pushed into a Sqlite database.
Hello,
Could somebody advice me on the library to have python talking to the Arduino? I would like to get the DHT22 temperature and humidity values readable by python and pushed into a Sqlite database.
Hi!
I haven't done this myself, but a google search gave me this:
http://playground.arduino.cc/Interfacing/Python
At the top of the page:
"After installing pySerial, reading data from Arduino is straightforward: "
Hope this helps.
electrofun123:
At the top of the page:
"After installing pySerial, reading data from Arduino is straightforward: "
That page is written for a typical Arduino talking to a Linux computer over the serial port. It can work for the Yun, if you do a little work to disable the existing services that use the serial port (login prompt and system log output) but there are easier ways.
There are already mechanisms in place to simplify communications between a sketch and the Linux side of the Yun. Probably the simplest is to use the Process class. You can create a Process object to start your Python script, and run it. While running, anything the sketch print()s to the process object will be sent to the Python process (which it can read from standard input just like it would read from the keyboard.) Anything that the Python process prints (using the same methods it would use to print to the screen) is sent to the sketch which can read it using process.read() just as if it were a serial port.
When running a Process object, you can call run() which will not return until the Python process exits, or you can call runAsynchronously() which will return right away and let the sketch run at the same time as the Python code. I use this method most of the time: start the Python code in the sketch setup() function, and then the Python code enters an infinite loop. Data can then be sent down or up at any time. If you go this route, it's important to turn off Python's default buffering: use Python's -u command line option when launching he script (ie: Python -u scriptname.py)
If you do want to bypass existing code and talk directly (it's a bit faster and more efficient if you need extremely high bandwidth) then use pyserial to open /dev/ttyACM0 on the Linux side, and have the sketch use Serial1. Personally, I've never had to resort to that, the Process class has always been fast enough for me.
ShapeShifter:
There are already mechanisms in place to simplify communications between a sketch and the Linux side of the Yun.
Opinions differ on that point.
My personal view is that some idiot chose to make the simple and well established Linux-Arduino comms system almost unuseable on a Yun. Thankfully it is not completely unuseable.
This Thread Develop on PC, deploy on Yun may be of interest.
...R
Robin2:
Opinions differ on that point.
As you say, that is debatable.
The communications between the Yun and the Linux side is not exactly the same as the communications between a typical Arduino and the serial port of a PC. And the existance of the Bridge Library has absolutely nothing to do with it. The difference is that the Linux side serial port is running a command interpreter and is also randomly sending log messages to that port.
In order to make it work mostly like a PC to Arduino serial connection, you need to go to special steps to disable the command interpreter on the Linux side, and to disable log messages. (My understanding is that you can stop many, but not all log messages.) Once you've done that, you can mostly use it as a regular serial port, but you may still get random log messages mixed in with your regular communications. You must make sure your sketch code is not confused by these additional messages, something you don't have to worry about when using Python with a standard PC serial port that doesn't also serve as a system console.
My personal view is that some idiot chose to make the simple and well established Linux-Arduino comms system almost unuseable on a Yun.
You seem to be under the impression that "some idiot" intentionally ruined things by using that port as a command shell and system console - he didn't, that's just the way Linux works. Your Linux PC might boot up using the screen as the console output, and the keyboard as the command shell input, but those devices are not available to the Yun's Linux processor. The ONLY choice it has is to use the only available serial port, so by definition that port must be able to serve as the system console, a command shell, and the interprocessor communications, all at the same time
Now, you are free to disable much of that ability to simplify your communications, but if you do so, you run the risk of closing off your only way to see status, and effect repairs should some disaster befall your Yun and you are not able to log in using the network.
I don't feel that "some idiot" ruined things by creating the Bridge Library. He worked around the inherent limitations of the Linux console port and came up with a system that offers a lot of capabilities without disabling useful debugging and disaster recovery features of the Linux system. He didn't do anything that prevents you from doing what you want to do with your system, he just didn't disable the useful console features that are getting in your way. It's the nature of Linux that's causing you problems, not anything that a developer at Arduino created.
I think that the best communications system between the two processors would be something that allows the very useful existing functionality of the Linux console port, and still allows reliable communications between the two processors. That communications should have a mechanism of distinct message IDs and message integrity checks that can ignore log messages and any other extraneous output. It should also allow a communications between a Linux process and the sketch. It would be nice if it could actually talk between several different Linux processes and keep them straight, and perhaps even handle web requests, TCP socket communications, and even data and message passing, all at the same time. What would be truly useful is a communications protocol that allows all of that while not requiring a lot of code to be written on either the sketch or Linux side, and doesn't require that the essential console port capabilities be disabled. A library like that could be very useful.
Oh, wait a minute, we already have a library light that: the Bridge Library! ;D
But if you don't like it, there is nothing forcing you to use it. And there is nothing that the Bridge Library or Arduino did to "ruin" serial communications for others.
ShapeShifter:
I don't feel that "some idiot" ruined things by creating the Bridge Library.
I am assuming that this debate is taking place in a friendly atmosphere.
My real complaint is that the "idiot" put the Arduino in charge of Linux rather than the other way round. That's a bit like getting me to help Richard Feynman with maths.
And he (the idiot, not Feynman) did it in such a way that the Arduino's spare serial port is not available for communicating with the outside world.
I may indeed be missing something important, but I can't see why a Yun is not the same as (albeit less powerful than) a combination of an RPi and a Leonardo. That's what I thought I was getting when I bought mine.
...R
Robin2:
I am assuming that this debate is taking place in a friendly atmosphere.
Absolutely! That's what the winks and smileys were for, since it's so hard to tell emotion in written words.
My real complaint is that the "idiot" put the Arduino in charge of Linux rather than the other way round. That's a bit like getting me to help Richard Feynman with maths.
I guess it all depends on how you look at it. The Linux side can load new firmware into the Arduino side, and the Linux side can reset the Arduino processor. The same is not true in the other direction. Seems to me like the Linux side is firmly in control and has the MCU by the short hairs...
Yes, the Arduino side can easily start a Linux process using the Process class, but that doesn't prevent you from launching a Linux process manually (or automatically in rc.local or cron) without involving the MCU. Everything on the Linux side including networking and web services are fully functional without the MCU processor. In fact, I've used a jumper wire to keep the MCU in a hard reset state for a while, as I do some Linux side debugging. (And I'm sure I could hold the MCU in hard reset using Linux software commands as well - /usr/bin/reset-mcu pulses the reset line, it would be simple enough to duplicate that and just not immediately release the line.)
The MCU is in control? I very much disagree. There are a lot of examples that show the sketch taking a leading role, but the Yun certainly doesn't have to be used that way.
And he (the idiot, not Feynman) did it in such a way that the Arduino's spare serial port is not available for communicating with the outside world.
What's that? Are you saying that you don't like that pins 0 and 1 are connected to the Linux processor? How else are you going to communicate between the two processors? If you are going to say via SPI (which, by the way, is connected between them) or I2C, you can stop right there because that violates your previous statement about talking from Python just like you do with any other Arduino. You can't have it both ways.
I suppose you can hook the MCU's USB port to the Linux system, but then you'd have people complaining that the port wasn't available to hook to a PC for use with the IDE. Oh, and by the way, you are certainly free to plug a USB cable between the two USB ports and talk that way, and that will indeed free up the pin 0 and pin 1 UART for whatever purpose you desire -- there are level shifters between the two processors, and some simple GPIO twiddling on the Linux side will disable those shifters and isolate the two processors.
I may indeed be missing something important, but I can't see why a Yun is not the same as (albeit less powerful than) a combination of an RPi and a Leonardo. That's what I thought I was getting when I bought mine.
I think it's already something better than an RPi and Leonardo. If you had bought that combination, you would've either hooked up the RPi serial port to the Leonardo pin 0 and 1 and be in the same situation where the UART is tied up (except that you wouldn't be able to disable it in software) and you'd still have to deal with the Linux console port conflicts. Or you would hook up the USB ports together and be able to use your existing unmodified Python to Arduino code between them, and be in the exactly the same situation as you would be in hooking the two USB ports on the Yun together.together. The difference is that with a Leonardo and RPi, that is all you have - serial communications the way you've always done it. The whole is simply the sum of the parts. With the Yun, it has so many additional capabilities that the whole is much greater than the sum of the parts.
I don't think there is one ideal setup for communications between the two processors - no matter what you do, someone is going to want something different. But, personally, the more I dig into the architecture and what's possible between these two systems, the more I think that the designer of the board did an admirable job of making a powerful, flexible, and highly hackable development system. There are some existing connections between systems, but they are easy to disable in software. It can be used like a traditional Arduino and Python combination. It can be used with the Bridge library to do so much more than you could do with straight serial communications (you'd have to write a lot of code to accomplish the same things.) It can be used by people who are familiar with Arduino and afraid of Linux. It can be used by people who are familiar with Arduinos and networking shields and just want to port over what they have. It can be used by people who are familiar with the traditional methods, and want to expand into Linux. It can be used by people who are familiar with Linux and want to add easy to use MCU capabilities to it. It's just so plain versatile and usable by just about anyone.
You want to use it as nothing more than a Linux system talking serial to an MCU. So go forth and do so, there is nothing in the design that is preventing you from doing that. But if you just slapped a Leonardo onto an RPi, you'd be missing out on all of the other things that the Yun brings to the table.
ShapeShifter:
The MCU is in control? I very much disagree.
I guess we are on different wavelengths and I have not been expressing myself clearly. I am not talking about what the Yun CAN do, but rather what it is marketed as.
YOU clearly know how to use the Linux side effectively when you need to.
But the broad impression I have is that the Yun is presented (and widely perceived by users) as an Arduino with Wifi etc tacked on and the normal way to get anything to happen on the Linux side is to make calls from the Arduino.
I have seen many Threads here with questions that would never have arisen if the OP had been working with a regular Linux PC coupled to a Leonardo.
...R
Yes, the documentation, what little there is in places, is targeted to the Arduino audience - it is positioned as an Arduino with improved networking. That seems natural, given the focus of the company and their other products. Perhaps they think that stressing the Linux side will scare away their typical Arduino customers? After all, Arduino is targeted at artists and beginners with no computer and electronics experience, and that sort of person is likely to be scared off by the thought of using a Linux command line or learning yet another programming language.
But the marketing department doesn't make the unit do what it does, the engineering department actually defines what the unit can do and how it does it. And I think they've done very well given the limitations of the individual parts.
Marketing doesn't control how the unit is used: it's up to us, the users, to take all of the elements given to us by the engineers and use them to the fullest potential to meet the needs of our current project, within the range of our abilities. If that means using it as an Arduino with a dumb network interface and/or SD card, that's OK. If it means using it as a Linux system with an attached MCU I/O processor, that's also OK. If it means a hybrid approach where each side is used for their unique abilities and making use of available existing libraries, that's also OK. I've used the Yun in all of these patterns, depending on my project and depending on my familiarity with it. I think it's great that people can use it as a basic Arduino, or as a Linux system, or as anything in between.
It's like a very sporty and nimble car that is marketed to grandmothers so they can go to church on Sunday. Does that mean that nobody else can enjoy the car, and that it can't be taken out for a spirited run on Track Day? Of course not. It isn't what the marketing folks say it is, it is what we make of it.
You lament that the Yun is not marketed as a replacement for a Leonardo talking serial to a computer running Python, and that the documentation doesn't mention how to use it in that manner. Well, I don't see anywhere where the Arduino documentation or marketing talks about using a standard Arduino to talk to Python over serial - that's something that was developed and documented by others. Why should the Yun be any different?
ShapeShifter:
You lament that the Yun is not marketed as a replacement for a Leonardo talking serial to a computer running Python, and that the documentation doesn't mention how to use it in that manner. Well, I don't see anywhere where the Arduino documentation or marketing talks about using a standard Arduino to talk to Python over serial - that's something that was developed and documented by others. Why should the Yun be any different?
Let's agree to disagree
...R