serial communication shows huge batch istead of steady small bursts

3 次查看（过去 30 天）
fima v
fima v 2020-10-29
编辑： fima v 2020-10-30
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:
sObject=serial('COM4','BaudRate',115200,'TimeOut',10,'Terminator','LF')
sObject.BytesAvailableFcn={@callbackSerial};
fopen(sObject)
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?
Thanks.
function callbackSerial(ser,~)
global time;
val=fread(ser);
val(1,1);
dec2hex(uint8(val))
%time(16)=pnumval;
%time(1)=[];
%disp(time);
%figure(1),plot(time);
end
  2 个评论
Rik
Rik 2020-10-30
You should have posted this as a comment to your previous question, instead of posting it as a new question.
Walter Roberson
Walter Roberson 2020-10-30
for signalling the end of the stream LF '\n' which Matlab sees it as 0A for some reason
https://en.wikipedia.org/wiki/Newline#Representation
You will see in the representation table that \n has been encoded as 0x0A for for 60-ish years.
Remember that the escape characters such as \n in format strings are not sent literally, as their role in format strings is to signal that what follows is an extended character sequence standing in for something else. For example \t for tab, \g for bell.

请先登录，再进行评论。

请先登录，再回答此问题。

回答（1 个）

Walter Roberson
Walter Roberson 2020-10-30
编辑：Walter Roberson 2020-10-30
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:
  • 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)
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.
  6 个评论
显示 4更早的评论
fima v
fima v 2020-10-30
Walter the callback worked before when i send a single commands it recived them fine.
the problem starts when i send all the time its stops reacting to \n
fima v
fima v 2020-10-30
编辑：fima v 2020-10-30
I'm pretty much just guessing at this point but if we rule out a buffer delaying the data then another possibility could be that Matlab doesn't actually react to \n at all but instead is waiting to see an EOF (End Of File)
how can i switch it back so if a send it a stream of bytes separated by \n byte then it will not store all of them? But will send threw when reaches \n

请先登录，再进行评论。

类别

在 Help Center 和 File Exchange 中查找有关 Simultaneous and Synchronized Operations 的更多信息

标签

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by