Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ Programming
➜ General
➜ inByte handling switch case serial (RS485)
inByte handling switch case serial (RS485)
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| Markus
(2 posts) Bio
|
Date
| Tue 10 Aug 2021 07:31 AM (UTC) Amended on Tue 10 Aug 2021 08:26 AM (UTC) by Markus
|
Message
| 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 | Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #1 on Tue 10 Aug 2021 07:51 AM (UTC) Amended on Tue 10 Aug 2021 07:52 AM (UTC) by Nick Gammon
|
Message
| I don't normally answer electronics questions here (there is StackExchange for that) however I will comment on your point:
Quote:
that the CRC Code itself might be recognized as a wrong STX or ETX which will lead to a mysterious error
The CRC will not ever be a 0x02 or 0x03 because of this:
Quote:
Each data byte (other than STX/ETX) is sent in a "doubled/inverted" form. That is, each nibble (4 bits) is sent twice, once normally, and once inverted.
...
Because of this, also, the STX and ETX characters cannot appear in ordinary data (they are not one of the 16 valid values).
Quote:
if the incoming Data is another STX or ETX it counts as a valid STX or ETX
No it doesn't, for the same reason. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Markus
(2 posts) Bio
|
Date
| Reply #2 on Tue 10 Aug 2021 08:45 AM (UTC) |
Message
| 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? | Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #3 on Thu 12 Aug 2021 06:06 AM (UTC) Amended on Thu 12 Aug 2021 06:07 AM (UTC) by Nick Gammon
|
Message
|
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.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #4 on Thu 12 Aug 2021 06:11 AM (UTC) |
Message
|
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.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
10,248 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top