-
Thread
CRC-16 Prüfsumme (serielle Übertragung)
; crc ^= (unsigned char)(crc & 0xff) >> 4; crc ^= (crc << 8) << 4; crc ^= ((crc & 0xff) << 4) << 1; return (crc); } Keine Loop und fast nur byte oder nibble swaps. Über die Qualität des
, 0xD68D, 0xE70E, 0xF78F }; unsigned short crc_update (unsigned short crc, unsigned char c) { crc = (((crc >> 4) & 0x0FFF) ^ crc_tab[((crc ^ c) & 0x000F)]); crc = (((crc >> 4) & 0x0FFF) ^ crc_tab[((crc ^ (c>>4)) & 0x000F)]); return
-
Thread
CRC16 - schnellere Implementierung möglich?
Dann berechne doch den CRC erst beim Senden der einzelnen Zeichen und nicht am Stück voe oder nach dem senden: alt: berechne_crc(string) sende(string) neu: for(position=0;position<sizeof(string);position++) { crc=berechne_crc
calc(const uint8_t *data, size_t length) { uint16_t temp; uint16_t crc_word = CRC16_PRELOAD; while(length--) { temp = crc_word & 0xFF; crc_word = (crc_word >> 8) | ((uint16_t)*data++ << 8); crc_word ^= crc_table[temp]; } return crc_word
-
Thread
Billig ds18b20 Fehlverhalten erfahrungen?
das ja auch so mache, also mit aktivem Pullup vom AVR in der Messphase. > Deine gelegentlichen CRC-Fehler sind ein Indiz dafür das es eben doch > nicht ganz rund läuft. CRC Fehler und Messfehler sind zwei paar Stiefel. Dass die Verkabelung nicht optimal ist (u.A. ein 3er Flachkabel über zig
bezüglich Linearität, Langzeit etc. Die dort genannten D2-ROM patterns [5]: 28-tt-tt-79-97-ss-ss-crc, 28-tt-tt-94-97-ss-ss-crc, 28-tt-tt-79-A2-ss-ss-crc, 28-tt-tt-16-A8-ss-ss-crc, 28-tt-tt-56-B5-ss-ss-crc (2020), 28-tt-tt-07-D6-ss-ss-crc (2020) enthalten scheinbar nicht die neuesten "Lieferungen"
-
Thread
16Bit CRC / 17Bit CRC Polynom
"X^16+X^15+X^2+x^0" Suche einen einfachen CRC -Algorithhmus bei dem ich ein CRC-Polynom mit 17Bit (siehe oben) verechnen kann. Die meisten 16Bir CRC (Ergebnis) benutzen Polynome mit einer länge von 16Bit!
@ Faller (Gast) >"X^16+X^15+X^2+x^0" >Suche einen einfachen CRC -Algorithhmus bei dem ich ein CRC-Polynom mit >17Bit (siehe oben) verechnen kann. Das ist ein 16 Bit CRC. Warum? Weil das oberste Bit immer implizit gesetzt ist. Siehe die Links im Artikel [[CRC
-
Thread
Kennt jemand diesen Audio/CAN/BT Chip? CP3CN37VVAWQ
irgendwas von Texas Instruments aufgekauft wurden. Als Datenblatt habe ich nur eines für den CP3CN17: http://www.alldatasheet.com/datasheet-pdf/pdf/125964/NSC/CP3CN17.html Ich denke das der von der Funktion dem CP3CN7 ähnlich ist, aber das Pinout stimmt natürlich nicht da der CP3CN17 im LQFP-100
Olli Z. schrieb im Beitrag #5883432: > Wenn Du sagst "gültige CRC", woher willst Du das denn wissen? Weißt Du > wie sich die CRC berechnet? Wenn ja, bitte mal den Algo nennen, das wäre > doch sehr interessant! Siehe die angehängte Datei. Den CRC Code habe ich
-
Thread
CRC16 per Hand berechnen - Fehler
Hallo zusammen, ich habe ein Problem mit meiner CRC-Berechnung von Hand. Mit der Funktion _crc16_update(uint16_t crc, uint8_t data)der Bibliothek <util/crc16.h>, sowie mit dem Online Rechner von Lammertbies bekomme ich als berechneten CRC-Wert 0x40BF
du auf der von mir verlinkten Seite nach unten scrollst wirst du einige Polynome finden wie z.B.: CRC-16: 0x8005 = x^16 + x^15 + x^2 + 1 Die 1 am Ende steht für x^0. Dieses Polynom ist also eigentlich nicht wie man bei einem flüchtigen Blick annehmen möchte 16 sondern 17Bit lang. Das 17.
-
Thread
MMC/SD CRC7 R8C/M16C/M32C
anl a,#07h ; (2) rl a ; (1) xrl a,r1 ; (1) mov crc7,a ; (1) crc= 7BitCRC.1 ret ; (2) (LCALL=2) -x-x-x-x- snip -x-x-x-x-xx- Zum Checken (Response of CMD17): mov crc7,#00000001b mov a,#0x11 lcall crc7 mov a,#0x00 lcall crc7 mov a,#0x00 lcall crc7 mov a,#0x09 lcall crc7 mov a,#0x00 lcall crc7 ljmp MONITOR-ODER-AUSGABE-von-crc7 rauskommen muss: CRC7=0110011.(1) = 0x67
-
Thread
Warum heisst es bei CRC Prüfsumme?
sofort bereit, auch beim CRC von einer Prüfsumme zu sprechen.
ziemlich unhandlich werden. > > Unhandlich ist der Algo-lose Pseudocode, nicht die CRC Bildungsformeln > die da lediglich lauten: > x^8 + x^2 + x + 1 ; CRC-8-CCITT > oder > x^8 + x^5 + x^3 + x^2 + x + 1; CRC-8-AUTOSAR oder ... Das sind weder die Bildungsformeln
-
Thread
Aufwärmzeit DS18B20 Sensoren
28 E 30 5D 5 0 0 F9 Chip = DS18B20 Data = 1 78 1 4B 46 1F FF 8 10 C1 CRC=C1 Temperature = 23.50 Celsius, 74.30 Fahrenheit ROM = 28 FF A EC 1 17 3 65 Chip = DS18B20 Data = 1 70 1 4B 46 1F FF 1F 10 69 CRC=69 Temperature = 23.00 Celsius, 73.40 Fahrenheit ROM = 28 FF BB FA 53 17 4 61 Chip = DS18B20 Data = 1 78 1 4B 46 1F FF 1F 10 43 CRC=43 Temperature = 23.50 Celsius, 74.30 Fahrenheit No more addresses.
-
Thread
Hilfe bei CRC!
; Meine 8051 X^8 + X^5 + X^4 + 1 Lieblingsroutine: ; (Assembler as31 unter Linux) ; crc8 definieren(!) (notfalls ein Register) ; .... und an Initialisierung des crc8 denken. crc8tab:mov dptr,#CRC8_TAB xrl a,crc8 movc a,@a+dptr mov crc8,a
viele der Java/Javascript/...-CRC Webseiten sind kaputt...) -Hans PS: Willst Du verraten, fuer welche Anwendung Du den ISO-CRC-8 einsetzen willst, ggf. waere da eine Tabellenversion Overkill...
-
Thread
STPM32 - Register beschreiben..
( ( cmd & 0xFF000000) >> 24 ) , 0x00 }; for ( uint8_t x = 0 ; x < ( STPM32_FRAME_WITHOUT_CRC + crcEn ) ; x++ ) { stpm32Tx[x][0] = frameLow[x]; frameLow[STPM32_CRC] = stpm32Crc( frameLow[STPM32_CRC] , frameLow[x] ); } stpm32SpiWrite( frameLow , ( STPM32_FRAME_WITHOUT_CRC + crcEn ) ); for ( uint8_t x = 0 ; x < ( STPM32_FRAME_WITHOUT_CRC + crcEn ) ; x++ ) { stpm32Tx[x][1] = frameHigh[x]; frameHigh[STPM32_CRC] = stpm32Crc( frameHigh[STPM32_CRC] , frameHigh
-
Thread
Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain
ganz sicher. Ich kenne das beispielsweise so: Der Bootloader mach vor er in die App springt eien CRC check dazu wurde die CRC an einen bestimmte Adresse gelegt beim Build-Prozess der App. Wie lauft das beim Fastboot es gibt ja eine CRC aber berechnet er sich diese selber?
bei jedem starten geprüft wird, ob die CRC stimmt? Nein, das macht der bootloader nicht, was sollte er auch tun, wenn das nicht der Fall ist??? Beim Fastboot wird die CRC beim Laden / flashen des Programmes überprüft. Eien CRC selbst muss
-
Thread
Suche Tipp für Encoder
https://standby-shop.eu/en/100k-potentiometer-for-pcb.html Philips CRC-17 Datenblatt https://standby-shop.eu/media/products/5e53d2a7594af465c58fc8d81b373150/attachments/en_US/crc17poti.pdf
schrieb im Beitrag #7842385: > https://standby-shop.eu/en/100k-potentiometer-for-pcb.html > Philips CRC-17 > Datenblatt > https://standby-shop.eu/media/products/5e53d2a7594af465c58fc8d81b373150/attachments/en_US/crc17poti.pdf Dieses sieht sehr richtig aus und das Gehäuse ist das richtige. Allerdings
-
Thread
CRC von Ethernet Frame berechnen
1); crc(5) := crc(6) xor crc_feedback; crc(7 downto 6) := crc(8 downto 7); crc(8) := crc(9) xor crc_feedback; crc(
(19 downto 17); crc(19) := crc(20) xor crc_feedback; crc(20) := crc(21) xor crc_feedback; crc(21) := crc(22) xor crc_feedback
-
Thread
CRC Generator in VHDL
splittest du also in 4 teile à 8 bit erster funktionsaufruf: Data <- ersten 8 Bit Daten crc <- Startwert liefert crc1 zweiter funktionsaufruf Data <- zweiten 8 Bit Daten crc <- crc1 liefert crc2 usw. nach dem vierten funktionsaufruf hast du dann den crc für dein komplettes
versteh irgendwie nich, wie du dein CRC berechnest ich hätte da sowas erwartet wie newcrc(0) <= d(16) xor d(0) xor c(0); newcrc(1) <= d(17) xor d(1) xor c(1); newcrc(2) <= d(18) xor d(2) xor c(2); newcrc(3) <= d(19) xor d(3) xor c(
-
Thread
Hilfe bei Übersetzung CRC32-ASM-Makro gesucht
; ;.set CRC32polyInv= 0xEDB88320 ;CRC32 polynom (0x04C11DB7) in inverted bits order ;.set CRC32 = CRC32init ;initialisation of CRC32 ;crc32x schiebt ein Byte durch den CRC ;r17 = Byte Message ;r18 = benutzt ;r16 = benutzt crc32x: ldi r18,8 crc32x2: mov r16,crc324 eor r16,r17 ; CRC32^Message lsr crc321 ; CRC32>>1 ror crc322 ror crc323 ror crc324 ; .if ((CRC32^(Message))&1)
-
Thread
ATTINY45 INPUT PORTB5 funktioniert nicht
3. Änderung des Bootloaders auf (Name ATTY45.ASM): .nolist .include "tn45def.inc" .equ CRC = 17 ; 17 = additional code size .equ VERIFY = 15 .equ ONEWIRE = 3 ;------------------------------------------------------------------------- ;
\ATMELP~1\BOOTLO~1\fboot17>fboot17 /C1 /B4800 /TEST.HEX COM 1 at 4800 Baud: Connected Bootloader V1.7 Target: 1E9206 ATtiny45 Buffer: 64 Byte Size available: 3582 Byte CRC: o.k. Elapsed time: 0.27 seconds Muß jetzt mal
-
Thread
CRC16 Berechnung mit Tabelle
------------------------------------------------------ ; crc16: push r19 push xl push xh ldi xl ,low (twi_buffer) ;Zeiger auf Datenblock ldi xh ,high(twi_buffer) ldi r16 ,0xFF ;CRC-Startwert ldi r17 ,0xFF crc16tab_loop: ldi zh ,high(crc16tab_lo<<1) ld zl ,X+ eor zl ,r16 lpm r16 ,Z eor r16 ,r17 ldi zh ,high(crc16tab_hi << 1) lpm r17 ,Z dec r18 brne crc16tab_loop movw zh:zl ,xh:xl pop
-
Thread
Checksumme berechnen in Biosfile!
sagen! Grüße! Spocky17 P.S.: Hab das Bios File mal angehängt!
Woher weißt du denn, dass es eine CRC Checksumme ist? Und eine CRC Checksumme bildet man nicht durch "zusammenzählen".
-
Thread
Protokoll analysieren aber wie ?
Mutterboard 0x13 Solarzentrale 1 (Adresse 2) 0x14 Solarzentrale 2 (Adresse 3) 0x17 Frischwasserzentrale (Adresse 5) Byte 4 Inkrementalwert Byte 5… Byte xx Noch unklar Letzte Byte CRC8 ? Daten aus der Slave Byte 1 0x02 (STX) Byte 2 0x02 (STX) Byte 3 0xXX
Hallo, ich habe mal schnell versucht den CRC nachzurechnen. Auf der Seite http://www.sunshine2k.de/coding/javascript/crc/crc_js.html kann man CRC rechnen. Ich habe versucht den Master von dir nachzurechnen: 0x02 0x26 0x17 0x41 0x4F
-
Thread
Wieso ändert sich die Bitlänge?
[i+(24+17+16)] = NRZI_nutzdaten[i]; } for(i=0;i<16;i++) { NRZI_frame_senden[i+(24+17+16+laenge)] = NRZI_CRC[i]; } for(i=0;i<24;i++) {NRZI_frame_senden[i+(24+17+16+laenge+16)]= NRZI_FFF_flag_before_Low
zum Problem: ändere ich nun folgende Zeile ab: [c] for(i=0;i<24;i++) {NRZI_frame_senden[i+(24+17+16+laenge+16)] = NRZI_FFF_flag_before_Low[i];}[/c] und zwar auf: [c] if(NRZI_CRC[15]==0) { for(i=0;i<24;i++) {NRZI_frame_senden[i+(24+17+16+laenge+16)] = NRZI_FFF_flag_before_Low
-
Thread
PWM - Breite von 0
*********************************************** Interrupt Extern 3 an P1.0 bzw. Compare-Interrupt CRC *******************************************************************************/ void CRC_ISR (void) __interrupt (10) __using (0) { if (crcval < CRC_RELOAD) { crcval = 0xFF00; }
*************************************/ int main ( void ) { i = 1; j = 2; crcval = CRC_RELOAD; CRCH = ((CRC_RELOAD >> 8) & 0xFF); // Compare-Register CRCL = ((CRC_RELOAD >> 0) & 0xFF); TH2 = ((T2_RELOAD >> 8) & 0xFF); // Timerwert TL2 = ((T2_RELOAD >> 0) & 0xFF
-
Thread
ADS131M06 ADC SPI Python
ADS131_Command import * from ADS131_Reg import* #settings GPIO.setmode(GPIO.BCM) GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_UP) GPIO.add_event_detect(17,GPIO.FALLING) adcC = ADS131_Command() adsReg = ADS131_Reg() spi = spidev.SpiDev() spi.open(0,0) spi.mode = 0b01 spi.max_speed_hz
ich immer die gleiche Nachricht, > unabhängig davon was ich vorher gesendet habe. Schon mal ein CRC hinterher geschickt? Steht auch im Datenblatt! Bzw. CRC abgeschaltet? Nachtrag: Doch, Du hast Recht, das DaBla ist eine Katastrophe. Gruß Jobst
-
Thread
Wie Daten per UART zwischen zwei µCs übertragen?
aber sicher: kommt STX fängts an. Genau genommen brauchts dann kein > ETX mehr. Dann noch eine CRC ans Ende.
würde ich diese Methode ebenfalls präferieren. In die dabei ungenutzten 3 Bit würde ich noch eine CRC packen.
-
Thread
SD Karte via ATmega644 und SPI ansprechen
/Set parameter byte 3 buffer[4] = paramL & 0xff; //Set parameter byte 4 buffer[5] = crc | 0x01; //CRC + Endbit '1' #ifdef DEBUG //Prints the Command printf("Sending CMD: "); for(uint8_t i=0; i<6; i++) printf("0x%x, ", buffer[i]); #endif
ich ohne probs initialisieren aber die 4GB karte will net. Aber ich sehe auuch gerade dass da ein CRC error kommt, ich dachte eigtl dass bei dem ACMD41 die CRC net berücksichtig wird. also hier der momentane code: sd.h [c] #ifndef __SDCARD__ #define __SDCARD__ /* Includes */ #include "
-
Thread
1-Wire Slave auf AVR
einfach mit eingefügt und nun geht’s ohne Probleme. Für den Counter muss wohl ein Attiny25 herhalten. CRC16 und die 80 Bit die zur Abfrage getauscht werden müssen... das geht einfach nicht in 1k. Aber ein alternativer Counter der nicht Kompatibel zu Dallas ist geht bestimmt. Vielleicht mit CRC8 und
und 0xA5 0xA5 + 2 Byte Adresse die nicht ausgewertet werden liefert: X C0 C1 C2 C3 0 0 0 0 CRC0 CRC1 X: letztes (eigentlich adressiertes) Byte C0 C1 C2 C3: 4 Byte Counter LSB first 0 0 0 0: 4 mal 0 nach Spezifikation CRC0 CRC1: 2 Byte CRC LSB first Weis jemand ob dass das SRAM des
-
Thread
Belohnung: Wer macht mit bei meinem Projekt?
Tom, Du hast recht, aber gegen die PC Lösung (wir haben schon ein kleines, schnelles 17x17cm Industrie MiniITX Board mit Pentium M benutzt) spricht erstens der Stromverbrauch und zweitens daß der PC-Bus seine Grenzen erreicht hat. Da ich aber beabsichtige demnächst die nächste (und übernächste
1 f = feedback 2 DD = Data to or from the bus 3 CRCOUT = 16-bit edge triggered result (current CRC) 4 CRCOUT(15:0) are sent on matching order bits of DD(15:0) 5 CRCIN = Output of combinatorial logic (next CRC)
-
Thread
Samsung N150: Dateifehler nach Reparatur
- -- -- -- --------------- -------------------- 60 00 08 00 98 00 00 19 81 1c 70 40 00 00:17:09.861 READ FPDMA QUEUED 60 00 08 00 90 00 00 13 41 11 00 40 00 00:17:09.860 READ FPDMA QUEUED 60 00 08 00 88 00 00 01 2f 77 50 40 00 00:17:09.860 READ FPDMA QUEUED ea 00 00 00 00
response for host-to-device data FIS, non-CRC 0x0012 4 0 R_ERR response for host-to-device non-data FIS, CRC 0x0013 4 0 R_ERR response for host-to-device non-data FIS, non-CRC
-
Thread
Prüfsumme berechnung
Moin, Wenns CRC sein koennte, wuerd' ich mal diesen Thread empfehlen: https://www.mikrocontroller.net/topic/449458 Gruss WK
nur eine Idee. Ich würde mal versuchen ein paar Frames mit evtl Zusatz-Byte in das oben verlinkte CRC Reverse Tool zu packen.
-
Thread
AVR JTAGICE mkII mit Eclipse, gdb timeout
0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 1 bytes read: 80 recv: 0xb5 recv: 0xd8 CRC OK Got message seqno 17 (command_sequence == 17) response: 80 ->GDB: OK GDB: <M20,20:0c943f000c943f000c943f000c943f000c943f000c943f000c943f000c943f00> GDB: Write 32 bytes to 0x20 jtagWrite
0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 1 bytes read: 80 recv: 0xb5 recv: 0xd8 CRC OK Got message seqno 17 (command_sequence == 18) got wrong sequence number, 17 != 18 recv: timeout command[0x04, 2]: 04 A0 20 00 00 00 20 00 00 00 0C 94 3F 00 0C 94 3F 00 0C 94 3F 00 0C 94 3F
-
Thread
Modbus RS485 abfragen mit ESP32 klappt nicht
einen netten Mitmenschen in einem anderem Forum wurde ich darauf aufmerksam gemacht, doch mal die CRC abzuschalten da dies mit dem verwendetetem Marstek Speicher wohl ein Problem sei. CRC deaktiviert und siehe da, sofort kommen die Werte rein. Egal mit welchem RS485 Adapter - eindeutig keine Hardwaresache
bei der Implementierung des modbus einen Fehler gemacht hätten. Es sei dort High- und Lowbyte zur CRC Prüfung vertauscht worden. Ich habe dann die Routine der verwendeten Lib umgebaut und die Bytes vertauscht. Jetzt kommen die Werte auch wieder mit aktivierter CRC Prüfung. Somit für mich Problem
-
Thread
PIC628: ORG und ab ins Nirwana ...
retlw 12h retlw 9 retlw 16h retlw 0bh retlw 17h ... ; viele retlw Zeilen ... retlw 0fh end ################################### Werden nur die Zeilen org 300h und data_crc-300h auf eine andere
grenze crc_1: addlw 30 crc_2: addlw low(data_crc) ; low adresse von data_crc dazu movwf retten ; zusätzlicher speicherplatz movlw high(data_crc) ; high adresse von
-
Thread
DAB+ Modul KeyStone 8650
101759v010201p ansehen. Die 2 Byte sind eine Checksumme: Seite 9 in dem Dokument: The packet_CRC field is calculated, according to the CCITT CRC-16 polynomial, over the entire packet, with the CRC register initialized to all 1s and the resulting CRC inverted. Anbei noch ein Screenshot von der
+ CRC 0x0001 0x00 wie oben ... 0x8019 0x84 + Daten + CRC [/c]
-
Thread
CRC32 vom STM32F4 auf dem PC zurück rechnen?
polynomial 0x00000000,0x04C11DB7,0x09823B6E,0x0D4326D9,0x130476DC,0x17C56B6B,0x1A864DB2,0x1E475005, 0x2608EDB8,0x22C9F00F,0x2F8AD6D6,0x2B4BCB61,0x350C9B64,0x31CD86D3,0x3C8EA00A,0x384FBDBD }; Crc = Crc ^ *((unsigned int *)Buffer); // Apply all 32-bits
[Crc >> 28]; Crc = (Crc << 4) ^ CrcTable[Crc >> 28]; Crc = (Crc << 4) ^ CrcTable[Crc >> 28]; Crc = (Crc << 4) ^ CrcTable[Crc >> 28]; Crc = (Crc << 4) ^ CrcTable[Crc >> 28]; Crc =
-
Thread
GD32F303: Bootloader der Originalfirmware für Open Source Projekt nutzen
kannst du aber ziemlich simpel ausprobieren, da du ja ein Image mit korrekter CRC vorliegen hast. Versuch mal: - In C die crc32_z Funktion der zlib - In Python binascii.crc32 Probier alle Kombinieren aus: - Initialwert 0 oder 0xFFFFFFFF - Endergebnis invertiert oder nicht
M820) konfrontiert, der in den Bytes 14 und 15 offensichtlich eine zweite Checksumme erwartet. Die CRC16 an Bytes 16 und 17 wird berechenet wie oben schon herausgefunden. Kann jemand die Bytes 14 und 15 in dieser Datei zuordnen? https://github.com/EBiCS/BAFANG_GD32F303RCT6/raw/refs/heads/M560/documentation
-
Thread
LON Bus Windhager mitlesen/steuern
1 avg: 511(25,55us) Bit length 1 max: 799(39,95us) Packets received: 13778181 Packets CRC Errors: 7834 (0,06%) Free heap: 231576 Max heap: 321324 Free PSRAM: 0 Max PSRAM: 0 Startup time: 25.11.2021 12:17:42 Statistics start: 25.11.2021
0 min: 60(3,00us) Bit length 0 avg: 251(12,55us) Bit length 0 max: 358(17,90us) Bit length 1 min: 362(18,10us) Bit length 1 avg: 511(25,55us) Bit length 1 max: 798(39,90us) Packets received: 5569 Packets CRC Errors:
-
Thread
dumme Frage zu printf ()
#4616778: > teste mal mit > [c] > #define START 0x02 > printf ("\x" START "%02x:%u:%u\r",adr,data,crc); > [/c] Wohl eher so: [c] #define START "0x02" printf (START "%02x:%u:%u\r",adr,data,crc); [/c] oder so: [c] #define START "02" printf ("0x" START "%02x:%u:%u\r",adr,data,crc);
schrieb: >> teste mal mit >>> #define START 0x02 >> printf ("\x" START "%02x:%u:%u\r",adr,data,crc); >> > Wohl eher so: #define START "0x02" > printf (START "%02x:%u:%u\r",adr,data,crc); > oder so: #define START "02" > printf ("0x" START "%02x:%u:%u\r",adr,data,crc); Volker B. schrieb
-
Thread
CRC auf einem Raspberry Pi in C
802.15.4): [c] uint16_t crc_ccitt_update(uint16_t crc, uint8_t data) { data ^= crc & 0xFF; data ^= data << 4; return ((((uint16_t)data << 8) | ((crc & 0xFF00) >> 8)) ^ (uint8_t)(data >> 4) ^
0x92B9, 0x8330, 0x7BC7, 0x6A4E, 0x58D5, 0x495C, 0x3DE3, 0x2C6A, 0x1EF1, 0x0F78 }; uint16_t CRC16Check (uint8_t* pByteData, int Length) { uint16_t Crc16Value; while(Length--) Crc16Value = CRC16Table[Crc16Value ^ *pByteData++]; return Crc16Value; } [/c]
-
Thread
bidirektionale RS232 Funkbrücke mit RFM12
die bringen etwas mehr Reichweite. Demnächst gibt es aber noch eine ganz neue Version, mit besserer CRC und ein paar behobenen Fehlern.
is 0 01: Number of data bytes to send = 1 05: The 5th packet to send 77: The Data - ascii w 2F: CRC (excluding stuff byte and excluding CRC itself) E2: Garbage Vielleicht interessiert es ja jemanden - die RFM12 scheinen ja weiter aktuell zu sein.
-
Thread
Checksumme von Bin/Hex-Datei berechnen und integrieren.
0x7c26,0x6c07,0x5c64,0x4c45,0x3ca2,0x2c83,0x1ce0,0x0cc1, /* f0 */ 0xef1f,0xff3e,0xcf5d,0xdf7c,0xaf9b,0xbfba,0x8fd9,0x9ff8, 0x6e17,0x7e36,0x4e55,0x5e74,0x2e93,0x3eb2,0x0ed1,0x1ef0, }; uint16_t crc = seed; if (len > 0) { for( uint32_t i = 0; i < len; i++ ) { crc = (uint16_t) ( (crc << 8) ^ crc_ccitt_table
berechnen und einpatchen. Natuerlich duerfen die CRCs nicht in einem Bereich liegen ueber den eine CRC berechnet wird. Es sei denn eine eigene CRC nur ueber die CRCs. Diese CRC darf dann aber in keinem anderen Bereich liegen ueber den eine CRC gebildet wird. Aber das Speicherlayout muss ja sowieso
-
Thread
PIN-Code Algorithmus von Blaupunkt Radio
Bit Werte (Little Endian), gebraucht werden davon die letzten > drei (Block Größe, gepackte Größe, CRC). Die ausgepackte Größe gibt es > nicht im Header und kann auf die Block Größe gesetzt werden. Die CRC ist > nicht Adler32 sondern CRC32, die entsprechende Funktion gibt es in der > LZO Library
findet (z.B.: http://web.mit.edu/freebsd/head/sys/libkern/crc32.c)
-
Thread
CRC Berechnung wie die Funktion aufrufen?
) == 0) { crc = crc >> 1; } else { crc = crc >> 1; crc = crc ^ CRC; } } } return crc; } int main(void) { unsigned int c; int buffer
{ > if((crc & mask) == 0) > { > crc = crc >> 1; > } > else > > { > crc = crc >> 1; > crc = crc ^ CRC; > } > } > } > > return crc; >
-
Thread
Digitale Stromzähler auslesen und in DB speichern
void decodeDataSML()" einfügen/bzw austauschen: #define HLY2018 ....... #ifdef HLY2018 crc_ccitt = refUint(crc,16)^0x0000; // reflected CRC-output and finish it with xor by 0x0000 HLY 2018 #else crc_ccitt = refUint(crc,16)^0xffff; // reflected CRC-output and finish it with
HLY2018 crc = 0x0000; // set crc to begin by 0x0000 HLY2018 #else crc = 0xFFFF; // set crc to begin by 0xffff #endif Gruß Peter
-
Thread
IBM-CRC-16 Codierung der CRC
[pre] CRC = 0xffff Schleife(für jedes Byte): CRC = Berechnung(CRC,Byte) [/pre]
auf: [c] crc_t crc; crc = crc_init(); // fuer alle Characters (oder Strings) in deinem datagramm: crc = crc_update(crc, (unsigned char *)data, data_len); crc = crc_finalize(crc); [/c] [c]/** *
-
Thread
[Info] Comparision of speed of .NET Hash Algorithms (Vergleich)
Datei-Datum unterschiedlich ist. Kai S. schrieb im Beitrag #5494175: > Spontan hätte ich einen CRC Hash mit erwartet. Hat dies einen > technischen Hintergrund, oder hast du ihn einfach nicht getestet? Wie Arc N. (arc) auch schon meinte: Bereits bei 77163 Dateien und CRC32 sagt der Rechner: "There
could not be found (are you missing a using directive or an assembly reference?) HashTestTemp.cs(17,10): error CS0246: The type or namespace name 'TestMethodAttribute' could not be found (are you missing a using directive or an assembly reference?) HashTestTemp.cs(17,10): error CS0246: The type or
-
Thread
Hat jemand Erfahrung mit dem 2,4GHz-Transceiver RFM70?
const unsigned int Bank0_Reg0_29[18]= { // address data (0x20|0x00), 0x7A, //Enable CRC ,CRC=1byte, POWER UP, TX (0x20|0x01), 0x01, //Enable Autoacknownledge datapipe 0 (0x20|0x02), 0x01, //Enable RX Addresses datapipe 0 (0x20|0x03), 0x03, //RX/TX address field width
Dann sind das aber eigentlich 2 Sendungen, wenn ich dich richtig verstehe: - Du sendest 17 Byte - der Slave sendet das ACK - danach sendet der Slave die 17 Byte zurück - der Master sendet das ACK zum Slave Meiner Meinung nach ist das eine mehr als ausreichende Performance. Gruß
-
Thread
I2C-Protokoll aus Datenblatt erfüllt? (Fuel Gauge LC709203F)
Sie ist 0x0B und dann kommt das Bit für Read oder Write noch hinzu. Das ergibt dann erst 0x16 bzw. 0x17. ACK müsste ja jeweils das LOW am 9. Clock-Signal sein. Gibt es dann eine Möglichkeit die CRC automatisch ausrechnen zu lassen oder muss ich die manuell für jeden Befehl ausrechnen? Gruß Daniel
Adressen als gerade Zahlen angegeben, also dient die angegebene Adresse (0x16) zum schreiben, 0x17 ist zum lesen. Du hast auch ein Beispiel unten im ersten Bild, versuche doch: 0x16-0x09-0x55-0xAA und als CRC 0x3B
-
Thread
SD SPI Bytes lesen
ARGS: 0x40, 0x0, 0x0, 0x0, CRC: 0xff, recv.: 0x1. Sending CMD: 41, ARGS: 0x40, 0x0, 0x0, 0x0, CRC: 0xff, recv.: 0x0. 0Sending CMD: 17, ARGS: 0x0, 0x0, 0x0, 0x0, CRC: 0xff, recv.: 0x0. read 32 Bytes after address 0x10cc offset
. Sending CMD: 41, ARGS: 0x40, 0x0, 0x0, 0x0, CRC: 0xff, recv.: 0x1. Sending CMD: 55, ARGS: 0x40, 0x0, 0x0, 0x0, CRC: 0xff, recv.: 0x1. Sending CMD: 41, ARGS: 0x40, 0x0, 0x0, 0x0, CRC: 0xff, recv.: 0x0. 0Sending CMD: 17, ARGS: 0x0, 0x0, 0x0, 0x0
-
Thread
Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung
BC 00 07 AA 55 REC : AA 55 08 00 34 00 3C 02 5E 02 5E 21 00 01 00 00 00 F6 57 00 0D E1 00 3E 00 17 AA 55 REC : AA 55 08 00 18 00 2F 01 D4 64 17 89 01 25 62 80 00 02 5E 01 B8 00 33 0C 2D 48 00 C8 00 02 00 39 00 1F AA 55 REC : AA 55 10 88 14 00 03 6E 00 07 AA 55 REC : AA 55 08 10 14 00 26 2C A6
- bei Byte28, der Rest ist CRC, BREAK und Telegrammlänge. //Niffko