- the buffer fills up, in which case the buffer is released to be schedule for transmission the next time that the USB Master polls the device for work (and the sending device does not have anything higher priority to send)
- a certain amount of time has elapsed since the last request to send a character was made, in which case the buffer is released to be schedule for transmission the next time that the USB Master polls the device for work (and the sending device does not have anything higher priority to send)
- the transmitting software sends a USB "Push" request to the device driver, in which case the buffer is released to be schedule for transmission the next time that the USB Master polls the device for work (and the sending device does not have anything higher priority to send)
serial communication shows huge batch istead of steady small bursts
3 views (last 30 days)
Hello i am sending threw my microcontroller to MATALB 4 uint8_t variables
0x2F,0x06,0x8F,0x3F and for signalling the end of the stream LF '\n' which Matlab sees it as 0A for some reason
I connect to matlab with the code shown bellow:
I use a callback function as shown bellow,instead of giving me small peaces of 2F 06 8F 3F ,i wait a lot of time and get a huge burst of data which consists of these elements.
How to make matlab to stop storing a lot of data not showing NONE and then ofter a while to show a huge burst of the waited data?
Walter Roberson on 30 Oct 2020
Edited: Walter Roberson on 30 Oct 2020
I predict that COM4 is not a true RS232 or RS422 port, and is instead a USB port with Serial over USB.
Serial over USB is defined by the USB standards that the driver must buffer characters until one of the following occurs:
USB is not RS232 or RS422 protocol. USB always tranmits in "packets" that have type and sizing and identifier information and optionally some data as well. USB never never just transmits the bytes like RS232 does: they are always wrapped in a packet. And the packet is not eligible to be sent until the USB controller specifically asks that particular device whether the device has anything it wants to send. And, as I discussed above, the packet would not even be queued to send until one of those three conditions -- buffer full, timeout, or Push request.
With your moderately high baud rate, and your continuous stream of data, timeouts are unlikely, so if the microprocessor software is not making Push requests to its USB hardware, then the data is probably not going to be transmitted until the buffer fills up.
This is not something that MATLAB can possibly configure: it has to be the sending software on the microprocessor that requests the Push.
Also, for USB 1 and USB 2, the polling rate at which the USB Master asks devices to work, is 1000 Hz. If you were to arrange for the microprocessor to issue Push requests after every 5 bytes, then you would be able to transmit a maximum of 1000*5 = 5000 bytes per second (about 50000 "baud" in traditional terms). This is a primary reason why the rule is that devices must buffer data unless they are specifically asked to release it: high per-packet overhead, somewhat low rate of polling for available data.