Will using one serial interface for sending and one for receiving make any difference

Status
Not open for further replies.

alexandros

Well-known member
I'm building a project where I use a Teensy 3.2 and an Odroid-XU4 where there is data exchange between the two. I'm reading quite a lot of potentiometers (could sum up to more than 30 at times) plus using input and output shift registers and I'm sending data from the Teensy concerning digital and analog input, but the Teensy also receives data to light up LEDs. When an LED is supposed to blink quite fast (about 100 ms, not exactly sure, maybe longer than that), the result is not as stable as it should be.
I'm thinking of using a hardware serial interface to send data from the Odroid to the Teensy. Will that make any difference? If so, using Serial1 will have the same effect as using Serial2? I think Serial1 is the same port as Serial, or am I wrong?

I'm not posting the code because it's pretty big (over 600 lines). If anyone wants to take a look, it's here https://github.com/alexdrymonitis/3...e/modular_synthesizer/modular_synthesizer.ino

Thanks
 
I think Serial1 is the same port as Serial

They're definitely not the same! Serial1 is hardware serial which communicates on pins 0 & 1. Serial is the USB virtual serial, which communicates over the USB port to your PC or Mac (or Odroid or whatever other USB host is programming or using the Teensy).
 
They're definitely not the same! Serial1 is hardware serial which communicates on pins 0 & 1. Serial is the USB virtual serial, which communicates over the USB port to your PC or Mac (or Odroid or whatever other USB host is programming or using the Teensy).
Ok, didn't know that. Will using Serial to send data to a computer and Serial1 to receive data take off some load of the serial communication? Or will it be exactly the same as using one serial interface both for sending and receiving?
 
Not sure what you are asking?

As Paul mentioned Serial uses the USB port, talks to Odroid, by who creates a device like /dev/ttyACM0.
Serial1 is a hardware UART. Note I have used this port to talk to ODroid from some of my Hats I created for RPI form factor, where I can talk to a hardware UART on an RPI or UP or Odroid C1/C2...

With XU4, there are a couple of issues. One the expansion connector(s) are different AND the signals are 1.8v whereas the Teensy is 3.3v....

You can (and I have) connected up an RPI hat if you use the Odroid XU4 level shifter: https://www.hardkernel.com/main/products/prdt_info.php?g_code=G143556253995
I have not done this in awhile as :eek: I converted the Odoid XU4 to an XU4Q and tried to use the level shifter. As the heat sink is real tall, I tried setup using a couple of connector extenders... They shorted out and that XU4 is toast... Still have another one, but... Actually right now more geared toward using UP boards...

It has been awhile since I played with their hardware, so don't remember what /dev/tty? Should be somewhere in their WIKI. Also there is a second UART available on the board, that again is 1.8V and they sell a UART module https://ameridroid.com/products/usb-uart-module-kit2 which you can use to plug it into another USB port... You could also hook this up using a TTL level shifter.

But will this help your performance? Hard to say. I was experimenting with it to have it talk to the Teensy (Either 3.2 or 3.6 version), where I then had the teensy driving the servos. I did this as a way to hopefully remove some USB latency issues and or inconsistent timings. That is if the USB was busy doing other things (talk to camera, wifi, ...) then the timings to get a packet out to the servos and get their response was not always as fast as I wanted or as consistent in timings...
 
I guess I wan't clear enough. I can use Serial1 with a serial to USB converter, so I can use both Serial and Serial1 with my computer as a test. I'm just wondering if this technique would help with my Teensy not being very responsive when it receives data from the Odroid. Maybe the issue lies elsewhere (for example the protocol the two devices use to talk to each other).
Maybe I should put the question in another way. The Data+ of the USB only sends data from the host and the Data- only receives data in the host? I mean, these two lines are unidirectional, so the Teensy will send its data on one line only and receive data only on the other line?
 
Simple part of the question: No D+/D- are not read/write, but are actually the same signal, but one is the negative value of the other.
lots more info up on the web, like: https://en.wikipedia.org/wiki/USB#Electrical_specification

