Communication between Yun and UNO seeking advice

Good morning dear Arduino Forum,

I’m having quite fun and satisfaction with the Yún reading sensors and sending data to a .php controller thanks to the client.get function.

Now… I need to extend the range of sensors, and I have almost reach the limit of the sketch size.

I was wondering if, among others, a viable solution would be to use an Arduino UNO to run additional sketch (to read sensors) and then pass values of variables to the YUN who will then take care of sending data over the web, the same way it is already doing now.

Would you have some reference or tutorial to address me to? It’s not too clear to me if the 12C would be the right path…

Thank you,
L

I don't know if you can do such thing as these suggestions but ill throw them out there..

  1. connect a SD card to your Arduino, store/run the sketches from the SD via a small sketch on the Arduino..
  2. do a 50/50 and split the sensors across the Yun/Uno use one of them expensive shields to send/receive data between arduinos.

Even though I'm just starting out with this stuff (noob) just off what I'm doing (making rc car) im using an 433mhz transmitter/receiver to send between Uno/Nano and that looks like messy code and it is the most basic code, so I would go with the SD card option and have a small sketch on the Uno to run your main sketch off of the SD card. Bonus of having an SD card connected is that you can create big logs for debugging purposes.

Thats my logic,
Aaron.

Thank you Aaron,

Interesting but could you actually explain better?
about solution 1) My understanding is that it is not possible to run sketches saved on the SD.
about solution 2) send/receive data between shields (I assume you meant boards): that's exactly the point of my question.

How would you advice me to start looking to learn how to exchange communication (i.e. values of variables) between 2 boards?
Is the 12C the proper library to start with?

I know the easy solution to go would be to add a second-and-indipendent Yun to the system. But I'd rather be more stimulated and interested into using the Yun to connect to the internet, and one (or more-why not?) UNO to run activities and do the sensing...

You can plug the UNO to the yun just as you do with your computer.
On the yun, you need to

opkg update
opkg install kmod-usb-acm

Be aware: you'll run two boards with the same USB cable (the one from your pc to the yun). Hence, you'll likely run into power issues. Best is to plug a externally powered usb HUB to the yun and plug the UNO to the HUB

Once you do that you can
opkg install picocom then use it to interact with the Uno plugged into the host port on the Yun like you would with the serial monitor on the IDE. Start a serial or ssh session on the start picocom on then openwrt session.
This is just proof of concept, obviously you will want to automate. All the scripts for talking to the 32u4 from openwrt should work with a Uno with some modification. You will need to use /dev/ttyACM0 for the Uno instead of /dev/ttyATH0 for the 32u4.

Ok Guys thanks a lot! I think I'll have a lot to study next weekend... =(
I'm such a debutante...

Just few small questions to verify I've got all clear...

Federico:

You can plug the UNO to the yun just as you do with your computer.
On the yun, you need to
Code:
opkg update
opkg install kmod-usb-acm

Be aware: you'll run two boards with the same USB cable (the one from your pc to the yun). Hence, you'll likely run into power issues. Best is to plug a externally powered usb HUB to the yun and plug the UNO to the HUB

