< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous (in thread)
N :the next (in thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
Robert Klemme wrote:
> Joel VanderWerf wrote:
>
>>Levin Alexander wrote:
>>
>>>Hi,
>>>
>>>I have a small program, that reads data from a serial port and chops
>>>it into packets. A Packet has the following format:
>>>
>>> [0x65, 0xEB, <type:8>, <counter:8>, <length:8>, data:length>,
>>><crc:16>]
>>
>>Why not read enough bytes to make sure you get the length byte:
>>
>>s = io.sysread(5)
>>len = s[4]
>>s << io.sysread(len+2)
>>ary = s.unpack "C5a#{len}n"
>
>
> Why do you use sysread? I'd prefer to use #read in this case - I don't
> see any advantage of resorting to sysread here - it may even prevent read
> buffering => things get slower than necessary.
You're right. I was thinking about readchar, which the op used and I
assumed to be unbuffered, but I don't even know if it is!
>>Or is the problem that there may be a variable number of "start
>>bytes"? In that case, maybe you could tell from the first 5 bytes how
>>many start bytes there are, and then read enough to capture the
>>length byte.
>
>
> Hm... doesn't seem to be the case.
But there is some logic in the op's code that looks for repeated "start
byte". I'm just not sure what the limit is.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407