When it comes to USB, I am now somewhat less of a novice knowledge wise than I used to be, but I have only scratched the surface... So hopefully someone like Paul can give a more complete answer.

You might try it and see if it helps you. What I found with the Odroid earlier (and some other boards). is that when you have several USB intensive things going on, USB was a bottleneck. It sort of acts like all of the USB 2 connections are on a single TT (not multi TT) type connection, so sort like only one thing going on at a time. Also the Network (ethernet) connection was also funneled through the same connection.

As for will adding USB to serial adapter to talk to Teensy help? I have my doubts. It might. What I found did help was to experiment on where I plugged in the devices. That is I believe the USB3 and USB2 connectors are on two different paths inside the processor. So try to split up where things might connect, to see if that helps. ...
 
Thanks for the explanation. I was asking because in order to try I need to print a circuit board first (trying out on a breadboard or a perforated one will just be hell), so I was hoping to get some information before I go on and make this. Since the D+ and D- lines are not independent, I think I'll give a try to use Serial1 with a serial to USB converter and use Serial for sending data from the Teensy to the Odroid and Serial1 for the inverse communication. I'll come back with results, but it might take some time.
 
I can use Serial1 with a serial to USB converter, so I can use both Serial and Serial1 with my computer as a test. I'm just wondering if this technique would help with my Teensy not being very responsive when it receives data from the Odroid.

I'm going to with "no, probably not" as a blind guess answer.

I guess I wan't clear enough.

Can you understand you've asking us to diagnose a responsiveness problem where the only info we have is a Teensy and Odroid communicate over USB serial. We don't know anything about what code is running on either side, how much data is flowing in either direction, whether you've structured the communication in a streaming manner or as query-response or some other way.

You mentioned an LED blinking every 100 ms, and you're using lots of analog inputs and shift registers, but that's the extent of what we know. You've said things aren't responsive, but we don't even know what you're specifically observing that isn't "responsive".

Over and over again, we've heard & answered questions on this forum about USB serial communication performance issues. Too much latency with command-response communication is the most common problem. If your approach involves code on the Odroid sending a command or query and waiting for Teensy to respond before it does anything else, you're never going to achieve good performance. You can make an improvement by using Serial.send_now() after you've used Serial.print() or Serial.write() to send the reply.

However, that advice applies to reducing latency for query-response. It's exactly the *wrong* thing to do if you're limited by bandwidth, since it causes Teensy to send a partial USB packet rather than efficiently stuffing your next Serial.print() into the remainder of the USB packet for best bandwidth utilization. If you're trying to maximize bandwidth, rather than minimize latency, then an approach where you never wait for replies and keep sending more data frames can really help.

But if you're sending a lot of data (over 100 kbytes/sec) in *both* directions simultaneously, then a whole different set of trade-offs matter. In those cases, structuring your code to limit how much it transmits before receiving whatever has recently arrived can make a huge impact.

So can you understand how in the dark you're keeping us? There isn't any one piece of advice that fits every situation. We know almost nothing about what you're really doing. Without understanding the problem, the best help anyone can give is pretty limited and may even be the wrong advice for your circumstances.
 
I'm going to with "no, probably not" as a blind guess answer.



Can you understand you've asking us to diagnose a responsiveness problem where the only info we have is a Teensy and Odroid communicate over USB serial. We don't know anything about what code is running on either side, how much data is flowing in either direction, whether you've structured the communication in a streaming matter or as query-response or some other way.

You mentioned an LED blinking every 100 ms, and you're using lots of analog inputs and shift registers, but that's the extent of what we know. You've said things aren't responsive, but we don't even know what you're specifically observing that isn't "responsive".

Over and over again, we've heard & answered questions on this forum about USB serial communication performance issues. Too much latency with command-response communication is the most common problem. If your approach involves code on the Odroid sending a command or query and waiting for Teensy to respond before it does anything else, you're never going to achieve good performance. You can make an improvement by using Serial.send_now() after you've used Serial.print() or Serial.write() to send the reply.

