I set up Arduino to write to the serial port (sudo ln -s /dev/ttyMCC /dev/ttyS0) and loaded this simple script to test write speeds: void setup() { Serial.begin(9600); delay(1000);} void loop() { Serial.println("testing!"); delay(5);} In Udoobuntu I ran this Python script to test reading: import serial import time print 'opening connection...' ser = serial.Serial( port='/dev/ttyMCC', baudrate=9600, timeout=1)time.sleep(2) print 'buffer size', ser.inWaiting() print 'reseting buffer...' ser.flushInput() print 'buffer size', ser.inWaiting() print 'fetching 10 readings...' for i in range(10): r = '' while '\r\n' not in r: r += ser.read(1) print r.strip()print 'buffer size', ser.inWaiting() The script ran as expected and Python fetched 10 messages instantly. However, after rerunning and reflashing the scripts a few times the serial port seems to slow down and the Python script can take minutes to fetch the same 10 messages. Have others had inconsistent performance with serial? Can anyone confirm the same behaviour?
Yes! With your delay of 5 (ms) you will overflow the serial buffer. Also use the correct Python serial library. The one that is in Udoobuntu 2 RC2 is the correct one (python-serial). Do not use pyserial! See also http://www.udoo.org/docs-neo/Debugging_&_Troubleshooting/USB_stops_working_after_programming_M4.html
Thanks Walter, will try the other serial lib. Is it actually explicitly bad to hammer the serial connection from the M4? I was hoping to use serial as high speed write only from M4 and then selectively read it from Linux. This actually works fine a lot of the time, even when the buffer is completely full (~4096 bytes). It's only sometimes the process fails. The link you sent implies this will not work. I don't understand the comment about 10 buffers though. The ultimate goal is to read the motion sensors as fast as possible at a known frequency (hence using M4) and then make that data available at high frequency to Linux.
The serial device between A9 and M4 has been improved in the last Udoobuntu version. The text in the docs refers to an older version. So stability has improved but we still see the issues you are referring to. See also this issue on the github linux kernel repository https://github.com/UDOOboard/linux_kernel/issues/14
Thanks. BTW, serial examples, e.g. https://github.com/UDOOboard/serial_libraries_examples/blob/master/python/python_serial_example.py, show to use pyserial. Is there an example with python-serial in use?
It does not matter in usage in the python program. Only the libraries behaves different. See this thread http://www.udoo.org/forum/threads/pyserial-error-with-udoo-neo.3294/#post-16063
For now at least, I've given up on the Arduino emulation, and turned the M4 off altogether. Getting sensor data via Sys FS like this for the barometric brick ("/sys/class/i2c-dev/i2c-1/device/1-0060/iio:device2/in_pressure_raw") is trivial and 100% reliable. I wrote a simple program in C to read the movement sensors and even running full-tilt (no "sleep()" calls) it produced data as fast as the machine could deliver it. Unless you're using the Neo as a development platform for stand-alone Ardunio shields (which it is good at) you're better off disabling the M4 and using the sensors/ADC/GPIO from via the A9. This is an early (console) version which I've developed into a logging one - but you can see that this is easy and reliable. Try adjusting the sleep timer (or even deleting it) and you can see just how fast this is! /* Udoo Neo Gyroscope/Accelerometer Demo (alpha) Copyright (C) 2016 Marc Draco This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ #include <stdio.h> #include <unistd.h> typedef struct { int x; int y; int z; } Coordinates; void readData(Coordinates *pCoord, char *sensor) { FILE *fp; fp = fopen(sensor,"r"); if (fp == 0) { return; } fscanf(fp,"%d,%d,%d",&pCoord->x, &pCoord->y, &pCoord->z); fclose(fp); } int main (void) { Coordinates coords; Coordinates gyroBase; Coordinates accelBase; readData(&gyroBase, "/sensors/gyroscope/data"); readData(&accelBase, "/sensors/accelerometer/data"); while(1) { readData(&coords, "/sensors/accelerometer/data"); printf("ACC: X:%+7d, Y:%+7d, Z:%+7d\t",(accelBase.x-coords.x)/1,(accelBase.y-coords.y)/1,(accelBase.z-coords.z)/1); readData(&coords, "/sensors/gyroscope/data"); printf("GYR: X:%+7d, Y:%+7d, Z:%+7d\n",(gyroBase.x-coords.x)/1,(gyroBase.y-coords.y)/1,(gyroBase.z-coords.z)/1); usleep(10000); } }
Is it possible to (and are there any guides or info on) accessing the Udoo's motion sensors externally, e.g. from a standalone Arduino and NOT the onboard Arduino or Linux? If so, I presume this would bypass any Udoo serial issues.
The problem seems to be the Arduino part and the serial between Linux and Arduino side. Standard the sensors are attached to the Linux side and you shouldn't have any problems to handle the data within Linux.
Thanks Walter. I meant more along the lines of it possible to use the sensors from a completely external, standalone Arduino, via say I2C on pins 10/12 & 18/20? If so, would that be subject to the serial issue?
I don't think so if it could be possible. But where do you need the data? In your original question you need the data on linux as fast as possible. And then? What are you going to do with it? If you need the data in Linux you just use the script IHG wrote and use the data coming out.
I was aiming to read data from the motion sensors from within (an) Arduino so that the time step between reads are repeatable and known accurately (to minimise errors when doing calculations based on the data). Reading straight from Linux wouldn't be as accurate (with respect to time) and there's no guarantee it will run in real-time. Given the current issue with the onboard Arduino I was hoping to use the same sensors but use an external Arduino just for some basic tests.
You could also send the data from Arduino out with serial0 which is a proper serial no virtual. Serial0 is connected to pin 0 and 1 so you have to use a TTL to Usb device to read it on your pc.
Newsflash! In the next Udoobuntu version the serial connection with Arduino will be updated. http://www.udoo.org/forum/index.php?posts/20205
Well, the Arduino update is released but it is not helping a lot with this issue yet. Perhaps we have top wait for the Udoobuntu update to have it solved. I did a sudo apt-get update & upgrade and a complet powerless shutdown and restart. For udoo team: I have the following sketch giving some data every second: Code: void setup() { Serial.begin(115200); delay(100); } void loop() { // Print out the data // Accelerometer Serial.print("Accel "); Serial.print("X: "); Serial.print("2121"); Serial.print(" Y: "); Serial.print("2122"); Serial.print(" Z: "); Serial.println("2123"); // Magnometer Serial.print("Mag "); Serial.print("X: "); Serial.print("2124"); Serial.print(" Y: "); Serial.print("2125"); Serial.print(" Z: "); Serial.println("2126"); delay(1000); } When reading by Arduino Serial monitor or Minicom I get missing data, even missing complete lines!! What I noticed is that CPU runs at 100% at the moment I start Serial Monitor or Minicom. When I used Minicom I had no Arduino IDE open, only used Minicom -D /dev/ttyMCC I didn't see a process in TaskManager that uses the CPU, when I count the running tasks I come to approx. 25% including root tasks. Example of my output: Accel X: 2121 Y: 2122 Z: 2123 Mag 2126 Accel X: 2121 Y: 2122 Z: 2123 Mag X: 2124 Y: 2125 Z: 2126 Accel X: 2121 Y: 2122 Z: 2123 Mag X: 2124 Y: 2125 Z: 2126 Accel X: 2121 Y: 2122 Z: 2123 Mag X: 2124 Y: 2125 Z: 2126 Accel X: 2121 Y: 2122 Z: 2123 Mag X: 2124 Y: 2125 Z: 2126 Accel X: 2121 Y: 2122 Z: 2123 Mag Accel X: 2121 Y: 2122 Z: 2123 Mag X: 2124 Y: 2125 Z: 2126 Accel X: 2121 Y: 2122 Z: 2123 Mag X: 2124 Y: 2125 Z: 2126 Accel X: 2121 Y: 2122 Z: 2123 Mag Accel X: 2121 Y: 2122 Z: 2123 Mag X: 2124 Y: 2125 Z: 2126 Accel X: 2121 Y: 2122 Z: 2123 Mag Z: 2126 Accel X: 2121 Y: 2122 Z: 2123 Mag X: 2124 Y: 2125 Z: 2126
We get the same problem with this test. We're working on the stability of the reloading of the sketch. Probably something is broken right now.
Well, I had no issue with reloading sketches. I had issues with reading /dev/ttyMCC. But if you now also have issues with reloading sketches it would be nice if this was fixed too.....
