Page 5 of 6
Re: UART Transmission with atmega328p
Posted: Tue Oct 15, 2024 11:53 am
by ChrisT66
Your suggestion to use the checksum is perhaps a good idea. I have read that all transmitted bytes are subtracted from 0xFFFF. With a 6-channel receiver, for example, the remaining channels (i.e. 8) are filled with 0x05DC. But only the sender knows the exact data of the 6 channels it is sending and can check the checksum, or am I making a mistake?
Re: UART Transmission with atmega328p
Posted: Tue Oct 15, 2024 1:21 pm
by mnfisher
It would 'normally' be transmitted as the last 2 bytes of the message - and should be correct for the packet to be valid.
Should be possible to check using a downloaded packet - if it's just a subtraction then all should be well - some checksum use a CRC and life would be harder unless the docs give a clue.
Re: UART Transmission with atmega328p
Posted: Tue Oct 15, 2024 3:07 pm
by ChrisT66
That means I have to subtract the 6 words of the 6 received channels from 0xFFFF, then subtract 8 times 0x05DC for the unused channels and then compare that with the last word (the checksum), right?
Re: UART Transmission with atmega328p
Posted: Tue Oct 15, 2024 3:16 pm
by mnfisher
Well worth a try - it might also include the header as well.
What values do you receive on the unused channels (ie do you get 0x05DC or 'random' values)
If it works - easy to do in a loop in the code.
Re: UART Transmission with atmega328p
Posted: Tue Oct 15, 2024 3:42 pm
by ChrisT66
Yes exactly, the unused channels always deliver 0x05DC.
You just have to think about what kind of receiver you have, 6 or 8 channel etc.
Another stupid question: when do you use parameters and when do you use variables? You have also defined parameters in your chart. I haven't used them yet.
Re: UART Transmission with atmega328p
Posted: Tue Oct 15, 2024 4:17 pm
by mnfisher
I would always favour local variables (and function parameters) over global variables. Global variables are sometimes a necessary evil (for example for the interrupt handler). If you create a large program then it makes life much simpler and avoids many possible errors.
It's worth splitting your program into small (hopefully) easily understood functions - the overhead is very small to use them
Where possible functions should avoid having side effects - they can (and will) come back to bite you at some stage with a weird crash.
Re: UART Transmission with atmega328p
Posted: Wed Oct 16, 2024 11:07 am
by mnfisher
A quick thought on checksums after some googling.
As far as I can tell - the value (the last two bytes of the packet) should match 0xFFFF - each byte of the packet (including 0x2040 but excluding the checksum) (Note the first byte is actually a packet length (0x20) then a command (only 0x40 supported)
Then I think we could refactor slightly.
The Rx interrupt could calculate the checksum as well as calculating the channel values:
We know the current position (so 0 is LSB of channel 0)
So something like (thinking aloud):
(in the interrupt handler)
Code: Select all
(case 1)
csum = 0xFFFF - 0x20 - 0x40
(case 2)
if pos < 28 // Data in bytes 0..27
csum = csum - .c
channel = pos / 2 // 0 and 1 = channel 0, 2 and 3 = channel 1...
if channel < 6 // We have channels 0..5
if (pos & 1) == 0 // Even byte is LSB
data[channel] = .c
else
data[channel] = data[channel] + (.c << 8)
if pos = 28 // LSB of checksum
checksum = .c
if pos = 29 // MSB of checksum
checksum = checksum + (.c << 8)
I've attempted to implement this (please post a few 'full' data rows - for testing.)
Maybe also need to add a timeout - connection lost?
Martin
Re: UART Transmission with atmega328p
Posted: Thu Oct 17, 2024 9:28 am
by ChrisT66
Wow, thanks for your new idea.
Nothing is currently displayed, i.e. the programme is stuck somewhere. I'll have to see if I can find something.
Re: UART Transmission with atmega328p
Posted: Thu Oct 17, 2024 9:36 am
by mnfisher
Okay - does that mean the checksum test is failing?
Re: UART Transmission with atmega328p
Posted: Thu Oct 17, 2024 10:01 am
by ChrisT66
Yes, it hangs in the query If pos < 28