There is no protection against buffer overflows (like getting 100 blanks while waiting for the STX),
and I'm not happy about the ESCIT handling outside the switch, but it is a start.
Most of the code is output and Serial faking, but I think the general structure using a callback
is quite logical and a good separation of reception and processing of the message.
should read one character at a time until STX is received, then capture a buffers worth of data
Then you have to change the ESCIT code, it will store the escaped character regardless of state.
Like I said:
use readByteUntil() to read up to the ETX character, but no more than the length of the buffer specified as an arg
then read the BCC
You can use those crap routines, I wont.
then write your own version of readBytesUntil().
Did you forget that the problem to solve is your problem?
no
just responding to your comments
maybe i was missing something
You should not use any blocking routines if you want to get a smooth running and responsive
sketch, so process data when it arrives and don't wait for anything, always just react.
Test with some new data, but please post that data here, maybe there is something
that is not handled correctly, because it did not occur in the current data.
Do you have any documentation for the packets?
Actually I Document via RS232 Serial Cable, with different dump truck conditions. and this is the video documentation I got on Youtube.
Empty & Stopped
This is an example of 3 data with different truck conditions, the results are exactly what I expected.
... what is the device (model #) being used?
I have no idea, that was the reason to ask.
rusda
two of us have asked this.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
