| Electronics > Projects, Designs, and Technical Stuff |
| Custom 1 wire (open drain aka I2C ) protocol bytes with CRC and ID arbitration |
| << < (4/4) |
| beduino:
--- Quote from: T3sl4co1l on November 11, 2019, 09:37:13 pm ---I would expect the software implementation for error detection would be smaller than a 256 byte lookup table, and execution time shouldn't be a problem here; the table is a lot faster to develop with though. --- End quote --- 256 byte lookup table is for the moment for simplicity, but 128 bytes is enougth since we need to precalculate Hamming Code 4 bits (P8 P4 P2 P1). Instead of calculation using XOR and all this mess we get without bit shifting in one step on ATTiny85 lookup table is quite fast 8) --- Code: ---269 avr_byte_crc_hamming_code: 270 /* prologue: function */ 271 /* frame size = 0 */ 272 /* stack size = 0 */ 273 .L__stack_usage = 0 274 0230 E82F mov r30,r24 275 0232 F0E0 ldi r31,0 276 0234 E050 subi r30,lo8(-(avr_byte_hamming_code_table)) 277 0236 F040 sbci r31,hi8(-(avr_byte_hamming_code_table)) 278 /* #APP */ 279 ; 913 "avr_utils.c" 1 280 0238 E491 lpm r30, Z --- End code --- I will change this Hamming Code parity bits table to support P8P4P2P1 bits in pairs, so 128 bytes in MPU flash memory. |
| beduino:
--- Quote from: T3sl4co1l on November 11, 2019, 09:37:13 pm ---Yeah, avr-gcc typically generates individual shifts until four or so, at which point it may generate a loop, or use the swap instruction. --- End quote --- Yep, avr-gcc for ATTiny85 used for C code something like this: --- Code: ---C= (C>>4) & 0xF --- End code --- In assembler listing we have SWAP followed by ANDI - not so bad and quite smart ;) --- Code: ---... 245 01dc 00C0 rjmp .L26 247 .L28: 248 01e0 8F70 andi r24,lo8(15) 249 01e2 0895 ret 250 .L26: 251 01e4 8E2F mov r24,r30 252 01e6 8295 swap r24 253 01e8 00C0 rjmp .L28 --- End code --- |
| beduino:
--- Quote from: rhodges on November 11, 2019, 12:00:15 am ---Each message was 128 bits long, and encoded with AES-128. If any bit is wrong, the entire message is garbage. --- End quote --- I've managed sucessfully to attach 4bits of Hamming Code to each send byte (12bits now), so if one bit will be wrong we still have a chance to correct this byte 8) Fast byte Hamming Code calculaltion is now based on 128 byte lookup table precomputed pairs of 4 bit parity bits. Now, imagine we apply XORed random OTP bits with each bit of send data this way- it will be very fast in comparision to AES-128 encoding assuming we have acccess to the same sources of random bits data on both sides of communication. Of course OTP has limittaions, but sometimes it might be very usefull to encrypt something this simply way - eg. we do not need send too many data in low speed comunication. In some cases we still could make SHA256 hash, for example with some sequence numbers and depennding on what we need it can work. |
| Navigation |
| Message Index |
| Previous page |