Go Down

Topic: Problem with HardwareSerial being too slow (Read 129 times) previous topic - next topic


I've been trying to implement a program on an Arduino UNO that samples AD values at 1 kHz and sends the acquired data via UART0 (USB) to a Raspberry Pi with a sufficient pySerial Interface.
My problem however is that the Serial.write command needs about 1 ms to execute, which is far too long because i try sampling with 1ms period and have to send out at least 4 bytes per ms, meaning at least 2 calls of Serial.write.

The code in v1.ino in the attachments was the first approach, where the problem appeared.

Since the overhead of the HardwareSerial class can't be neglegted i tried to configure the UART and all the other needed modules manually and implemented my own ISR.

Note that i made some improvements regarding GPS synchronisation from v1 to v2.
Unfortunately the last version doesn't seem to work at all.

To sum up the needed functionality of the program:
The Arduino receives a single byte representing the current run mode.
An auto-triggered ADC shall be executed every 1 ms.
For counting the Timer1 is used.
Timer1 is being reset by the PPS (pulse per second) signal of the GPS for synchronisation.
In mode '1' the result, aswell as a timestamp representing the expired ms,  shall be sent as uint16_t via USB.
In mode '2' the GPS Location is written to the port as 3 floats.

For the record: I don't own a oscilloscpe or logic analyzer to test the timer frequency or the UART ports

To view the output i use either my python interface or the screen packet on linux:

> screen /dev/ttyACMx y

where x is the Portnumber and y is the baud rate

I noticed that the data gets completly corrupted if i select baud rates higer than 115200 and even at 115200 i get corruption. At 38400 the data seems to be perfectly normal.

Thank you all for your help.


Just a question,
   Can the PI handle serial data that fast without flow control?
unless you have implemented Hardware flow control you could be overflowing the PI's input buffer and getting garbage. I know Windows :(  has problems with anything over 2400 baud of continuous data flows.  I had to implement RTS/CTS hardware flow controls for my Mega2560 projects to achieve reliable data transfers.


Checkout my latest Mega2560 Project on Kickstarter : Memory Panes


Hardware flow control shouldn't be needed.
I use the USB port of the raspberry and connect it with the USB port of the UNO, the series-USB converter converts the signal and pushes it on the UART0.
The converter should be able to handle at most 1MBaud.
The problem indicator is that i don't receive any input in my v2.ino.
If i transmit anything i see the RX LED illuminating so the converter chip isn't the problem, but something in my program.
Maybe some settings of mine are being overwritten by the standard libraries, but i see no indication for that being the case.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131