Scoping Data over Serial in Real Time - Is it feasible?

I am using a TI microcontroller to control a system. I sample at 10kHz and each sample is a 16 bit unsigned integer value. The development board is connected by USB to my PC and there are two channels of serial interface carried - one for the JTAG emulation and one that is available for other uses.

My question is this: Is it possible to log data back to the PC over serial and then use MATLAB as an oscilloscope to view it in real time? This would be extremely useful for debugging and for gathering experimental data. A VERY rough calculation would suggest it is possible: 10000 samples * 16 bits = 160,000bps. The microcontroller datasheet shows the serial interface operating at 6.25Mbps in one of the applications.

Are there any examples out there of this being done, or resources that I could look at?

Answer 1

[Walter Roberson]

In theory a USB 2.0 port should be able to handle that data rate for a virtual COM port, provided that at least 160 bits of payload are sent per packet... so 5 or more samples at a time.

If you have configured to send the packet after every 2-byte sample, then USB 2.0 will not be able to handle that load.

Serial over USB is not the same for performance purposes as a true serial port. For a true serial port, you could in theory configure for an interrupt for every byte (but that could be stressful on the interrupt service routine); for Serial over USB, you are effectively limited to 1000 interrupts per second for virtual COM ports, so you are forced to bundle multiple samples per packet. Which is fine if you just care that the bytes get to the other end without overflow, but is not fine if your "real time" requirements do not permit for transport delays while samples are bundled together into a packet.

In terms of simulink and oscilliscope: you would need to simulate time (under the assumption that the data is being transmitted at a fixed frequency); OR you could time-stamp the packets as they come in and assume that the sampling frequency was fixed within the buffer of samples (so count backwards from the present time by a fixed amount per sample to deduce the time the sample was generated); OR you can have the device time-stamp the samples, which can multiply the number of bytes needed per sample -- generally to 8 bytes of timestamp if using absolute time, and generally to 4 bytes of timestamp if using relative time (in which case there can be difficulties in synchronizing the meaning of the base time.)

[Euan Andrew]

Please forgive my ignorance, but are you able to link to any good resources where I could read up on the data packets you describe? My previous experience is with using SPI where you're only ever dealing with one 16-bit sample at a time without ever trying to collect multiple samples into a packet.

I would be happy to bundle the samples into very large packets. I am actually sampling a 50Hz signal at 10kHz, so lets say I could bundle one cycle's worth of data into one packet, that would be (1/50)/(1/10000) = 200 samples per packet. For the four signals sampled at 16-bit resolution, that would be 12kbits per packet, with 50 packets arriving per second.

[Walter Roberson]

http://janaxelson.com/usb_virtual_com_port.htm

If you were sending binary data to an external device via virtual COM port, from within MATLAB, then the basic technique would be to fwrite() whatever you have available, and let the drivers handle the rest. The USB drivers will bundle packets until a particular time has elapsed without new data to send (my memory is saying it works out to 40 packets per second if you proceed by timeout), or until a USB COM packet is full (I have lost track of whether that is 1020 data bytes or 1022 data bytes. not 1024 data bytes for USB 2.) The USB standards say that instead of waiting for timeout, the sending system can also execute a packet push call to schedule the packet for the next available timeslot, but MATLAB does not provide access to such a push call.

When sending the other way, from external device to MATLAB, the same considerations apply: the standards say that you are supposed to accumulate bytes to send until timeout or until packet is full or until the code asks to push the packet. But there are differences between what the standards say and what is implemented by microcontroller libraries. I have never investigated the TI implementation. On some small-system implementations, the rule is that each I/O call is scheduled for an individual packet -- so if you putchar() or fprint() then whatever you did in that one operation will be scheduled as a packet, and if you fwrite() then whatever you write in that burst is scheduled for as many packets as needed to send it out. However, the 1000 per second limitation is at the host controller: USB 1.0 and 2.0 operate on a master/worker arrangement where the worker is only permitted to send data when the master asks for it. (USB 3.0 is still mostly that way, but added provision for interrupt requests in some cases.) The host controller (on the system MATLAB is running on) is not going to ask the USB peripheral for data more than 1000 times per second. One thing about small system implementations is that they generally make it easier (or at least more socially acceptable) to make the appropriate driver call to ask for the packet to be pushed.