I'd just like some keywords and very basic guidance so that I can better google for answers myself.
I have a vehicle which communicates a couple of functions from its ECU to the vehicles gauge cluster using a very simple (one way) serial connection.
The data is extremely basic. each message is 8 bytes, the first 7 bytes contain useful information, the final byte is a simple checksum. As an example of how basic this data stream is, the first two bytes get summed together to provide a sensor voltage, and the 6th byte is simply divided by 32 to give the current gear selected.
It is easy on the scope to see that each message is separated from the next by a delay, but I cannot see any character or number that formally defines the start or end of the message.
The problem:
I cannot get my head around how I maintain this pause or message separation within the buffer. I'm confused. If we somehow had the ECU and arduino pick up every one of the 8 bytes and stack them into the buffer in order, they could be pulled out in groups of 8 to populate my array, no problem, but if the arduino picked up the tail end of one message and then stacked in the start of the next message, everything would be corrupt.
Key words and abuse appreciated I have not shared any code because Its not a code problem, its a problem with my knowledge.
The entire message frame must be transmitted as a continuous stream. If a silent
interval of more than 1.5 character times occurs before completion of the frame,
the receiving device flushes the incomplete message and assumes that the next
byte will be the address field of a new message.
I have a basic version of the code operating now, I was extremely proud once it started spitting out data
I think one of the worst things that a novice can do is stress over the first piece of code being absolutely perfect, 100% efficient etc. I have read numerous related threads on here with guys saying things like "if you throw data out, your code is no good"... but tell you what its my code I'll do what I want
I couldn't work out how to measure the timing of the incoming bytes since they all come out of the buffer and can potentially lose the delay between messages, so I went the most basic route possible and used the 0's (which seem to be used just to pad the messages out) to find a pattern. I know the first two bytes have numbers and the 3rd is a zero, so it simply tries to line up those three and biffs out between 1 and 3 bytes each time until the pattern is found, and from then on it should stay relatively in sync (But its doing that check for the pattern each time it runs through that loop anyway). Once the pattern is found it stuffs those first three bytes into variables and then pulls the next 5 from buffer and throws those into variables too.
I'm not checking the CRC because i don't see the point. If it identifies an error my only option is to read the next message from the ecu and hope that its right- and thats what it does anyway.
The data is not critical- water temp and gear position, so very low risk
