Connecting Raspberry Pi to Teensy 3.2

Status
Not open for further replies.

sixeight

Well-known member
IMG_20171024_113820964.jpg

I am having trouble getting a Raspberry Pi and a Teensy 3.2 to talk MIDI to each other. Well actually it works fine when I connect the raspberry pi to Serial1 or Serial2 via a full midi circuit (optocoupler on both Tx and Rx in both directions). But Serial3 seems to give me trouble. This port is connected directly as shown in the image above) I am losing data along the way. I should be receiving messages of 153 bytes, but half the time they are shorter.

Because I have ready made PCB's for my project, it is difficult to swap uart ports. I am trying to determine where I should be looking. Because most solutions require messing up my board.

1) Is Serial3 (UART) different from serial1 and serial2 when it comes to sending midi data? Could it be that serial 3 is suffering from data loss, because the loop time is getting too long?

2) Because both the Teensy 3.2 and the RPi work at 3.3 volts, I have the Tx en Rx of both units connected directly. Is this OK or do I need some sort of buffer in between?

Any suggestions are welcome.
 
IIRC, Serial3 on the Teensy 3.x has no FIFO, opposed to Serial1 and Serial2. This might explain the data loss, especially if the Teensy is the receiver and you don't do Serial3.available() often enough to pick up the incoming bytes before something saturates and bytes get lost. Which baud rate are you using, the default midi baud rate (31250) or something higher?

On pure 3.3V systems, a direct connection of the UART pins won't harm, but think not only of crossing RX-TX but to make a ground connection between both systems, too.
 
Try editing serial3.c to increase the receive buffer. Maybe also increase the interrupt priority (lower numbers = higher priority).
 
Changed the Contents/Resources/Java/hardware/teensy/avr/cores/teensy3/serial3.c file inside the Arduino program object. Tried setting the receive buffer to 256 and the interrupt priority to zero. But it does not seem to make any difference.

@Therimingenieur. The communication is at normal 31250 midi baud rate and I have power including ground running to the Raspberry Pi as well.

Speeding up the loop is tricky. I have already done several optimization rounds. How short does the loop time have to be? If I have to catch every byte, like 31250 bit/s = 3906 byte/sec. So a loop time of 256 microseconds? That is mission impossible...
 
I didn't say that speeding up the loop was the only way to solve the problem... Unfortunately you did not post any code which would help to understand what happens... A bigger receive buffer might help too, always under the condition that it is read and thus emptied before it overflows.

And a loop time of 256us is more than generous. On a Teensy 3.2@96MHz, this corresponds to 24576 clock cycles - enough to calculate complex waveforms in real time...
 
I didn't say that speeding up the loop was the only way to solve the problem... Unfortunately you did not post any code which would help to understand what happens... A bigger receive buffer might help too, always under the condition that it is read and thus emptied before it overflows.

And a loop time of 256us is more than generous. On a Teensy 3.2@96MHz, this corresponds to 24576 clock cycles - enough to calculate complex waveforms in real time...

Here is a link to my code: https://github.com/sixeight7/VController_v3/tree/master/Firmware/VController_v3

The low level midi stuff is in MIDI.ino.

The VController project has 13 character displays, 16 buttons connected via i2c, 3 serial midi ports, usbMidi and 12 neopixel LEDs. And when something happens, everything has to be updated. Loop time is very unpredictable. Usually it is under 256 us, but it does flare upwards whenever I press a button.
 
The VController project has 13 character displays, 16 buttons connected via i2c, 3 serial midi ports, usbMidi and 12 neopixel LEDs. And when something happens, everything has to be updated. Loop time is very unpredictable. Usually it is under 256 us, but it does flare upwards whenever I press a button.

Ah, you didn't tell before that there were more things do... ;)

Perhaps a different programming model, only processing the midi stuff in real time, but queueing somewhere the button presses as well as the display and neopixel update requests and processing that queue only while nothing happens on the midi in front could be helpful?
 
Status
Not open for further replies.
Back
Top