Tty for serial port to Arduino from Linino

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

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.

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

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

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: linino/bootlog at master · arduino/linino · GitHub. 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".

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

Just a warning to the wise, it looks like this breaks the WiFi reset button, re-enabling
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?"

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:

in both document search for "handshake"

While you are investigating on your own, do you mind opening on issue on GitHub - 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

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

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

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:



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

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.

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
}

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.

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.

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 :slight_smile:

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

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 :slight_smile:

violinuxer

What do you exactly mean by you disabled tty?
Thought tty is required for Bridge.

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.

Sounds promising.
Anything to share?

Maybe someone following this thread can help me regarding my problem posted over there: WebSockets with Yun? - #38 by mamu - Arduino Yún - Arduino Forum

mamu:
What do you exactly mean by you disabled tty?
Thought tty is required for Bridge.

Sorry about the confusion... let me clarify.

I'm attempting to get real time data from an I2C sensor that I want to send to a computer over Wi-Fi. I attempted to use the Console class to send data from the microcontroller to the Linino processor. It was reliable and all, but it was WAY too slow (it sent only 2 or 3 samples per second). I then decided to bypass bridge altogether and write a very simple Serial to TCP Bridge using pyserial. Without bridge enabled, I could send values to the linux processor via Serial1 (at 250k baud) to the shell quite quickly, but there were many issues with dropped characters because of the high UART speed. I disabled the tty in inittab so I could set my own baud rate for communications, after which the transmission worked great.

To everybody else:

Does anyone know how to change the tty baud rate at boot time? The speed appears to be coded into the kernel args. Do I have to build my own kernel to change the speed? Is there a file somewhere I can edit?

Also, I would love it if future releases of Linino adopt a 115k baud TTY speed as it appears to be MUCH more stable.

Anyways, thanks for all the help!

violinuxer

Thanks for the clarification.
Could you share your python code?

BTW: Does it count whether one connects Yun via USB and uses TTY from IDE or WiFi only? Looks like when doing Serial1.println() Serial Monitor throws back something from BuysBox:

@arduino:/# 
oot@ arduino:/# ->test=[[1,2],[3,4]]
sh: -: not found

Where "->test=[[1,2],[3,4]]" is my data.

wayoda:

GreyCon:
Hi Wayoda,
when you say a BAUD rate of 250000 fails - do you get characters from Serial, or nothing at all?

The python script writes 32 chars to the ATmega and then reads 32 bytes with a five second timeout.
When used with baudrates above 115200 the read returns unexpected characters and also too few of them.

I can confirm this. At 250k, characters are sent, but it drops characters pretty often. At 115200 and below, it works great.

violinuxer