How to recive data every 200 us by SerialPort

[billko]

---

@LLindenbauer wrote:

I will grant that I have not been explicit about wraping up the Physical and Link Layer up as one in my examples. This changes little, since both are handled over USB and simulated on both ends. This can be seen in the article I linked above from the wireshark traces. There are no Start, Stop, or Parity bits transmitted.

The Serial Line is a character device. It promises you that if you put bytes in you get the same bytes out, as long as everything is aligned. As it turns out, when you don't have a physical line, you can just assume that the non-existant line was correctly aligned and don't worry about it.

The Start/Stop 'Bits' are not part of the application data. You would be very lucky to be able to mangle and bit-bang your application data just so that it might correctly move over a misaligned physical UART pair and come out at the other end as intended.

In the end, all this is of little consequence for most users. The virtual UARTs I have seen didn't care if you messed up the settings and worked fine either way. It might be of consequence for the thread opener, though, given that they have some tight timing requirements to fulfill. Maybe they would be better served to post the question on an Arduino hardware forum instead?

---

It gets pretty confusing when you start talking about serial and USB when some people use "serial" and "RS-232" interchangeably, yet USB is also a serial device.

I assumed that, when the OP mentioned "USB to serial" adapter, they are talking about a "USB to RS-232" adapter.  If something claims to be an RS-232 adapter, it has to follow the RS-232 recommended standard, or it isn't an RS-232 adapter.  That being said, maybe if you have two adapters from the same company, they can recognize each other and forego most of the RS-232 stuff, but I've never seen something like that.

[rolfk]

Things are slightly more complicated than what has been discussed here. If you have sn Arduino Due you have indeed a virtual serial port in it as the USB port is directly wired to the CPU whose firmware implements a virtual serial port when enabled. On many other Arduinos the USB port is connected to an FTDI chip (or on Chinese Arduino boards a CH232 or similar) or an extra ATMega CPU acting as USB to RS-232 converter before it goes to an actual UART interface on the main ATMega CPU. So things are for many Arduinos not really virtual port to virtual port but virtual port to actual UART port.

With a pure virtual port to virtual port connection there are indeed some possible shortcuts but I seriously doubt that you would get close to 3Mb peak data rate, not to speak of 100 us reaction time. There are to many FIFOs and state machines in between to get a low enough latency for that!

[apc22]

Yes, I have already seen that video and I'm using SerialUSB to send data.

Before I used Serial to send data and this use too much time in procesator to send data, when I change for a SerialUSB this time improve. I see the frecuency with a logic analizer.
Thanks for the aport.

[apc22]

Hello, I didn't find this "BM option", I changed the baud rate default, I was 9600 and I put it in 115200. I have not seen change but maybe help.

[Yamaeda]

115k won't get you far when you need 3000k.

[LLindenbauer]

---

@apc22 wrote:

Hello, I didn't find this "BM option", I changed the baud rate default, I was 9600 and I put it in 115200. I have not seen change but maybe help.

---

The baud rate should not matter when you use SerialUSB. Can you share your Arduino Code?

[apc22]

I have seen the video and the recomendation with ASCII format I am already taking in acount, but the examples in the video always have sampling rate lower than I need (10 samples per second in the video).I will study RAW format, maybe this can solve my problem.

Thanks

[apc22]

Are you propousing to send 5 samples (5x25channels) evey 1 ms from Arduino and them in LABview process this data with some time mark?

It could work, but the problem would be the same, in this momet my Arduino is sending every 200us, but the LABview interface just read every 5 to 50 ms. In this idea order I should to send 250 samples every 50 ms to be sure that LABview will read with the same latency that Arduino send. But in this case the problem could be that the bunch of data will be very big 18740byte / 50ms (75bytes * 250 samples).

[apc22]

In .rar I've uploaded the Arduino Code.

Im using 3 modules that give to me the ADC reading (each module give me 8 chanles).
I verify the period of Arduino by a Logic Analyzer, I see the SPI comunication with the ADC and is 200us of period.
I send data in 2's complement because if I transform to integer in Arduino, Arduino delays the period of sending data.

I program Arduino DUE via Programing Port, but for use with LabView I conect the NativeUSB port.

[LLindenbauer]

---

@apc22 wrote:

Are you propousing to send 5 samples (5x25channels) evey 1 ms from Arduino and them in LABview process this data with some time mark?

---

Yes. As it turns out, the SerialUSB library might not quite "baked through". I would say that the solution is to add timing information on the DUE. Can you tell us why you want such a low latency?

I wanted to see the Arduino code because I hoped that adding a SerialUSB.flush() to line 204 would force a USB packet. I went to double check if this true and came upon this thread: https://forum.arduino.cc/t/arduino-due-native-usb-communication-serialusb/366130/3 - They seem to indicate that SerialUSB.flush() may not be working at all. I triple checked with the SerialUSB source* here: https://github.com/arduino/ArduinoCore-sam/blob/790ff2c852bf159787a9966bddee4d9f55352d15/cores/ardui... - but it looks like the flush does point somewhere within the USB firmware.

So, my suggestions:

• Try adding SerialUSB.flush() below line 204 and see if this solves the issue.
  • Maybe the flush works and you are fine
  • Maybe the flush is ignored - or the rapid flushing blocks the DUE: Proceed to the next suggestion
  • Bonus: If the flush is ignored, you might be able to lower the timeout until the DUE flushes itself.
• Reconsider why you need the timing to be this precise.
  • You can add timing information to each measurement. On the receiving end (LabVIEW?) you can then reconstruct the precise signal. This is fine if you only need to know what the signal was, but not react within 100µs. I highly doubt that you need this fast of a reaction time. If you were building a quad-copter, you'd need to to this on the arduino itself anyway.
    See example below on what changes I'd do.
  • If you really have to do something this fast, you might consider detecting it by doing signal processing on the DUE. It should be beefy enough to do so. Then send the reaction upstream.

What I would change in the code:

• Move trasmision() to the main loop (Line 183 below line 191)
• Add SerialUSB.print(micros()) to trasmision()

A note on your own measurements: As I understood, you use the logic analzer to check if the SPI/ADC measurements are done in the correct frequency. To see if the USB packets arrive on time, you would need to probe (and decode) the USB line. I doubt that most logic analzers are fast enough for this. Wireshark does a better job there. The USB part of the firmware has a mind of its own and after you write() or print() to it, it will wait to send a big packet all at once. You can probably set the timeout it will wait, but I would not know how to do that off my hat.

*: RS-232-afficionados may notice that the only Baud Rate that the firmware cares about is 1200, at which the DUE resets itself if DTR is also set. This virtual UART is really quite minimal, it just collects the RX bytes in a ring buffer and keeps them safe until requested. TX is immediately sent to the USB-CDC.