Tty for serial port to Arduino from Linino

[wayoda]

The Arduino UART should definitely do 250000 , and higher. And since the hard-wired serial connection is very short, there shouldn't be any signal degradation issues.
Maybe you have a marginal board. I will give it a go tonight and let you know results. If necessary we can look at the UART registers for over-run or parity errors....

I tried everything to create a bad environment for the Yun to provoke an error at 115200 baud...
- Wind an active Lan-cable several times round the Yun
- Place the Yun on to of my cellphone, and call myself
...but the python script runs without problems

Raise the speed to 250000 and it fails .

BTW:
Sketch programming from the Yun side (not over USB) does not use the serial port. It uses the avrdude -c linuxgpio option which emulates a SPI programmer. See file /etc/avrdude.conf line 976
 

[wayoda]

Hi,
there is a serious problem with my little echo sketch on the ATmega.

The changes in /etc/inittab detach the serial line to the ATmega, but this happens very late in the boot process.
Until just before the login prompt for the shell is shown, all kernel messages are still forwarded to the ATmega.
Because my test sketch more or less echos what is read from the serial, the  boot process seems to be stopped by the random data coming back over Serial1.
The effect is that because of the echo sketch the WiFi setup never completes. Login over ssh is [font=Verdana]not possible[/font].

When the simple Blink Sketch or even the Yún Serial Terminal runs on the ATmega the Yun boots fine because these Sketches don't throw any random data back at the linux machine. If you are stuck like that because you tried the test at home, simply upload a Sketch not writing to Serial1. http://arduino.cc/en/Tutorial/YunSerialTerminal

For an application using the Serial1 to communicate with the ATMega this means, you are only allowed to listen on the Serial1 until the Linux machine was sucessfully booted.
 

[scrot]

If you look in the Bridge.cpp source code you'll se that they deal with this.

Code: [Select]

// Wait for U-boot to finish startup
  do {
    dropAll();
    delay(1000);
  } while (stream.available()>0);

This doesn't seem very fool proof.  Its counting on the fact that during the boot process you see some data at least once per second come over serial.  If there was a > 1 sec pause then you'd be out of luck.

I'd be happy to see a robust code snippet I could insert into my sketches.

Good catch.

[priority]

Hmmm....I have used the serial console of the early boot process before to debug a bad dd-wrt (openwrt fork) image on a router. I suspect that this "feature" is enabled by default in the openwrt build process since this is a relatively good way to unbrick a board with a corrupt flash image.

A bootlog for linino is at:  https://github.com/arduino/linino/blob/master/docs/hardware/danube/bootlog.  There are several opportunities that echoing the console is not a good idea!

Took a bit of digging, but it appears the only way to stop the "terminal chatter" early in the boot process is to rebuild the kernel to disable "Early printk".  Not something that most folks (including me) will be excited about for many reasons.   Seems like the best workaround is exactly what scrot and wayoda are doing: find a way to make sure the 32u4 does not respond to this "terminal chatter".

[federicofissore]

Indeed, disabling printk doesn't seem a very good idea: I fear we may lose dmesg output, making device debugging (wifi in particular) impossible

[noblepepper]

Just a warning to the wise, it looks like this breaks the WiFi reset button, re-enabling

Code: [Select]

ttyATH0::askfirst:/bin/ash --login in /etc/inittab makes it work again.

If you lose your Yun this way check out my post about "is my WiFi dead?"

[wayoda]

Hi,
I had a little accident in my workshop, so I will not be able to do any serious work with my yun, but I took some time to read the whole documentation that is available, and there might be a nice way to signal the atmega when the linux machine is available. The original Yun docs mention a heartbeat line from the mips-processor (GPIO 19) to the arduino Pin 7.

I should be possible to write a Linux Init-script that switches this handshake to a certain state when the Linux part is fully booted and the Console is free to use for an application. The same is possible for situations where the Linux part is shutting down or in a Reboot.

An Arduino Sketch would simply have to monitor Pin 7 and thereby knows when serial IO with som Python code is possible.
One-handed typing is a bit arkward, so here are just the references:
http://arduino.cc/en/Main/ArduinoBoardYun
http://arduino.cc/en/uploads/Main/arduino-Yun-schematic.pdf
in both document search for "handshake"

[federicofissore]

While you are investigating on your own, do you mind opening on issue on https://github.com/arduino/YunBridge ? This is pretty cool stuff and it would be a shame to forgot it just because we are stuck with other tasks at the moment

[mundosimaginados]

It works for me... thank you. I've working on that and at the end you gives the solution.

I got Firmata to work between a Python script running on Linino and the Arduino.  I was able to get about 400 messages per second which is sufficient for my needs.  I made the following changes to the StandardFirmata sketch "begin" section.

Code: [Select]

