UART again

[Jean FOUGERON]

One year ago ckielstra and Ttelmah helped me a lot to write a receive procedure, which works perfectly untill now.

The message to be received is as follow
aa fc nn nn 04 xx xx crc CRC
where :
aa is the adress of the set
fc is a function code the set has to proceed
nn nn is a transaction number
xx xx are the datas linked used with the function code
crc CRC is ... as they say themselves

[ckielstra]

To avoid your problem many protocols start with a fixed sequence of several known bytes. The chance of this special start sequence occurring in the middle of your message is very small and is a good filter for detecting start of the message.
Disadvantage is that you have to send extra bytes, this takes time and power.

Your solution with a time-out is another approach used in many systems.

One reason for it not working is this line:

[asmboy]

Rather than the ISR + timer route you are struggling with, have you thought about simply catching ALL the chars in a standard circular serial receive buffer
and sorting out what is in the buffer in MAIN(); at your leisure ??

Far simpler really and very fast in and out of the ISR -
with a big enough circular receive buffer - you can sort out what you have
in the foreground and never risk a dropped character.

Your timeout-timing can then be a foreground process as well, possibly not even needing a ISR for timer service either.

[Jean FOUGERON]

Thanks friends, for your message

To ckielstra

[Ttelmah]

Have to agree.

Thing is that a well written circular buffer, even at quite a small size, then allows you to take more than one character time between things being handled. A 'classic' problem would be if (for instance) at the end of line, the code then performs calculations to check the CRC, followed by some other processing of the data. It is always quite easy for this to take more than a character time, and then things start to go wrong....

I tend to use a 'per character' parser, which whenever a character arrives, uses a state machine that is stepping forwards through the expected values and actions for each, performing the required operations.

Now, I have to suggest that you 'reconsider' the format if you can. The problem you are seeing, is fundamental, with any message where the same value is used potentially inside a message, and in an address or control. Though a 'timeout' may allow a form of recovery, this doesn't appear to be guaranteed, since what happens if two successive messages both contain the same address?.
Using some form of unique marker, is the best way to avoid problems. As a 'suggestion', consider setting your UART to 9bit mode, and setting bit 9, in the address only. The cost is 11 bits per byte sent, versus the current 10 bits, so just 10 percent. Then your handler can just look for bit 9 being set, and when it is, use this as the 'address' marker. Nice thing then is that even if a byte is lost, or an extra one received so a count goes faulty, you can still recover. The bytes received with the count 'wrong' can be rejected when the CRC doesn't work, and the new start of packet location identified.

Best Wishes

[Jean FOUGERON]

Thanks Ttelmah

[Ttelmah]

Is there a guaranteed time gap between the messages?.

If so, then this can be used as the marker. Reset a timer to a value that will not reach it's limit, between standard characters, each time the character is received. Then if the timer interrupt is called, you are in the gap between messages.

Unless there is a guaranteed time marker, then the message is really badly designed (I'm not even sure 'designed' would be the applicable word....). Without something to distinguish the start of message, you degenerate into 'trial and error'. You'd have to use the count approach, with a state machine, and when the limit count is reached, check the CRC. If this is OK, accept the message, and pull the address from the expected byte. If it isn't, throw away the first character from the sequence being checked, and loop back to checking. There is still a tiny chance of accepting a wrong message, but this is as close as you'll get.

[temtronic]

Is the 5th character always '04' ?
If so, using a circular buffer makes it possible,though 'messy'.

1) capture a datastream.
2) locate the '04'.
3) create a new buffer 'test_buffer[]',filling it with the previous 4 bytes before the '04' and those after to the crc bytes.
4) run a 'CRC checking' function to confirm/deny this 'test_buffer' has the correct data.
5) if correct, continue your program, parsing address,command,etc.
6) if NOT correct, go back to step 1, try again.If your 'raw data' buffer is large enough,just find the next '04' and retest.

This might work but ONLY if '04' is always the 5th element of the datastream.

As others have said you really NEED a 'delimiter', a 'reference' or 'starting point' in order to properly capture and deal with the data.

hth
jay

[jeremiah]

Another "messy" way would be to do the ISR buffer they are talking about and in the main do a multi-pass CRC check until you find a valid CRC, then go back and parse the message to see if it is for your address or the broadcast address

So if you had the byte stream:


b00 b01 b02 b03 b04 b05 b06 b07 b08 b09 b0a b0b b0c b0d b0e b0f b10

So the first pass would use b0-b8, checking versus the CRC bytes in b7 and b8. If the computed CRC matches those, go back and look b0 to see if it is your address or a broadcast address.

If not, look at b01-b09, assuming b8 and b9 are the CRC bytes. If this doesn't pass, do b02-b0a, etc.

This is tricky because it is a lot of processing of the same data, so you'll have to figure out how to manage processing time, getting the data out of the circular buff, and possibly adding new bytes to the end of your saved copy if new ones come in while you processing earlier ones.

This isn't a 100% solution, but since you cannot change the supervisor, it might make due. Really the best solution is to talk with your management and do a new revision on the supervisor firmware and add new parts to the protocol (or rewrite it).

[Jean FOUGERON]

Yes the 5th is always 0x04 because the message is always 9 bytes long and the MODBUS standart implies the succession of set adress, function code, content. In content is included remaining bytes quantity in the message, which counts data by itself = 2 bytes plus CRC = 2 bytes -> total 4 bytes
So, the 5th is always 0x04

Taking that in account, I presently am testing a solution like as follow, according to asmboy idea

[jeremiah]

[Jean FOUGERON]

[Ttelmah]

If this is Modbus, then the time gap is defined.

Frame start, is 3.5 characters or more of silence. Well defined, and easy to test for.

[Jean FOUGERON]

I have implemented the following, and it seems it works (at least since this morning)

I have one set in the lab
If I configure it in adress 01 it answers, and it acts when broadcast (adress 0)
Idem if I configure it in adress 2
... and 3, and 4 ...

Youpiii !

[ezflyr]

Hi,

Well, is the '0x04' totally unique, or might it also appear as part of the 'data' or 'CRC' later on? If this character is not 100% unique, then yes, your method is still flawed....

As Ttelmah pointed out, the interval between messages in Modbus is well defined, and easy to test for. It seems to me that this is the only unique thing that occurs in your communications protocol. Why not use it?

John