Hi,
You have to create a state machine, at start you can have something in
the serial buffer and you will lose receiver sync..
Java example:
privateenum Stage {
FIND_STAGE1,
FIND_STAGE2,
FIND_STAGE3,
FIND_STAGE4,
FIND_STAGE5
}
public void test() {
Stage currentStage = Stage.FIND_STAGE1;
ByteBuffer buffer = ByteBuffer.allocate(255);
while (true) {
buffer.clear();
int count = readCom(buffer);
if (count < 1) {
continue;
}
for (int i = 0; i < count; i++) {
int j = buffer.get(i) & 0xff;
switch (currentStage) {
case FIND_STAGE1:
if (j == 0x10) {
currentStage = Stage.FIND_STAGE2;
}
break;
case FIND_STAGE2:
if(j == 0x11){
currentStage = Stage.FIND_STAGE3;
}else{
currentStage = Stage.FIND_STAGE1;
}
break;
case FIND_STAGE3:
if(j == 0x12){
currentStage = Stage.FIND_STAGE4;
}else{
currentStage = Stage.FIND_STAGE1;
}
break;
case FIND_STAGE4:
if(j == 0x13){
currentStage = Stage.FIND_STAGE5;
}else{
currentStage = Stage.FIND_STAGE1;
}
break;
case FIND_STAGE5:
System.out.println("received header:
0x10,0x11,0x12,0x13");
System.out.println("received data: "+j);
currentStage = Stage.FIND_STAGE1;
break;
}
}
}
}
ArSi
------------------------------------------------------------------------
*From:* David Howlett
*Sent:* Friday, April 21, 2017 6:18PM
*To:* Beagleboard
*Subject:* [beagleboard] Repeatable bug where beaglebone black loses
bytes from
it's serial connection.
I have spent about two days tracking down an issue in one of my
machines. I am streaming pressure readings from an i2c pressure sensor
to a PC at high speed. I have reduced the problem to a small test
case. To replicate the fault I connect the beaglebone black to a PC,
connect to it with serial over the micro USB port, login and launch a
command that streams data fast. On the PC run a program that collects
the streamed data more slowly than it is being created.
importserial
x = serial.Serial('COM15')
to_send =b'\x03yes HelloWorld\n'
x.write(to_send)
while True:
received = x.readline()
ifreceived !=b'HelloWorld\r\n':
print(received)
The python program above prints lines like:
b'ld\r\n'
b'HelloWoroWorld\r\n'
b'HelloWorldorld\r\n'
b'HelloWorldorld\r\n'
b'ld\r\n'
b'ld\r\n'
b'ld\r\n'
b'ld\r\n'
b'ld\r\n'
b'ld\r\n'
b'HelloWoroWorld\r\n'
b'ld\r\n'
b'HelloWlloWorld\r\n'
b'ld\r\n'
b'HelloWorldorld\r\n'
At about 4 lines per second. If I set the program on the beagle bone
to stream slowly then this issue goes away. It appears to be an issue
with a buffer filling up somewhere between the output of the yes
command and reading bytes from the windows API. The correct behaviour
is that the yes command should be stopped when the buffer is full to
prevent the loss of data, then allowed to continue when there is space
in the buffer again. I observe that the streaming command (in this
case yes) is stopped but there is still data loss happening somewhere.
I wrote this in python because it is the language I am most
comfortable in but if you needed me to I could rewrite the example in
some other language. To run the program shown above you will need
pyserial and you will need to change 'COM15' to be whatever the port
is called on your computer.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google
Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/d63ea012-b3ea-49b6-9b13-f3e3be9c51ca%40googlegroups.com
<https://groups.google.com/d/msgid/beagleboard/d63ea012-b3ea-49b6-9b13-f3e3be9c51ca%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/58FA4F5B.2060400%40chello.sk.
For more options, visit https://groups.google.com/d/optout.