inByte handling switch case serial (RS485)

Hi Nick,

first of all, thanks for sharing your work and knowledge.
I am intending to make a communication protocol based on your serial RS 485 implementation, which I think is straightforward and uses only what is really needed. I think it indicates good code when everyone would say something like "this is easy, of course this is how you do it".

I have had a look at the code and already done a basic implementation.
Since I would like to eliminate possible errors I have a question concerning the switch case which handles the incoming bytes (or more specific the available bytes in the receive buffer).
1: if the incoming Data is another STX or ETX it counts as a valid STX or ETX - of course there will probably be an error afterwards because of a non-valid CRC, but maybe it would make sense to produce an error, if another STX or ETX is in the buffer before a valid CRC is received indicating the end of this message.
2: connected to this is the problem, that the CRC Code itself might be recognized as a wrong STX or ETX which will lead to a mysterious error (or am I missing something?)

Thanks and regards,
Markus

I don't normally answer electronics questions here (there is StackExchange for that) however I will comment on your point:



The CRC will not ever be a 0x02 or 0x03 because of this:

---

No it doesn't, for the same reason.

thanks for the quick answer.
I was not aware this is an electronics related question, sorry for that.
You are of course right about the inverted form, somehow I forgot about it in the process of thinking about the specific code implementation (I had the line you quoted somewhere in my mind but didn't relate to it somehow).
I am not really an experienced programmer, so I am really thankful for experts sharing their knowledge.

The only point which could probably be discussed is, that one of the valid 16 values gets corrupted during the transmission (such that it becomes 0x02 or 0x03) and is therefore recognized as a valid STX or ETX. Of course this is very unlikely and I wouldn't know of a better solution without a lot of overhead.

I have another small question concerning the code in this switch case:
the switch case is waiting until a valid STX is in the buffer, other characters until the STX are omitted, but there is no error if there is a wrong character before the STX. Is there a specific reason, why you didn't implement a return 0 and therefore an error if this happens? Is it in order to work even if there is a lot of noise on the line, so that even with a very noisy line a valid message will get through once in a while?

Is there a specific reason, why you didn’t implement a return 0 and therefore an error if this happens?

What is a “wrong character before the STX”?

The protocol defines an STX as starting a packet, so there isn’t really any concept of <some valid thing> before the STX.

If noise looks like an STX, well so be it. The likelihood of noise that looks like an STX, followed by some data, followed by an ETX, followed by the correct CRC, just happening by chance from noise, is pretty low.

Is it in order to work even if there is a lot of noise on the line, so that even with a very noisy line a valid message will get through once in a while?

Pretty much. If the line is so noisy that this happens a lot then you have hardware problems.

The only point which could probably be discussed is, that one of the valid 16 values gets corrupted during the transmission (such that it becomes 0x02 or 0x03) and is therefore recognized as a valid STX or ETX. Of course this is very unlikely and I wouldn’t know of a better solution without a lot of overhead.

I think you are overthinking it. This hypothetical scenario which you are trying to solve by having “something valid” precede an STX, where an STX, by definition, starts a packet could only be solved, if it could be solved at all, by a lot of complexity, requiring a lot of code, which isn’t a great thing to have on a microprocessor with limited program space.