Those are commands I shall send through the terminal via the SSH connection right? (I'm a mac user).
About power issues... I suppose that any solution powering both boards independently will work fine, right?

Thank you also Noblepepper

Would you actually advise me following any tutorial, or example or sketch to run in order to try first some of these communications? I've quite tried looking for something about prior to posting, but nothing really relevant to this subject.

Thank you a lot for your advices!

Federico may contradict me since he has more direct information but I have not had any trouble plugging things like another Arduino (I have used a Due, Uno and Mega) or a USB pen drive into the USB host port. I really haven't pushed to see the limits but I don't think loading up the inputs will be a problem. If you start driving outputs that is a different story...

I believe motorized usb disk drives have been mentioned as definitely not a good thing.

Here is a interesting bit of info:
Before I plug a Uno into the host port of the Yun I get this in a terminal session (ssh or serial doesn't really matter)

root@Arduino:~# lsusb -v|grep Vendor
  idVendor           0x1d6b Linux Foundation
  idVendor           0x058f Alcor Micro Corp.
  idVendor           0x058f Alcor Micro Corp.
root@Arduino:~# lsusb -v|grep iProduct
  iProduct                2 Generic Platform EHCI Controller
  iProduct                1 USB2.0Hub
  iProduct                2 Mass Storage Device
root@Arduino:~# lsusb -v|grep idProduct
  idProduct          0x0002 2.0 root hub
  idProduct          0x6254 USB Hub
  idProduct          0x6366 Multi Flash Reader
root@Arduino:~# lsusb -v|grep MaxPower
    MaxPower                0mA
    MaxPower              100mA
    MaxPower              100mA

After I plug a Uno into the host port of the Yun

root@Arduino:~# lsusb -v|grep Vendor
  idVendor           0x1d6b Linux Foundation
  idVendor           0x058f Alcor Micro Corp.
  idVendor           0x058f Alcor Micro Corp.
  idVendor           0x2341 Arduino SA
root@Arduino:~# lsusb -v|grep iProduct
  iProduct                2 Generic Platform EHCI Controller
  iProduct                1 USB2.0Hub
  iProduct                2 Mass Storage Device
  iProduct                2 
root@Arduino:~# lsusb -v|grep idProduct
  idProduct          0x0002 2.0 root hub
  idProduct          0x6254 USB Hub
  idProduct          0x6366 Multi Flash Reader
  idProduct          0x0043 Uno R3 (CDC ACM)
root@Arduino:~# lsusb -v|grep MaxPower
    MaxPower                0mA
    MaxPower              100mA
    MaxPower              100mA
    MaxPower              100mA
root@Arduino:~#

Now I want to run picocom:

root@Arduino:~# opkg update
Downloading http://downloads.arduino.cc/openwrtyun/1/packages/Packages.gz.
Updated list of available packages in /var/opkg-lists/attitude_adjustment.
Downloading http://downloads.arduino.cc/openwrtyun/1/packages/Packages.sig.
Signature check passed.
root@Arduino:~# opkg install picocom
Installing picocom (1.7-1) to root...
Downloading http://downloads.arduino.cc/openwrtyun/1/packages/picocom_1.7-1_ar71xx.ipk.
Configuring picocom.
root@Arduino:~# picocom -b 115200 /dev/ttyACM0
picocom v1.7

port is        : /dev/ttyACM0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,


FATAL: cannot open /dev/ttyACM0: No such file or directory
root@Arduino:~#

Which tells a linux geek he needs to install the kmod-usb-acm module Federico already told us we need, so:

root@Arduino:~# opkg install kmod-usb-acm
Installing kmod-usb-acm (3.3.8-1) to root...
Downloading http://downloads.arduino.cc/openwrtyun/1/packages/kmod-usb-acm_3.3.8-1_ar71xx.ipk.
Configuring kmod-usb-acm.
root@Arduino:~# picocom -b 115200 /dev/ttyACM0
picocom v1.7

port is        : /dev/ttyACM0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,

Terminal ready

Wah lah, we are talking to the Uno! The problem is, it isn't talking to us. Use [CTRL] a x to exit picocom.

So I open up the Arduino IDE, set verbose output for both compilation and upload in under File->Preferences, select Arduino Uno under Tools->Board and then verify the Blink example with a couple of modifications:

/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.

  Most Arduinos have an on-board LED you can control. On the Uno and
  Leonardo, it is attached to digital pin 13. If you're unsure what
  pin the on-board LED is connected to on your Arduino model, check
  the documentation at http://arduino.cc

  This example code is in the public domain.

  modified 8 May 2014
  by Scott Fitzgerald
 */


// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin 13 as an output.
  Serial.begin(115200);
  pinMode(13, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
  Serial.println("On");
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
  Serial.println("Off");
  delay(1000);              // wait for a second
}

The last few lines at the bottom of the lower window in the IDE tell us:

/home/pep/Desktop/arduino-1.5.7/hardware/tools/avr/bin/avr-objcopy -O ihex -R .eeprom /tmp/build4193894950639761511.tmp/Blink.cpp.elf /tmp/build4193894950639761511.tmp/Blink.cpp.hex 

Sketch uses 2,506 bytes (7%) of program storage space. Maximum is 32,256 bytes.
Global variables use 196 bytes (9%) of dynamic memory, leaving 1,852 bytes for local variables. Maximum is 2,048 bytes.

The important bit is where it put Blink.cpp.hex, for me it is /tmp/build4193894950639761511.tmp/Blink.cpp.hex

Since I'm running linux I use scp to send it over to the Yun's file system:

pep@elbono-bigguy:~$ scp /tmp/build4193894950639761511.tmp/Blink.cpp.hex root@arduino.local:/root
Blink.cpp.hex                                 100% 7066     6.9KB/s   00:00    
pep@elbono-bigguy:~$

I have an ssh key set up for the connection, you will probably be asked for user (root) and password(whatever you set it to)

Back in the ssh session then:

Terminal ready

Thanks for using picocom
root@Arduino:~# ls /root
Blink.cpp.hex 
root@Arduino:~#

Now I'll flash it over the the Uno:

root@Arduino:~# avrdude -C/etc/avrdude.conf -patmega328p -carduino -P/dev/ttyACM0 -b115200 -D -Uflash:w:/root/Blink.cpp.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "/root/Blink.cpp.hex"
avrdude: writing flash (2506 bytes):

Writing | ################################################## | 100% 0.41s

avrdude: 2506 bytes of flash written
avrdude: verifying flash memory against /root/Blink.cpp.hex:
avrdude: load data flash data from input file /root/Blink.cpp.hex:
avrdude: input file /root/Blink.cpp.hex contains 2506 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.36s

avrdude: verifying ...
avrdude: 2506 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

root@Arduino:~#

Now when we use picocom to connect to the Uno we see:

root@Arduino:~# picocom -b 115200 /dev/ttyACM0
picocom v1.7

port is        : /dev/ttyACM0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,

Terminal ready
?On
Off
On
Off
On
Off
On
Off

Thanks for using picocom
root@Arduino:~#

The Uno is telling us when it turns the led on or off.

That's the closest I can give you to a tutorial. You'll need to have a script (Python seems the preferred choice on the Yun) to read your data from /dev/ttyACM0 and do what ever you want with it.

Very interesting. So now, the OpenWRT side is talking to the Uno through the USB port. Would it be possible now to start a second copy of the bridge script to talk over that port? Then run the bridge library on the Uno and have the same bridge communications with that board?

Of course, one issue is going to be how to handle REST API calls: when a request comes in to /arduino or /mailbox, which sketch would it get routed to? Hmmm... maybe this wouldn't be so easy... sounds like a lot of modifications...

Very good and complete explanation @noblepepper, thank you very much

ShapeShifter:
Very interesting. So now, the OpenWRT side is talking to the Uno through the USB port. Would it be possible now to start a second copy of the bridge script to talk over that port? Then run the bridge library on the Uno and have the same bridge communications with that board?

No, the UNO cannot act like the onboard 32u4. The onboard 32u4 is connected to the serial device the linux side uses for exposing its console. Bridge (arduino library) expects to have that console in order to start its python counterpart.

Linux and UNO can still communicate, though: on the linux side you need to use something like pyserial, opening /dev/ttyACMx just like any other serial port and start "chatting" with the sketch running on the UNO.

In essence, you're using your yun as a raspberrypi (linux side, usb cable, arduino board on the other side), so many tutorials out there could be easily adapted for the yun.

Ok Noble thank you very much again, I’ll definetly try this out over the Week end… or over night ]:smiley:
It’s literally the first time I’ll try something like this out I hope I’ll be able to manage at the first shot.

I’ll come back to you guys in some days…
L

This can be confusing at first, you will be running a openwrt console in a ssh session on your host which is running a terminal session that is talking to the Arduino connected to the USB port. After a while it clicks and make sense.

@Federico-I agree it won't work as it is now but nothing is impossible, the naysayers in the openwrt world were part of my motivation to get gcc running on the ar9331. It definitely would require a lot of work but /dev/ttyATH0 and /dev/ttyACM0 are just serial connections and are fairly interchangeable and the bridge libraries and sketches work fine on my UNO, MEGA and DUE when I connect them to the console on other ar9331 systems running the bridge packages. The work would be mainly in getting the bridge in openwrt to use /dev/ttyACM0. This isn't my itch though, someone else will have to prove you wrong.

Agree (and just learnt a new word, naysayer :wink: )

Actually the only reason (AFAIK) for the Bridge needing a linux prompt is to start the python side of the Bridge.
If it was already running (say started like a initd service or by rc.local, as some have reported in this forum) we didn’t need that prompt, hence any serial channel would suffice.

But here comes the original problem: memory consumption. Python has a slow startup and takes memory (megss, not gigas, but we got 64 of them and we have be wary)

I thought about converting the Bridge to a lua program many times, but I never convinced my self of its worth, not to mention the boss :slight_smile: