Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: Teensy 4.0 <-> Raspberry Pi 4 serial communication problems.

  1. #1

    Teensy 4.0 <-> Raspberry Pi 4 serial communication problems.

    Hi there,
    I've been struggling with this for quite some time now so hope someone might have an idea;
    I have a Teensy 4.0 hooked up with some RX/TX pins (Hardwareserial) through an FTDI converter into a Raspberry pi 4. Communication from the Teensy 4.0 to the Raspberry Pi 4 seem fine. Communication also seems fine when I use my laptop (macbook pro) to send serial commands to the Teensy over this FTDI connection by using this software called 'CoolTerm'.

    Though when I hook up the Teensy and Raspberry Pi together the communication TO the Teensy (Raspberry Pi -> Teensy) seems to halt untill the Raspberry Pi programme stops and everything seems to come in as one big dump of data. Feel like I'm missing something that might be obvious to some of you.

    I've got a lot of code running but here is at least the bit that runs the serial read-in; (Some Serial.prints for me to read out whats happening).
    void Comm::retrieve(HardwareSerial& serial, char* buffer, char* temp_buffer, unsigned int& buffer_index) {
        // Code heavily based on;
        while (serial.available() != 0) {
            Serial.print("retrieve serial");
            char rc =;
            if (rcInProgress == true) {
                if (rc != endMarker) {
                    buffer[buffer_index] = rc;
                    if (buffer_index >= 128) {
                        buffer_index = 127; // Safety for memory overflow
                } else {
                    buffer[buffer_index] = '\0'; // terminate string
                    rcInProgress = false;
                    buffer_index = 0;
                    parseData(serial,temp_buffer); // Parse data to the right location.
            } else if (rc == startMarker) {
                rcInProgress = true; // Start receiving block of data

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Are you using the Arduino serial monitor to view the data on Raspberry Pi? Or some other software?

    If it's custom written code, you might be facing a unix line discipline problem because the Linux serial port does not default to raw mode.
    Last edited by PaulStoffregen; 04-24-2020 at 03:10 PM.

  3. #3
    It's running a custom application written in C++ using OpenFrameworks. So there is basically a similar structure running on the Raspberry Pi as on the Teensy. Here's some documentation on their embedded serial class;

    If this is a 'unix line discipline problem' how would I go about fixing it? Appreciate the help

  4. #4
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    The first things I would do is to have simple sketch on Teensy, that maybe simply dumps the messages as it receives them, maybe with some form of time stamp.

    Again I don't see any sources here to try out, so don't know what you are trying or ...

    With many frameworks and the like they often write to some internal buffer and only send data when the logical buffer is filled or when there is a timeout.
    There is always an interesting trade off between throughput and latency...

    I know from the past that FTDI usb to serial adapters can have a high latency. With Windows you can use the device manager and go to the device properties and update how much latency.

    Don't remember how much this can be set on Linux. I have not used your framework before. I have gone directly to setting stuff with termios. It has been awhile since I played with it much,
    but I remember that for example when I am running code to control servos, where I send a command and then wait for a response, that when I was using an FTDI Serial port /dev/ttyUSBx I would often use the drain (tcdrain with termios) to force the system to send the data now. However I also found that in many cases when what I am sending the data to (like a Teensy) and it is instead using a device like /dev/ttyACMx I found that calling tcdrain really slowed down the program. It was like the underlying device driver did not have support for the IOCTL to do the drain so instead it just did a long sleep operation.

    Good luck

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts