-
Thread
CAN-FD CRC-17 Berechnung stimmt nicht mit erhaltene CRC
1ste and 2te Fixed bits // nicht drin }; std::uint32_t receivedCRC_17 = 0x1A049; [/c] ABER... wenn ich es selber ausrechne, ich bekomme immer CRC_17 = **0xAD5** statt **0x1A049** wie es in CANoe ausgegeben wurde (siehe CANoe Screenshot). Für die Berechnung habe
[Stuff Bits Count] - siehe bitsForCalculation Code oben. Basis der Kalkulation ist das Polynom CRC_17 = 0x3685B (Bin:110110100001011011). Hier einen Link wo man es online rechnen kann ** (https://asecuritysite.com/comms/crc_div?a=1010101010&b=10001) ** Ich bitte um Hiiiilfe!!! Ich weiss nicht
-
Thread
Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?
12] << 8 | (buffer[13] & 0xFF); status.totalGeneratedPower = *((float*)&tempTotal); // CRC = buffer[14] status.dcVoltage = (buffer[15] << 8 | buffer[16]) / 100; status.dcCurrent = (buffer[17] << 8 | buffer[18]) / 100; status.dcPower = status.dcVoltage * status.dcCurrent;
02 00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c e3", "crc8_valid": true, "mid": 149, "response_time_ns": 67262961, "ch_rx": 3, "ch_tx": 40, "src": "73415022", "name": "acdata", "dst": "73415022", "cmd": 2, "u_V": 2.3, "f_Hz": 0.21, "p_W
-
Thread
Logamatic 2107 Schnittstelle
YEAH! "0B 88 18 0 255 <crc>" => "08 0B 18 00 3C 02 77 64 17 09 01 25 40 80 00 02 32 80 00 00 7A FF 2D 48 00 C8 00 02 00 B1 00 0D" :-D
nicht möglich das letzte Datenbyte von 00-ff aufzunehmen. Es gibt nur folgende Möglichkeiten: DB CRC 00 C1 01 41 02 D8 03 58 04 F3 05 73 06 AF 07 6A 12 10 13 90 16 22 17 A2 ;)
-
Thread
UART Bootloader ATtiny13 - ATmega644
Ohne Bootloader läuft es, und CRC habe ich nicht drauf, zumindest wird ausgegeben das CRC nicht implementiert ist. Auch wenn ich .crc = 17 auskommentiere erscheint dies. Ich benutze den Internen Oszi, habe Datenübertragung mit 9600
Nochmal Wo bitte finde ich die Defines .equ CRC = 17 ; 17 = additional code size .equ VERIFY = 15 .equ ONEWIRE = 3 Ich kann die Defines in der Source nicht finden - gibt es eine neuere Version von Loader als tinyload3.zip
-
Thread
AVR-Bootloader mit Verschlüsselung
04 30 17.06.10-17:26:14-534 > Timer created 17.06.10-17:26:14-534 > Device connected 17.06.10-17:26:15-049 > send keepalive 17.06.10-17:26:15-548 > send keepalive 17.06.10-17:26:16-063 > send keepalive 17.06.10-17:26:16-297 > Timer released 17.06.10-17:26:16-297 > Reading SRAM... 17.06.10-17:26:19-105 > Timer created 17.06.10-17:26:19-604 > send keepalive 17.06.10-17:26:20-119 > send keepalive 17.06.10-17
-
Thread
Faktensammlung Buderus EMS
Soweit bin ich bis jetzt: Aus (Mond drücken): Länge Sender Empfänger Typ Daten gefolgt von CRC 0x05 0x17 0x00 0xad 0x03 0x00 0xb9 Ein (Sonne drücken): Länge Sender Empfänger Typ Daten gefolgt von CRC 0x05 0x17 0x00 0xad 0x03 0x01 0xb8 Raum-Temperatur (0xe3 Byte
10 08 1a 00 00 00 00 00 91 - CRC-Fehler RCTimeMessage ( 10 00 06 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 Daten: 10 00 06 00 13 05 16 1e 19 10 03 01 0c 00 10 00 ed - CRC-Fehler UBAMonitorFast ( 08 00
-
Thread
Brötje ISR Plus Kommunikation / LPB
CRC over bytes [:-2] is 0xB923 Pause of 25,915us at 885,872,216 us (+10,591,996 us offset): 78 17 08 00 0c 02 00 14 e7 05 05 04 b3 00 ff 03 x............... 19 ff ff ff ff 16 f1 a3
CRC over bytes [:-2] is 0x920E Pause of 24,535us at 886,100,648 us (+10,820,428 us offset): 78 17 08 00 0c 02 00 14 07 05 05 04 b2 00 ff 0a x............... 19 ff ff ff ff 16 f0 c9
-
Thread
Diverse fragen zu Hash Maps in C
16 Meiyan 51 66 4.18 54 7106 16384 17 CRC32_SW 32 38 0.69 5 1176 16384 18 CRC32C_HW64 18 28 0.73 17 1246 16384 19
CRC32C_HW64_B 12 17 0.00 0 0 16384 20 CRC32C_ROT 11 16 0.00 0 0 16384 21 Daniel_hash3
-
Thread
Wer verwendet RFM69?
den Wert Länge der tatsächlichen Payload plus zwei haben muss? Falls du für die Semtech/HopeRF-CRC den Code brauchst: [c] // CRC16 gemäß Semtech-CCITT (Finales Ergebnis muss vor Senden/Prüfen bitweise invertiert werden!) uint16_t crc16(uint16_t crc, uint8_t data) { crc ^= (data << 8); for (uint8_t i = 0; i < 8; i++) { data = ((crc & 0x8000) && 1); // Wird durch && entweder 0 oder 1 crc <<= 1; if (data) crc ^= 0x1021; // 0x1021 weil Generatorpolynom x^16+x^12+x^5+1 und MSB first } return crc; } [/c] Du musst
-
Thread
RDS CRC Prüfbit Berechnung
//dummy rcall crc_loop // mit OFFSET_WORD_A verknüpfen ldi r17,low(OFFSET_WORD_A) eor r3,r17 ldi r17,high(OFFSET_WORD_A) eor r4,r17 // CRC abspeichern sts crc,r3 sts crc+1,r4 pop r18 pop r17 pop r16 pop r4 pop r3 ret crc_loop: _loop: lsl r16 rol r3 rol r4 sbrs r4,2 rjmp _kein_xor ldi r17,low(POLYNOM) eor r3,r17 ldi r17,high(POLYNOM)
-
Thread
Automower G3 mit USB Diagnoseport fernsteuern?
Z.b. in C# so, die Bytes aus den der CRC berechnet wird sind nur die Payload. Also ohne die beiden Frame-Bytes 0x03 und 0x02. var crc = Crc8.getInstance().compute(payload); public class Crc8 { private static Crc8 instance
crc = crcTable[data]; } crc = (resultReflected ? reflect8(crc) : crc); return (byte)(crc ^ finalXor); } private byte reflect8(byte val)
-
Thread
SDR-Dekoder für TFA KlimaLogg Pro/IT+ Temperatursensoren
[1]: Stopping tfrec... Oct 25 17:37:19 localhost systemd[1]: Starting tfrec... Oct 25 17:37:19 localhost systemd[1]: Started tfrec. Oct 25 17:37:19 localhost run-tfrec.sh[31569]: Found Fitipower FC0012 tuner [/code]
Hallo Georg Kann es sein, dass in der Routine "tfa2_decoder::flush_tx22" die CRC Berechnung nicht korrekt ist? Ich erhielt keine korrekten Ausgaben. Die crc_val und crc_calc sind nicht identisch. Habe daher folgende Zeilen angepasst: crc_val=rdata[2*num+4]; (original +6) crc_calc
-
Thread
EMS > Adapter > NetIO > Raspi
burnerstatus = "Off"; String cvpumpstatus = "Off"; String hotwaterstatus = "Off"; // Calculate CRC for buffer uint8_t nefit_ems_crc( char * buffer, int len ){ uint8_t i,crc = 0x0; uint8_t d; for(i=0;i<len-2;i++){ d = 0; if ( crc & 0x80 ){ crc ^= 12; d = 1; } crc = (crc << 1)&0xfe; crc |= d; crc ^= buffer[i]; } return crc; } // CRC check boolean crcCheckOK(char * buffer, int len ){ int crc = nefit_ems_crc(buffer, len ); boolean crcOK
-
Thread
timer und interrupt
13] = 0x00; Zoom[k][14] = 0x00; Zoom[k][15] = 0x00; Zoom[k][16] = 0x00; Zoom[k][17] = 0x00; Zoom[k][18] = 0x00; for (i = 1; i < 17; i++ ) crc_16 = update_crc_16(crc_16, Zoom[k][i]); //calculate crc for the command Zoom[k][i] = (unsigned char)(crc_16 >
Zoom[13] = 0x00; Zoom[14] = 0x00; Zoom[15] = 0x00; Zoom[16] = 0x03; Zoom[17] = 0x00; Zoom[18] = 0x00; for (i = 1; i < 17; i++ ) crc_16 = update_crc_16(crc_16, Zoom[i]); //calculate crc for the command Zoom[i] = (unsigned char)(crc_16 >> 8); //
-
Thread
BME280 per OneWire mit DS28E17
// I2C Register to read BME.write(0x02); // Number of data bytes to be read BME.write(crc); // CRC 16 [/c] 1. Der BME280 hat mit SDO auf GND eine 7bit Adresse von 0x76. Der DS28E17 erwartet eine 7bit Adresse und schaltet das R/W bit selbständig. Ist es dann korrekt 0xEC zu senden? 2. Der DS28E17 erwartet einen CRC16 auf die gesendeten Bytes. In der OneWire Library sind ja CRC16 Routinen enthalten. Dort muss aber ein crc Wert übergeben werden. Wie hab ich das zu verstehen? [c] uint16_t OneWire
-
Thread
Bus Protokoll Körting/EBV Gamma 2B
for (int b = 0; b < 8; ++b) { if (crc & 1) crc = (crc >> 1) ^ 0x8408; else crc = (crc >> 1); } } return crc & 0xFFFF; }; auto raw_to_out = [&](uint8_t
(crc_src, crc_src_len); uint16_t frame_crc = (uint16_t)bytes[crc_lo] | ((uint16_t)bytes[crc_hi] << 8); if (calc != frame_crc) { ESP_LOGW("CRC","CRC mismatch %04X!=%04X payload
-
Thread
Yet another CRC32 Code
^= POLY; } return crc; }[/c] Damit schrumpf der Code schon mal um 21% (von 86 auf 68 Bytes). [avrasm] crc32: push r16 push r17 mov r16,r20 ldi r17,0 ldi r18,0 ldi r19,0 eor r16,r22 eor r17,
movw r24,r18 pop r17 pop r16 ret [/avrasm] Klar, mit (inline) Assembler geht's immer besser... > : [crc] "+r" (crc), > [tmp] "=&a" (tmp) > : [polynom] "i" (0xEDB88320) > : );
-
Thread
AVR für wenig Geld im LAN
hallo Hans- Werner, kommt bei mir auch, ist doch ok? CRC Error (lost connection?) FC:28 (18B)SN: cc 9a c8 1 0 0 CRC:78 CRC O.K. CRC Error (lost connection?) FC:28 (18B)SN: cc 9a c8 1 0 0 CRC:78 CRC O.K. CRC Error (lost connection?) FC:28 (18B)SN: cc 9a c8 1 0 0 CRC:78 CRC O.K. CRC Error (lost connection?) FC:28 (18B)SN: cc 9a c8 1 0 0 CRC:78 CRC O.K. CRC Error (lost connection?) FC:28 (18B)SN: cc 9a c8 1 0 0 CRC:78 CRC O.K. CRC Error (lost connection?) FC
-
Thread
Alles Rund um den MEDION LIFE P89626 NAS
Daemon erst einmal im Vordergrund starten: # ./dropbear -F -r dropbear_rsa_host_key -E [26337] Dec 02 17:02:10 Failed reading '/etc/dropbear/dropbear_dss_host_key', disabling DSS [26337] Dec 02 17:02:10 Not backgrounding [26485] Dec 02 17:02:28 Child connection from 192.168.178.32:41077 [26485] Dec 02 17:02:42 Bad password attempt for 'tuxopa' from 192.168.178.32:41077 [26485] Dec 02 17:02:46 Exit before auth (user 'dirkg', 1 fails): Exited normally [26612] Dec 02 17:02:51 Child connection from 192.168.178.32
-
Thread
Floppy MFM Decoder selber bauen AVR ATmega Assembler Beispiele FDD Diskette
> ... würdest Du dafür die CRC-Routine schreiben? Im Anhang ist eine CRC16-CCITT Routine mit einem Aufruf der Daten eines ID-Records. [pre] ID-Record: a1 a1 a1 fe 14 00 01 02 CRC: 1b 39 [/pre]
meine Stärke, ich könnte sie dann in Assembler > umfummeln :-) Erklärung: http://www.ross.net/crc/download/crc_v3.txt
-
Thread
Andere Crc32 Frage
(7) XOR crc_i(0) XOR crc_i(24) XOR crc_i(21) XOR data(2) XOR crc_i(20) XOR crc_i(29) XOR crc_i(16) XOR data(3) XOR crc_i(28); crc_c(17) <= data(14) XOR data(10) XOR data(9) XOR data(6) XOR crc_i(1) XOR crc_i(
(3) XOR crc_i(28); crc_c(23) <= data(15) XOR data(14) XOR data(0) XOR crc_i(7) XOR crc_i(31) XOR crc_i(17) XOR data(2) XOR crc_i(29) XOR data(9) XOR data(6) XOR crc_i(16) XOR crc_i(25) XOR crc_i(22); crc_c(
-
Thread
SD-Karte initialisieren
uint8_t data = 0xFF; mmcDisable(); // CS=HIGH mmcSend(data); uint8_t crc = 0; #ifdef MMC_CALC_CRC7 crc = mmcCRC7(crc, command); crc = mmcCRC7(crc, (uint8_t)(address >> 24)); crc = mmcCRC7(crc, (uint8_t)(address >> 16)); crc = mmcCRC7(crc, (uint8_t)(address >> 8)); crc = mmcCRC7(crc, (uint8_t)(address)); crc = crc | 1; #else crc = 0x95; #endif mmcWait(); mmcEnable(); for (uint8_t i = MMC_COMMAND_TRIALS; i > 0; i--) { mmcSend(command
-
Thread
default von Switch wird nicht abgearbeitt
15: *(ptr+pos )= input; pos++; //protoflag |= (1<<RxComp); //t= CalcCRC16(dataRX,15); if (CalcCRC16(ptr,15)!=0)//CalcCRC16(dataRX,15) { error++; pos=0; } else { pos=0; protoflag |= (1<<RxComp);
pos )= input; pos++; //protoflag |= (1<<RxComp); //t= CalcCRC16(dataRX,15); if (CalcCRC16(ptr,15)!=0)//CalcCRC16(dataRX,15) { error++; pos=0; } else {
-
Thread
AT86RF230 - Automatische CRC16 Erzeugung Fehler..
CRC in den Speicher des RF230 schreiben ============= static void spi_write_frame (uint16_t two_byte) { PORTB &= ~(1<<PB0); // SEL low SPDR = 0x60; // SPI write Frame // do 17 clock-cycles
Wartezeiten, bis das SPI-Interface wieder das nächste Byte reingeschoben hat, sinnvoll mit dem Updaten der CRC verbringen. Wenn ich mich nicht verzählt habe, benötigt _crc_ccitt_update() 17 CPU-Takte, während das SPI minimal (d. h. höchste Taktrate und SPI2X gesetzt) 16 CPU-Takte für das Reinschieben eines
-
Thread
STM32 CRC mit 3 Byte Daten
ldi r16, 8 ;8 Verschiebungen ;ONE_WIRE_CRC7_200: eor r18, r17 ;CRC berechnen ror r18 ;Ergebnis in Carry schieben mov r18, r17 ;letzten CRC-Wert
---------------------------------------- ; hier ist die CRC-Summe berechnet, mit empfangenem Wert überprüfen LDS temp,(ow_Data+8) ; ev. Korrektur ;STS(ow_Data+7),R17 ;eigentlich unnötig cp temp,r17 brne PC+3 ;ONE_WIRE_CRC7_ERROR CLC
-
Thread
Zeigt her eure S.M.A.R.T.-Werte!
0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 17 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032
< 000 Old_age Always - 47 (Lifetime Min/Max 0/17)
-
Thread
Debug ANSI C Programm, RaspberryPI.
if ( (fp = fopen ( fn, "r" )) == NULL ) { return(temp); } else { fgets( crc_buffer, sizeof(crc_buffer), fp ); if ( !strstr ( crc_buffer, crc_ok ) ) { syslog(LOG_INFO, "%s", crc_buffer); syslog(LOG_INFO, "CRC check failed, SensorID: %s", sensorid);
s/w1_slave", sensorid); if ((fp = fopen(fn, "r")) == NULL) return -errno; if (fgets(crc_buffer, sizeof(crc_buffer), fp) == NULL) { ret = -EOF; goto error; } if (!strstr(crc_buffer, crc_ok)) { syslog(LOG_INFO, "%s", crc_buffer); syslog(LOG_INFO, "CRC check
-
Thread
Problem beim SRAM testen
!= iCRC){ // wenn nicht, Fehlerroutine aufrufen while(1){ cli(); wdt_disable(); DDRB = 0xFF; DDRD = 0xFF; PORTD = iCRC>>8; PORTB = iCRC;
cFlashZeiger = FlashA; } else{ for(int i = 0; i <= iFlashTestLaenge; i++){ iCRC = _crc_ccitt_update(iCRC, pgm_read_byte(cFlashZeiger++)); } } } [/c] wobei die while(1)-Schleife im moment nur zu Testzwecken drin ist um zu sehen was denn die CRC-Routine berechnet
-
Thread
eBus CRC Berechnung nachvollziehen
/* Initialwert */ uc_crc = (unsigned char) 0; for (i = 0; i < sizeof(auc_bytestream); i++) { uc_crc = crc8_calc(auc_bytestream[i], uc_crc); } printf("CRC: 0x%02X\n", uc_crc); return 0; }
byte for _, dataByte := range data { crc = dataByte ^ table[crc] } return crc } // Diese Variante funktioniert bei echtem CRC-8 // in der loop: crc = table[dataByte ^ crc] func correctTableCRC(data []byte) byte { var crc byte
-
Thread
KWB Kessel RS485 Protokoll
[c] int Checksum(unsigned char* data, unsigned char length) { int i; unsigned char crc = 0; crc = data[0]; // = 0x02 for (i = 1; i < length; i++) { crc = rotl(crc, 1); if (crc + data[i] > 255) { crc = crc + data[i] + 1; } else crc = crc + data[i]; } return crc; } [/c]
-
Thread
Was ist aus dem Thread der MeteoData geworden? Gesperrt
Bezüglich der Vermutung es könnte sich bei den ersten 12 Bit (ohne Alarmbits)um einen CRC-12 handeln, habe ich mal ein paar Versuche mit dem Programm "CRC RevEng v0.40" [http://regregex.bbcmicro.net/reveng-readme.htm] gemacht. Mit dem Programm kann man auch unbekannte CRC Algorythmen/Parameter
gekippt, also das Jahr 2089 eingestellt. Das letzte Bit deshalb, da ich in den ersten 12 Bit eine CRC vermutet habe. Die CRC wird gebildet, indem der CRC Wert um ein Bit geschoben wird und ne 1 rausfällt wird nen XOR mit dem Generatorpolynom gemacht. Wenn ich nun das letzte Bit von 0 auf 1 setze
-
Thread
An Bit Experten: "Alles CRC oder was?" - oder so.
01011100 18.7 44 000000011000 111000100000 01101101 18.0 47 011011101000 100010100000 01101101 17.6 51 100000011000 011000100000 01101101 18.1 46 100000011000 011000100000 01101101 18.1 46 111011101000 000010100000 01101101 17.7 50 111011101000 100100100000 01111101 17.7 49
10011011 18.3 47 000000011000 011000100000 10101010 18.0 46 001011101000 010010100000 10101010 17.4 52 101011101000 100010100000 10101010 17.5 51 101011101000 100010100000 10101010 17.5 51 000100011000 001000100000 11011000 18.8 44 001000011000 000100100000 11011000 18.4 48
-
Thread
Flash CRC Berechnung optimieren/schneller
#7397443: > Ich hab mal schnell was zusammengestrickt, ich komme auf 55 Takte/Byte Die Lib in crc16.h des AVR-GCC ist inline-Assembler (23 Zyklen) und braucht mit Loop-Overhead zusammen 41 Zyklen. Die CRC-CCITT ist mit 17 Zyklen etwas kürzer.
Peter D. schrieb im Beitrag #7397834: > Die Lib in crc16.h des AVR-GCC ist inline-Assembler (23 Zyklen) und > braucht mit Loop-Overhead zusammen 41 Zyklen. > Die CRC-CCITT ist mit 17 Zyklen etwas kürzer. Das widerspricht aber der Wahrnehmung des OP
-
Thread
DS1820, DS18B20 in C
{ data = ow_buffer[loop_count]; bit_counter = 8; do { feedback_bit = (crc ^ data) & 0x01; if ( feedback_bit == 0x01 ) { crc = crc ^ CRC8POLY; } crc = (crc >> 1) & 0x7F; if ( feedback_bit == 0x01 ) { crc = crc | 0x80;
loop_count++) { b = data[loop_count]; bit_counter = 8; do { feedback_bit = (crc ^ b) & 0x01; if ( feedback_bit == 0x01 ) { crc = crc ^ CRC8POLY; } crc = (crc >> 1) & 0x7F; if ( feedback_bit == 0x01 ) { crc = crc | 0x80; }
-
Thread
CRC Berechnung für Ethernet
invertiert werden. [vhdl] for i in 0 to data'left loop data(i) := data(data'left - i); end loop; crc <=nextCRC32_D8(data, crc); [/vhdl] 3. Am Ende der Payload muss der komplette CRC Wert invertiert werden und die Bits anschließend wieder vertauscht werden. 4. Die CRC wird mit dem LSB Byte
<= SendCRC2; when SendCRC2 => OutByte <= CRCResultInverted( 31 downto 24); SendBufferState <= SendCRC3; when SendCRC3 => OutByte <= (others => '0'); TXOut <
-
Thread
Abschlussprojekt
stell mal ungefähr 25% (4000) bei dem einen und 50% (8000) bei dem anderen ein: [avrasm] ldi r17,0x0f ldi r16,0xa0 out OCR1AH,r17 out OCR1AL,r16 ldi r17,0x1f ldi r16,0x40 out OCR1BH,r17 out OCR1BL,r16 [/avrasm] So und jetzt noch die Ports als Ausgänge definieren. Table 31 auf Seite
TCCR1B, temp ;So und jetzt noch die von mir willkürlich gewählte Testpulsweite einstellen ldi r17,0x0f ldi r16,0xa0 out OCR1AH,r17 out OCR1AL,r16 ldi r17,0x1f ldi r16,0x40 out OCR1BH,r17 out OCR1BL,r16 [/avrasm] Eine kleine Motivation am Rande: [c] DDRD = 0b00110000; ICR1 = 15999
-
Thread
ISR Code schneller machen?
// Bytes rausschieben } uart0_putc(ETX); MAX487_Empfangsmodus(); } uint16_t calc_CRC16 (uint8_t feld[], uint8_t length) { uint16_t crc = 0xFFFF; // initial CRC value uint8_t b = 0; while (length--) { crc = _crc16_update(crc, feld[b++]); } return crc;
Pointer-Kram angeht und weis auch nicht, wie weit der Compiler hier optimiert. [pre] uint16_t crc16_update(uint16_t crc, uint8_t a) { int i; crc ^= a; for (i = 0; i < 8; ++i) { if (crc & 1) crc = (crc >> 1) ^ 0xA001; else crc = (
-
Thread
Junkers HT-Bus Heatronic 3 Schnittstelle
6E <= 6E 16 00 17 00 10 00 90 00 06 00 0B 01 0F 0D 27 07 04 00 58 <= 0D [/code] Grüße.
wohl fummeln oder evtl. haben die auch ein Monitormenü !? Anbei noch die Raw-Daten mit korrekter CRC. Grüße.
-
Thread
STM32 - Crc Berechnung in C# nachbilden
Hallo, ich möchte mit C# folgende Crc Funktion nachbilden: [c] uint32_t CRC_CalcCRC(uint32_t Data) { CRC->DR = Data; return (CRC->DR); } [/c] In main wird diese Funktion so eingesetzt: [c] CRC_ResetDR(); CRCValue
[Crc >> 28]; Crc = (Crc << 4) ^ CrcTable[Crc >> 28]; Crc = (Crc << 4) ^ CrcTable[Crc >> 28]; Crc = (Crc << 4) ^ CrcTable[Crc >> 28]; } return(Crc); } /*******************
-
Thread
CRC - Byte-weise oder Wort-weise?
byteBuf[], uint32_t bufLen ) { uint32_t crcTable[256] = { 0x00000000, 0x77073096, 0xEE0E612C, 0x990951BA, 0x076DC419, 0x706AF48F, 0xE963A535, 0x9E6495A3, 0x0EDB8832, 0x79DCB8A4, 0xE0D5E91E, 0x97D2D988, 0x09B64C2B, 0x7EB17CBD,
RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fARM%20CortexM3%20STM32%2fCRC%20calculation%20in%20software&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000626BE2B829C32145B9EB5739142DC17E¤tviews=1761 Der Autor hat herausgefunden, wie die CRC-Berechnung beim STM32
-
Thread
Fehler in AVR-GCC 3.4.6
stream[4+i] = aBuffer->Seq; // sequence number stream[5+i] = (unsigned char)(aBuffer->CRC >> 8); // CRC HIGH stream[6+i] = (unsigned char)(aBuffer->CRC); // CRC LOW crc = 0; // < zum test, gleicher fehler wie: CRC16(stream, i+7); return crc; } unsigned int Handle_Device
stream[4+i] = aBuffer->Seq; // sequence number stream[5+i] = (unsigned char)(aBuffer->CRC >> 8); // CRC HIGH stream[6+i] = (unsigned char)(aBuffer->CRC); // CRC LOW crc = 0; // < zum test, gleicher fehler wie: CRC16(stream, i+7); return crc; } unsigned int Handle_Device
-
Thread
Heizungs-Datenerfassung (HT3)
thread start 17.11.2018 09:56:01 INFO: Client-ID:2; ('127.0.0.1', 56332) disconnected 17.11.2018 09:56:01 INFO: Client-ID:2; removed; number of clients:1 17.11.2018 09:56:01 INFO: Client-ID:1;cportwrite();couldn't read from queue 17.11.2018 10:00:49 INFO: Client-ID:3; ('127.0.0.1', 56334) connected 17.11.2018 10:00:49 INFO: Server :('0.0.0.0', 8088) 17.11.2018 10:00:49 INFO: Client-ID:3; register(); got devicetype:MODEM 17.11.2018
-
Thread
Frame Check Sequence
erstmal richtig? data ist der Empfangspuffer, len die Packetlenge (hier 115 Bytes). [c] uint32_t crc32(const uint8_t *data, size_t length) { uint32_t crc = 0xFFFFFFFF; for (size_t i = 0; i < length; i++) { uint8_t byte = data[i]; crc = (crc >> 8) ^ crc32_table[(crc ^
uint32_t ch=i; uint32_t crc=0; for(size_t j=0;j<8;j++) { uint32_t b=(ch^crc)&1; crc>>=1; if(b) crc=crc^0xEDB88320; ch>>=1; } crc32_table[i]=crc; } } uint32_t crc32_fast(const uint8
-
Thread
CRC-Rätsel (IRDA)
man die Bytes B5 und B6 "entschlüsseln". Ich selbst habe bereits die CCITT-CRC16 und auch die CRC16, die in der avr-libc enthalten sind, mit allen 65536 möglichen Startwerten durchprobiert. Leider kann ich nicht alle 3 CRCs mit demselben Startwert reproduzieren. Vielleicht
Vlad Tepesch schrieb im Beitrag #4086053: > hast du denn probiert, ob der CRC möglicherweise nur über die beiden > Bytes gebildet wird, Ja, ich habe CRC sowohl über die ersten 4 Bytes als auch über die 2 Bytes der Transponder-ID probiert. > oder irgen eine andere Art
-
Thread
Ab wann macht CRC8, 16 oder 32 Sinn?
Phi * Daumen: bis 256 Byte: CRC8 bis 64kB: CRC16 Peter
>Phi * Daumen: >bis 256 Byte: CRC8 >bis 64kB: CRC16 Nein. Es sind CRC8 schuetzt bis 2^8 bit = 32byte CRC16 schuetzt bis 2^16 bit = 8kbyte CRC32 schuetzt bis 2^32bit = 500MByte
-
Thread
AT86RF230 - SRAM Read Access fehlerhaft..
_t rec_frame = spi_read_frame(); // die ersten 2 byte einlesen if (crc_calc (crc_poly, (rec_frame>>8), rec_frame) != 0) goto Abbruch; // CRC-Check // wenn CRC check sagt 'recFrame' ist defekt oder nicht unseres -> Abbruch // 64µs warten, dann das 2nd Frame einlesen
read Kommando, PHR lesen. Wenn Länge != 4 => Abbruch. Zwei weitere Bytes abwarten und einlesen, CRC überprüfen, wenn falsch => Abbruch. Noch zwei Bytes abwarten und lesen, gegen die vorigen vergleichen, wenn falsch => Abbruch. CRC abwarten und lesen, /SEL auf high. CRC-16 noch vergleichen (wenn's
-
Thread
STM32 Seriennummer Shrink
#5976291: > Meine Implementation für einen Shrink der ID hätte ich aktuell so > vorgestellt: > > CRC16 aus Byte 0..4 errechnen > CRC16 aus Byte 4..11 errechnen > > aus den 2x2 byte einen fiktiven uint_32 zusammensetzen also CRC1 | > CRC2<<16 Und wieso benutzt Du nicht die interne CRC calculation
#5976291: >> Meine Implementation für einen Shrink der ID hätte ich aktuell so >> vorgestellt: >> >> CRC16 aus Byte 0..4 errechnen >> CRC16 aus Byte 4..11 errechnen >> >> aus den 2x2 byte einen fiktiven uint_32 zusammensetzen also CRC1 | >> CRC2<<16 > > Und wieso benutzt Du nicht die interne CRC
-
Thread
Knobelei: CRC Polynom / Checksummen-Algorithmus gesucht
0xCC, 0xCB, 0xE6, 0xE1, 0xE8, 0xEF, 0xFA, 0xFD, 0xF4, 0xF3, ] # # update with table # def crc8_update_table(d,crc): return crc8_table[d^crc]; # # crc8 algorithm # def crc8_algo(crc): for x in range(0,8): if crc & 0x80: crc = (crc << 1)&0xfe; crc ^= CRC8_POLY else: crc = (crc << 1)&0xfe; return crc # # update with algorithm # def crc8_update_algo(d,crc): crc ^= d return crc8_algo(crc) # # calculate crc from buffer # def crc8_calc(buf,l): crc =
-
Thread
CRC32 mit stm32
%20CortexM3%20STM32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/CRC32%20calculation%20mismatch&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000626BE2B829C32145B9EB5739142DC17E¤tviews=635 CU Dirk
RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fARM%20CortexM3%20STM32%2fCRC%20calculation%20in%20software&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000626BE2B829C32145B9EB5739142DC17E¤tviews=2028 sorry für den langen Link. Aber das Beispiel steht weiter unten
-
Thread
Space Age 2 der 32Bit MIPS Rechner in TTL
fertig. Die einzelnen Teile der Netzwerkkarte funktionieren bereits in der VHDL Simulation und der CRC generator wird grade ausgebaut zu einem General Purpose CRC. Denn der HW CRC beschleunigt die CRC Berechnung mal eben um den Faktor 17. Dafür sind nur ein paar ICs mehr nötig und das passt schon wenn danach nicht nur die Netzwerk CRC32 berechnet werden kann. Die Polynome stecken eh in einer LUT und da sind noch Adresspins frei für mehr LUTs. Für CRC16/8 muss nur die Schiebeweite des Eingangsbytes verändert werden. Das ReflectIn