Electronics > Projects, Designs, and Technical Stuff
Custom 1 wire (open drain aka I2C ) protocol bytes with CRC and ID arbitration
beduino:
Hello,
I'm working now on custom 1 wire protocol where bytes will be send with optional CRC (by extending data byte 8 bits by additional 2 bits).
Additionally, I'd like to have bus arbitration based on message ID, where ID is two bytes and each ID byte with optional 2 bits CRC.
It looks like that something such simple like below might work for low speed communication, where logical 0 is three times shorter than locical 1.
Each byte in message is separated by one time period (1ms @ 1kHz example below) space between bytes.
End of message can be marked as at least 3x time period release of open drain wire with pull-up to Vcc aka I2C, etc.
In many cases 1kHz signal frequency will be fine for low speed communication, but I'd like to be able detect transmision errors at each byte - eg. receiver can put line low to indicate error eg. at the begining of the message, to tell sender there is something wrong, since it doesn't make any sense to continue while we already know probably one of the message bytes is already bad.
What kind of 2bit CRC would you suggest to do so for each byte? ::)
T3sl4co1l:
2 bits isn't really a CRC... or much of anything, I think?
You need 1 bit for basic parity. You need at least 3 bits to do a sum (2^3 = 8 maximum number of bits) for example. Hamming code needs 4 bits to correct single-bit errors for 8-bit words. Or you get better efficiency for more, but I'm guessing that would suck. You wouldn't want to have to decode the entire message packet (say 32 bits worth, plus check bits) just to see where it's going.
Heh, error correcting codes are probably a bad idea anyway actually, since that's the point, it needs to be detecting errors for arbitration purposes. I mean, you can use them both ways, single-bit correcting is double-bit detecting, you can provide that as an output from the decoder.
It's kind of a weird thing anyway, regardless; you're relying on bit errors to serve a specific purpose. Which means you can't really tolerate bit errors at all. Consider if some interference is reliably causing single bit flips that trigger the arbitration function, it'd basically be trolled by it and nothing can ever get through.
Mind, that's true of the original (I2C), not specific to your proposition. It's all the more reason why I2C needs to be kept on board, well away from cables.
So anyway, if nothing else, I guess error checking on the ID/address alone, wouldn't really make sense. Some check bits or CRC at the end would be good though. And then you have good reason to use more bits, maybe a traditional CRC8, or, uh, what does I2C actually use again?..
Good luck, in any case. Looks like your proposal is more than slow enough to bit-bang, if you're so inclined, so whatever timing, byte/word/packet length, EDC and ECC you like, are all game. :-+
As an aside, if bus-open times are symmetrical with bus-active times, I think that's basically Manchester encoding?
Tim
beduino:
--- Quote from: T3sl4co1l on November 09, 2019, 11:15:37 pm ---2 bits isn't really a CRC... or much of anything, I think?
You need 1 bit for basic parity.
--- End quote ---
I think I will use CRC-1 (basic parity ) two times: for first 4 bits and second time for last 4 bits, than those two CRC-1 will be attached to the end of each byte which will look like 2 bit CRC.
Another way could be compute CRC-1 of first 4 bits of byte, attach it to form 5 bit, than last 4 bits the same with attached CRC-1 will create fancy 10 bit number >:D
Benefit by using parity check of 4 bits this way could be, we could reject message after parity check fails after 4 bits.
--- Quote from: T3sl4co1l on November 09, 2019, 11:15:37 pm ---Some check bits or CRC at the end would be good though. And then you have good reason to use more bits, maybe a traditional CRC8, or, uh, what does I2C actually use again?..
--- End quote ---
I've already found CRC-8 example implementaion used as additional byte at the end of I2C communication, so since I will also need to talk to different devices using I2C, probabbly it is good idea to implement CRC-8 as additional byte at the end of the more important message :-+
beduino:
--- Quote from: T3sl4co1l on November 09, 2019, 11:15:37 pm ---Hamming code needs 4 bits to correct single-bit errors for 8-bit words.
--- End quote ---
I've already implemented in my AVR MPU code quite fast CRC8 function based on lookup table of 256, so now additional CRC byte is added by main loop code, than in timer ISR (10kHz) parity bits (after each 4 bits inside bytes) inserted during outputing encoded waveform and it looks like below for 3 bytes: 0x12 0x34 0x56 + 1 byte CRC8: 0xC1 :
In comparision, below the same 4 bytes send without those 2 parity bits inserted in each byte:
NOTE: I've changed my mind and now space (1ms) between each byte in message is made by pull down, so we have easy to read even by humans transmission bits ;)
Anyway, It could be interesting maybe support instead of those 2 additional bits per byte use additional 4bits for Hamming code to be able make this single bit correction 8)
However, when started looking for good examples howto calculate those Hammins codes for byte (8bits) I struggle to find good example to understand in detail howto implement this.
Here below on YT videos looks like quite good howto make it by hand on paper, but still too fast ???
Calculating Hamming Codes example
Hamming Code - error detection and correction
Looks like ECC memory works on larger amouts of bytes.
Maybe, someone could help find more datailed information about those Hamming codes calculation in the case of single byte, error detection and optional correction? :-//
viperidae:
Is there a reason you're rolling your own protocol and not using am existing one? There's 1wire and sw-can
Navigation
[0] Message Index
[#] Next page
Go to full version