void setup()
{
 
  Firmata.setFirmwareVersion(FIRMATA_MAJOR_VERSION, FIRMATA_MINOR_VERSION);

  Firmata.attach(ANALOG_MESSAGE, analogWriteCallback);
  Firmata.attach(DIGITAL_MESSAGE, digitalWriteCallback);
  Firmata.attach(REPORT_ANALOG, reportAnalogCallback);
  Firmata.attach(REPORT_DIGITAL, reportDigitalCallback);
  Firmata.attach(SET_PIN_MODE, setPinModeCallback);
  Firmata.attach(START_SYSEX, sysexCallback);
  Firmata.attach(SYSTEM_RESET, systemResetCallback);

  Serial1.begin(9600); // Set the baud.
  Firmata.begin(Serial1);
  systemResetCallback();  // reset to default config
}

On the python I installed PyFirmata and pyserial.  The following code turns on the LED:

Code: [Select]

from pyfirmata import Arduino, util
board = Arduino('/dev/ttyATH0', baudrate=9600)
board.digital[13].write(1)


[scrot]

Thanks for the update.  Here's my Firmata setup().  Its very similar to yours.  The only difference is a section to wait for the U-boot to complete, and I set the baud to 115200 which works like a champ.  I stole the U-boot section from Bridge.cpp.

Code: [Select]

void setup()
{
  Serial1.begin(115200); // Set the baud.
 
   // Wait for U-boot to finish startup.  Consume all bytes until we are done.
  do {
     while (Serial1.available() > 0) {
        Serial1.read();
        }
   
    delay(1000);
  } while (Serial1.available()>0);
 
  Serial.begin(9600); // For logging.
 
  Firmata.setFirmwareVersion(FIRMATA_MAJOR_VERSION, FIRMATA_MINOR_VERSION);

  Firmata.attach(ANALOG_MESSAGE, analogWriteCallback);
  Firmata.attach(DIGITAL_MESSAGE, digitalWriteCallback);
  Firmata.attach(REPORT_ANALOG, reportAnalogCallback);
  Firmata.attach(REPORT_DIGITAL, reportDigitalCallback);
  Firmata.attach(SET_PIN_MODE, setPinModeCallback);
  Firmata.attach(START_SYSEX, sysexCallback);
  Firmata.attach(SYSTEM_RESET, systemResetCallback);

  Firmata.begin(Serial1);
  systemResetCallback();  // reset to default config
}

[GreyCon]

Hi,
  I use the Linino to handle REST Web Services, and JSON data. These services talk to an API layer, which maps the JSON data to "device level" calls, which my Arduino understands. (Eg replace Timers for Monday, read all timers, etc.)

This API layer takes a sequence of bytes (A private command or the Arduino API), wraps it in a frame (SOM BYTE, frame datalen, DATA, EOM, and Checksum) and sends it to the Arduino over the serial port.

I have a C++ class (YUNListener) on the Arduino which waits for SOM, parses the data, ensures there's an EOM, and validates the Checksum. So ant comms errors, or other unwanted / unexpected incoming data on the serial bridge are discarded. The C++ class has 2 Virtual methods, which do nothing in the base class, but are designed to be over-ridden in real subclasses. (Eg TimerListener : YUNListener)

The methods are:
1. handleCommand( data ) which you can implement, and will be given a correct byte array from incoming commands.
2. debug( data ) which will be called at various points in the command parsing process. I use this method to check for an input pin being pulled high, and if it is, I output serial debugging info to an output pin . So I have a cable that connects the output pin to a serial terminal, and straps the other pin high. So I automatically get debug output when I connect the cable to my laptop.

Happy to supply the code if anyone is interested.

[scrot]

Please show us the code, or post a link to GitHub.  I'd be very interested in seeing your code.  Its probably simpler than Firmata which would be great.

[GreyCon]

No problem, it will be tomorrow or thursday night before I am home and able to upload it. I have never actually put code on Github but how hard can it be :-)

[GreyCon]

Hi,
  sorry for the delay. I have the arduino code running just fine (It was already running on another Arduino) but I have been in a rabbit-hole trying to get C code to cross-compile for the Yun. Anyway, I have it working now.

So, I will finish off the Linux part of the protocol classes, and put them on Github. Hopefully this weekend.

Cheers,
Con

[violinuxer]

Hi everybody!

Sorry if I'm necroing this post... just wanted to add my 2 cents and confirm that things don't work well at 250k baud.

I too have been working on bypassing the Bridge library which (in my experience) is VERY slow. With regards to the baud rate, I agree that 250k baud seems awfully high. I also had trouble with dropped characters at that rate when reading them on the device. What if it's purely a matter of CPU Speed? At a rate like 250k baud, the CPU shouldn't have much time to empty the UART buffers before they overflow. Might the dropped characters just be lost in a buffer overflow because the CPU cant quite keep up?

Anyways, I disabled the tty and connected at 115k. It works great

violinuxer