However, that advice applies to reducing latency for query-response. It's exactly the *wrong* thing to do if you're limited by bandwidth, since it causes Teensy to send a partial USB packet rather than efficiently stuffing your next Serial.print() into the remainder of the USB packet for best bandwidth utilization. If you're trying to maximize bandwidth, rather than minimize latency, then an approach where you never wait for replies and keep sending more data frames can really help.

But if you're sending a lot of data (over 100 kbytes/sec) in *both* directions simultaneously, then a whole different set of trade-offs matter. In those cases, structuring your code to limit how much it transmits before receiving whatever has recently arrived can make a huge impact.

So can you understand how in the dark you're keeping us? We know almost nothing about what you're really doing. There isn't any one piece of advice that fits every situation, and there's only limited help anyone can give you when they have to blind guess what's causing the responsiveness problem you're seeing.

Instead of providing an over 600 lines of code sketch, I provided a link to GitHub where I have my project. I know my question was very broad, and eventually I'm going to give a try to using two serial interfaces as a trial and error approach. With your response you do provide some technical information that I wasn't aware of, and thank you. Still, I don't thing I could provide much evidence here, it's a rather large project, it's a whole physical modular synthesizer running on an Odroid and a Teensy.

Thank you both for your answers.
 
Is the code doing serial communication from the Odroid side a huge puredata patch?

If so, I would recommend switching to USB MIDI protocol instead of USB Serial. Many people using puredata report MIDI protocol works much better. It might have something to do with the interaction of message buffering in the kernel drivers and latency added by Pd's update rate, especially if your patch is doing heavy work while also trying to communicate.
 
Is the code doing serial communication from the Odroid side a huge puredata patch?

If so, I would recommend switching to USB MIDI protocol instead of USB Serial. Many people using puredata report MIDI protocol works much better. It might have something to do with the interaction of message buffering in the kernel drivers and latency added by Pd's update rate, especially if your patch is doing heavy work while also trying to communicate.

It is a Pd patch indeed. I don't seem to have an y issues with the data received in the patch, only with the data sent, and that only when some data are sent repeatedly at a rather high rate. I know this information is vague again, not really sure about the bytes per second sent and received.
Also, I wouldn't want to use MIDI to receive potentiometer values because of the limited resolution. Do you think I could send MIDI to Pd for certain types of data (for example, digital inputs) and also send MIDI from Pd for controlling LEDs, and send serial to Pd for the analogue inputs?
 
Do you think I could send MIDI to Pd for certain types of data (for example, digital inputs) and also send MIDI from Pd for controlling LEDs, and send serial to Pd for the analogue inputs?

On the Teensy side, yes, this option is available in the Tools > USB Type menu. All you have to do is click "Serial + MIDI", and Teensy will implement both simultaneously.

On the Pd side, I'm afraid I can not help much. I have personally used Pd only a couple times. The best I can do is pass along the experience I've heard from many puredata users, that Serial tends to have issues and switching to MIDI (usually) gives much better performance with Pd.
 
Ok, thanks for the info. There's quite some trial and error I need to do. Will come back with results when done.
 
After quite some time of fiddling and testing, I changed the whole system and now the communication between the Teensy and Pd is being done with MIDI. A major change was that I applied some more filtering to the potentiometers and their values are being sent only when they have a certain absolute difference from the last value sent. Sending lots of potentiometer values constantly was probably clogging the serial line.
Since I did this change alongside applying the MIDI protocol, I can't really confirm that MIDI with Pd is more stable that raw serial data. The only thing I can confirm that works better with MIDI is that now I have no issues when I launch Pd without its GUI, when the Odroid boots.

The system I have now is very robust.

Thank you all for your help.

P.S. I'd like to add "[SOLVED]" to the subject of this thread, but to be honest, I can't see how I can edit it.
 
Status
Not open for further replies.
Back
Top