-
Thread
[Transceiver] Sammelbestellung!?
Die Preisliste von laipac: http://www.laipac.com/Downloads/Orders/Order%20Form%20LTE%20EUROS%2003-17-04p.pdf @André: Habe die Module noch nicht getestet, werde mich aber heute abend dran versuchen. Der Chip implementiert einen CRC-Check, sodass die Daten mit hoher Wahrscheinlichkeit richtig ankommen
copy&paste lässt grüßen: Muss natürlich heißen: Modus 3: 16 Bit CRC
-
Thread
Hadamard Transformation
schafft es für dieses script bis zu MLS der Länge 511, mein Ziel sind Ortungen mit MLS der Länge 2^17-1, dazu müßte ich ~ 8*2^34 Byte Speicher für eine Matrix haben, das klappt so nicht ;-))), deswegen werde ich das entweder in Matlab oder C so umbauen, dass ich die Permutationen für 2^17-1 berechnen
, $1609, $1647, $1655, $1659, $16A5, $16BD, $1715, $1719, $1743, $1745, $1775, $1789, $17AD, $17B3, $17BF, $17C1, $1857, $185D, $1891, $1897, $18B9, $18EF, $191B, $1935, $1941, $1965, $197B, $198B, $19B1, $19BD, $19C9, $19CF, $19E7, $1A1B, $1A2B, $1A33, $1A69, $1A8B, $1AD1
-
Thread
Hommage an Lothar Miller
Datenblätter von Zilogs Z-SIO reinziehen! René D. schrieb im Beitrag #2607192: > wie wird dann die CRC gefunden? Die muss doch sicher erkannt werden? Dazu muss man erst einmal den Blockanfang finden. Nach wievielen Bytes dann der CRC zu finden ist, wird genau wie bei den asynchronen Verfahren,
Blockanfang feststellen, und "weiß" dann auch, wann Informationen wie z.B. Adresse, oder eben der CRC kommen. Deshalb kann sich ein zu be
-
Thread
SD-Card schreiben auf Arduino due mit Atmel-Studio
ACMD13 (0xC0+13) /* SD_STATUS (SDC) */ #define CMD16 (0x40+16) /* SET_BLOCKLEN */ #define CMD17 (0x40+17) /* READ_SINGLE_BLOCK */ #define CMD18 (0x40+18) /* READ_MULTIPLE_BLOCK */ #define CMD23 (0x40+23) /* SET_BLOCK_COUNT (MMC) */ #define ACMD23 (0xC0+23) /* SET_WR_BLK_ERASE_COUNT
Argument[15..8] */ xmit_spi((BYTE)arg); /* Argument[7..0] */ n = 0x01; /* Dummy CRC + Stop */ if (cmd == CMD0) n = 0x95; /* Valid CRC for CMD0(0) */ if (cmd == CMD8) n = 0x87; /* Valid CRC for CMD8(0x1AA) */ xmit_spi(n); /* Receive command response */ if (cmd ==
-
Thread
ATmega EEPROM beschreiben/lesen
Werte aus. Hier die Aufrufe zum Beschreiben: [c] EEPROM_schreiben (6, sint_Flow_Digits); sint_crc = (sint_Flow_Digits%CRC_DIV); //CRC bilden EEPROM_schreiben (8, sint_crc); EEPROM_schreiben (2, sint_offsetfehler); sint_crc = (sint_offsetfehler%CRC_DIV); //CRC bilden EEPROM_schreiben
(6); //Adresse 6 im EEPROM lesen sint_crc_check = EEPROM_lesen(8); //Adresse 8 im EEPROM lesen if ((sint_dummy%CRC_DIV == sint_crc_check) && ( sint_dummy != 0xFFFF)) //Bereits ein Speichervorgang in EEPROM? sint_Flow_Digits
-
Thread
STM32F4 und LTC6803-4, Probleme mit dem SPI und der Antwort des LTC
void CRC8_Init(void) { uint16_t i, j; uint8_t crc; for (i = 0; i < 256; i++) { crc = i; for (j = 0; j < 8; j ++) { crc = (crc << 1) ^ ((crc & 0x80) ? 0x07 : 0); }
*/ uint8_t CalcPEC_Packet(uint8_t Len) { uint16_t i; /* Initialize PECbyte */ uint8_t crc = 0x41; for (i = 0; i < Len; i++) { crc = CRC8_Table[(crc) ^ LTC6803_RX[i]]; } return crc; } [/c] Meine main-Routine: [c] /* Write Configuration Registers (Broadcast Write) *
-
Thread
Wer hat Lust auf Protokollanalyse? BMS unbekannter Hersteller
Bit AD-Wandler drin sein. Da wird ein 12 Bit AD-Wandler drin sein. 13*8*2 = 208 Bit 208 : 12 = 17,33 Langt also für 17 Werte.
Byte lange Kommando-Codes, aber dann schickt er mir für z.b. einen Request "0x10 0x05 0x13 0xYY 0xCRC" trotzdem die Response für 0x13. Scheinbar führt er da keinen Format check durch. Ich finde es sehr seltsam, dass er da nur 13 Werte liefert für die 17 Zellen. Aber ja, bei chinesischen Billigprodukten
-
Thread
CRC Berechnung anhand Tabelle
untere nibble der CRC-ID (0xFFF) auf CRC-ID (0xFF) geschnitten werden. crc_ist = K_CRC_TABLE_CRC8[crc_ist^(_applid >> 8)]; // Berechne CRC vom Datenbereich if (_CRCoffset>0) { for(i = 0; i < _length - 1; i++) { crc_ist = K_CRC_TABLE_CRC8[crc_ist^_data[i + _offset]]; } } else { for(i = 1; i < _length; i++) { crc_ist = K_CRC_TABLE_CRC8[crc_ist^_data[i + _offset]];
-
Thread
Problem mit CRC-Test wenn Tabelle im EEPROM - mega88
0x0CC1, /* f0 */ 0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8, /* f8 */ 0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0 }; /** * Method generates partial CRC16 checksum, for using in time critical * conditions and applications. */ void calc_crc_partial(void) { byte bTemp; byte bix; word wTab; u_crc.b_CRC[3] = u_crc.b_CRC[2]; u_crc.b_CRC[2] = u_crc.b_CRC[1]; bTemp = u_crc.b_CRC[0]; bix = u_crc.b_CRC[2] ^ b_ROM; wTab = crctttab[bix]; u_crc.w_CRC[0] = wTab; u_crc.b_CRC[1] = u_crc.b_CRC
-
Thread
CRC 8 Probleme bei cyclic redundancy check
CsBitPos - CsBitRem) / 8; switch (MsgID) { case 0x3C: {xor_value = 197;}; break; //CRC_CON_VEH case 0x1CA: {xor_value = 116;}; break; //CRC_CTR_CNV_48V_2 default: {return(-1);} } CheckSum = CRC8_11D_LookUpTable[(byte)(xor_value & 0x00ff)]; CheckSum = CRC8
Nop schrieb im Beitrag #5942852: > Danach gehst Du zu https://create.stephan-brumme.com/crc32/ , was zwar > für CRC32 ist, aber das Prinzip ist dasselbe. > > Da findest Du auch Code, um die Lookuptabelle für CRC32 zu generieren. > Dann schaust Du, wo Du das Generatorpolynom für CRC32
-
Thread
CRC-Neuling
; i++) { m = mem[i]; for( j = 8; j; j-- ) { b = 0; if(crc & 0x80)//00) b++; crc <<= 1; // Shift the register left by one bit, if ((m & 0x80) != 0) crc |= 1; m <<= 1; if (b != 0) /
http://www.riccibitti.com/crc.htm http://www.riccibitti.com/crcguide.htm
-
Thread
CRC look-up table
during calc ushort crc_crc; // holder of CRC int crc_i; // loop counter char j; // loop counters for( crc_i = 0; crc_i < 256; crc_i++) { crc_data = (crc_i << 1); crc_crc = 0; for( j = 8; j > 0; j--) { crc_data >>= 1; if( (crc_data ^ crc_crc) & 0x0001) crc_crc = (crc_crc >> 1) ^ 0xA001; else crc_crc >>= 1; } // endfor j crc16_Table[crc_i
-
Thread
CRC calculation unit
0xcd4dbdaa, 0x8dc97c26, 0x5c644c45, 0x3ca22c83, 0x1ce00cc1, 0xef1fff3e, 0xbfba8fd9, 0x9ff86e17, 0x7e364e55, 0x2e933eb2, 0x0ed11ef0 }; uint32_t CRC_CalcBlockCRC(uint32_t pBuffer[], uint32_t BufferLength) { uint32_t index = 0; for(index = 0; index < BufferLength; index++) {
void CRC_ResetDR(void) { /* Reset CRC generator */ CRC->CR = CR_RESET_Set; }
-
Thread
AVR: Wetterinformationen über DCF77 Gesperrt
I wrote "CRC", not "CBC". Poul-Henning
http://www.zorc.breitbandkatze.de/crc.html habe ich gefunden . wenn man bischen mit spielt könnte man vermuten die ersten acht bits gehören zu einem CrC meine Einst. CRC Order 8/CRC Poly 4/nächsten beiden 0. Data länge
-
Thread
Code in den Atomic Block verschleppt
0f add r30, r30 176: ff 1f adc r31, r31 178: ee 0f add r30, r30 17a: ff 1f adc r31, r31 17c: ef 59 subi r30, 0x9F ; 159 17e: ff 4f sbci r31, 0xFF ; 255 180: 00 83 st Z, r16 182: 19 83 std Y+1, r17 ; 0x01
tmp[0] = (x >> 0) & 0xff; tmp[1] = (x >> 8) & 0xff; x = 0xffff; x = _crc16_update(x, tmp[0]); x = _crc16_update(x, tmp[1]); tmp[2] = (x >> 0) & 0xff; tmp[3] = (x >> 8) & 0xff; volatile uint8_t* volatile pI2CBuffv = &txbuffer[i*4];
-
Thread
SMART Werte eine defekten Platte
Axel S. schrieb im Beitrag #6877842: > Ich habe derzeit 17 TB im aktiven Datenbestand. Da hätte ich Probleme, > überhaupt ein Medium zu finden, wo das alles drauf paßt. Das Finden sollte kein Problem sein. Das Bezahlen vielleicht eher: https://www.youtube.com
changed from 118 to 102 <- Nov 10 17:08:52 1 Raw_Read_Error_Rate changed from 117 to 118 Nov 10 15:38:52 1 Raw_Read_Error_Rate changed from 115 to 117 Nov 10 15:08:53 1 Raw_Read_Error_Rate changed from 114 to 115 sinkt der Wert X
-
Thread
datenübertragung mit crc5 - seltsame effekte
verarbeiten switch(incomingByteCounter) { case 1: byte0 = UDR0; crcValue = crctable[nextCrcIndex]; break; case 2: byte1 = UDR0; crcValue = crctable[nextCrcIndex]; break; case 3: byte2 = UDR0; crcValue = crctable[nextCrcIndex]; break; case 4: byte3 = UDR0; crcValue = crctable[nextCrcIndex]; break; case 5: //Entscheidender
-
Thread
Datenübertragung von Außeneinheit einer Wetterstation
irgendein Standardprotokoll mit einer bestimmten Fehlererkennung ist. Zum Anhang: Die Temperatur betrug 17,5 °C. Gruß, Wolfgang
dass man von einem Bestimmten Null-Punt ausgeht und dazu eine binäre Differenz überträgt. Also: 0x17 0x01 für 17.5° ist ebenso möglich, wie 0x73 für folgende Rechnung: 0-Punkt ist -40°C, 7-Bit für 128° ab -40 aufwärz, 1 Bit für 0.5°C Es hilft auch zu wissen, welche Auflösung das Gerät hat, dann
-
Thread
Wie lange läuft eure Hardware so (Lebensdauer von Hardware)
Wolf17 schrieb im Beitrag #7863714: > WDs gibt es auch mit 5 Jahren Garantie. Wer nur mit 2 Jahren kauft, muss > nach 3 Jahren selber zahlen. Theoretisch ja. Argumentationsgrundlage von WD ist aber nicht
197 Not_In_Use 0x0032 100 100 000 Old_age Always - 0 199 SATA_CRC_Error_Count 0x000b 100 100 050 Pre-fail Always - 0 218 CRC_Error_Count 0x000b 100 100 050 Pre-fail Always - 0 231 SSD_Life_Left 0x0013
-
Thread
NODEMCU ESP32 Anemometer RS485 MAX485
ku8MBResponseTimedOut: tmpstr2 += "Response Timed Out"; break; case node->ku8MBInvalidCRC: tmpstr2 += "Invalid CRC"; break; default: tmpstr2 += "Unknown error: " + String(result); break; } Serial.println(tmpstr2); return false; }" Der Autor hat zwar andere
. Laut Anleitung vom Anemometer ist das folgendermaßen: Address Function Start Address DataLength CRC-L CRC_H 0x01 0x03 0x00 0x16 0x00 0x01 0x65 0xCE ich hatte das folgendermaßen eingebaut, ist aber Käse, weil Antworten angezeigt werden, egal ob sich das Anemometer dreht oder nicht
-
Thread
SPI mit AVR: Array-Zugriff in ISR funktioniert nicht
auch Timer-ISRs und ADC. Eine CRC zu verwenden bei Master und Slave ist unumgänglich (habe ich bei mir), man muss das 0-Byte des Slaves beim CRC aber verwerfen, da dies falsche Werte beinhalten kann (und wird).
tatsächlich technisch besser geeignet, aber die Frage stellt sich bei meinem Bastelprojekt gerade nicht. CRC ist übrigens bei mir auch vorgesehen.
-
Thread
Runtime Libs aus gcc-arm-none-eabi
mno-thumb-interwork -c -mcpu=cortex-m3 -mno-tpcs-frame -gdwarf-2 --function-sections -oo/stm32f10x_crc.o stm32f10x_crc.c arm-none-eabi-gcc -Wall -Os -funsigned-char -xc -mlittle-endian -mthumb -mno-thumb-interwork -c -mcpu=cortex-m3 -mno-tpcs-frame -gdwarf-2 --function-sections -oo/stm32f10x_spi.o stm32f10x_spi.c
cortex-m0plus.small-multiply generic-armv7-a cortex-a5 cortex-a7 cortex-a8 cortex-a9 cortex-a12 cortex-a15 cortex-a17 cortex-r4 cortex-r4f cortex-r5 cortex-r7 cortex-r8 cortex-m7 cortex-m4 cortex-m3 marvell-pj4 cortex-a15.cortex-a7 cortex-a17.cortex-a7 cortex-a32 cortex-a35 cortex-a53 cortex-a57 cortex-a72 cortex-a73
-
Thread
6bit CRC check on SENT slow channel Nachricht
J2716 überein. Nur weiß ich nicht wie ich auf die CRC von 13d komme. Vielen Dank
Der Vollständigkeit Halber: [c] static const unsigned char crc6_table[] = { 0, 25, 50, 43, 61, 36, 15, 22, 35, 58, 17, 8, 30, 7, 44, 53, 31, 6, 45, 52, 34, 59, 16, 9, 60, 37, 14, 23, 1, 24, 51, 42, 62, 39, 12, 21, 3, 26, 49, 40, 29, 4, 47, 54, 32
-
Thread
27C64 durch 27C256 ersetzen
Inforationstechniker schon mal verifiziert haben. ;-) Statt einer Prüfsumme (egal, ob Summierung oder XOR) also eine CRC. Je nach Größe der CRC ist dabei bekannt, wie viele einzelne falsche Bits noch sicher erkannt werden.
Auch eine CRC ist nicht 100% sicher.
-
Thread
Inline Assembler _crc_ccitt_update von util/crc16.h nach Assembler
"\n\t" "eor %A0,__tmp_reg__" : "=d" (__ret) : "r" (__data), "0" (__crc) : "r0" ); return __ret; }[/c] Ich hab sie jetzt so umgeschrieben: [avrasm].def wl = r0 .def crc0 = r16 .def crc1 = r17 eor crc0, XL mov wl, crc0 swap crc0 andi crc0, 0xF0 eor crc0, wl mov wl, crc1 mov crc1, crc0 swap crc0 andi crc0, 0x0F eor wl, crc0 lsr crc0 eor crc1, crc0 eor crc0, crc1 lsl crc0 lsl crc0 lsl crc0 eor crc0
-
Thread
PIC32MX350 läuft zu langsam
Konfiguration messe ich einen SPI-Clock von 3MHz (genau 2,85MHz). Nachtrag: Im DB findet sich unter 17.2.5 die Formel zur Berechnung von F_SCK (SPI-Clock): F_SCK = F_PB / (2 * (SPIxBRG + 1) ) ergibt bei 96MHz SPI1BRG = 16: 96 / (2 * (16 + 1) ) = 2,82....MHz Passt also so ziemlich zur Messung!
char dat2, char dat1, char dat0) { // create an ongoing XOR sum of all bytes sent char crc=0, start=84, stop=204; QF_INT_LOCK(); crc^=addr; crc^=dat5; crc^=dat4; crc^=dat3; crc^=dat2; crc^=dat1; crc^=dat0; SPI2BUF=start;
-
Thread
Problem: 16 Bit Variable über UART zu empfangen
Protokoll auch so definieren: - ASCII-Zahl ( Leerzeichen ASCII-Zahl )wiederholen Zeilenende Also "85 17 32 535\n" bedeutet dann "Befehl 85 mit den Parametern 17, 32 und 535". Dein Empfangscode schreibt also so lange Bytes in einen Puffer, bis ein "\n" kommt und übergibt die gesamte Zeile auf einmal an
so: Ohne Frage, wenn man die obige put16()-Funktion um beliebige Datenmengen plus zusätzlicher CRC erweitern will, wird man irgendwann auf dieselbe oder zumindest ähnliche Form kommen, die Du mit > <SOF><RcvAdr><SndAdr><Len><Cmnd><Data>...<CRC><EOF> skizziert hast. Dabei kann <Data> auch eine
-
Thread
Conways Game of Live zu langsam auf Z80
4B5C CB 7A [ 8] 254 bit 7, d 4B5E 28 04 [12] 255 jr Z,00109$ 4B60 16 17 [ 7] 257 ld d,#0x17 4B62 18 0D [12] 258 jr 00110$ 4B64 259 00109$: 4B64 3E 17 [ 7] 261 ld a,#0x17 4B66 92 [ 4] 262
vergleichen, dann wird eine Periodizität zwar verspätet erkannt, aber Es reicht wohl, wenn man einen CRC vom Bild speichert. Der CRC kann beim Aufbau des Bilds nebenbei berechnet werden.
-
Thread
Unterschied zwischen Code für Arduino und normalem Code
unsigned char mmc_read_sector (unsigned long addr,unsigned char *Buffer){ unsigned short a; // cmd17 zum lesen eines einzelnen blocks von der karte unsigned char cmd[] = {0x40+17,0x00,0x00,0x00,0x00,0xFF}; // CMD17 (read_single_block), response R1. // addressiertung bei mmc und sd (standart
#else a=512; do{ *Buffer++ = mmc_read_byte(); }while(--a); #endif //CRC-Byte auslesen mmc_read_byte();//CRC - Byte wird nicht ausgewertet mmc_read_byte();//CRC - Byte wird nicht ausgewertet MMC_Disable(); return TRUE; } [/c] Grüße
-
Thread
Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi
Um dem ganzen dynamisch beizukommen und ich mir ziemlich sicher bin, daß die 80 00 am Ende vor dem CRC konstant ist, schlage ich vor den CRC-test mit 23 Byte Datenlänge durchzuführen (wie jetzt schon vorhanden) _und_ wenn dieser _fehlschlägt_ die restlichen 2 Byte nachladen und _erneut_ CRC-check durchführen
=> Stretch durchgeführt und ich bekomme die folgende Fehlermeldung in Ccollgate.log 28.12.2017 17:05:47 INFO: Starting 'Ccollgate.run() 28.12.2017 17:05:47 CRITICAL: cht_if_worker();Error;couldn't open requested device:/dev/ttyAMA0 28.12.2017 17:05:47 CRITICAL: ccollgate().run();Error;could not
-
Thread
Tut gelesen und trotzdem Problem mit Strings im Flash
raus welche speicherbereiche wo stehen. Den Speicherverbrauch oben zeigt mir das makefile an. Die CRC Routine schliesse ich erstmal aus, da sie auf dem AT89C51ED2 ja läuft. Ich hänge sie aber mal mit an. Gruß aus Köln Frank
jetzt nochmal eine Verbindungssequenz mit Wireshark mitgeloggt. Beispiel: SYN - Seq_No 94 65 17 5E SYN_ACK - Seq_No 94 65 17 5F SYN_ACK = Seq_No + 1 ACK - Seq_No 94 65 1A 13 ACK = Seq_No + Datenlänge (692 Bytes) Also muss die Sequenznummer nach dem Wandeln auf Big Endian erhöht werden
-
Thread
CRC16 per hand berechnen!
siehe den Wikipedia-Artikel über CRC: http://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung
Es gibt Zusatzmechanismen um die CRC sicherer zu machen. Auf http://zorc.breitbandkatze.de/crc.html kannst Du versch. Mechanismen ausprobieren. Wenn es dann online mit der Berechnung klappt, dann solltest Du auch manuell auf das gleiche
-
Thread
STM32 SDIO Blöcke lesen
DMA_SxCR_MSIZE_1 /* word */ | DMA_SxCR_PSIZE_1 | DMA_SxCR_MINC | DMA_SxCR_PFCTRL | DMA_SxCR_EN; // Sende CMD17 - Einzelnen Block lesen SDIO->ARG = blockIndex; // Zu lesender Block SDIO->CMD = SDIO_CMD_CPSMEN | 17 | (1 << 6);[/c] Du musst dann noch den SDIO-Interrupt aktivieren (DMA-Interrupt wird nicht
CMD17 nur einen Block liest. Zum Lesen mehrerer Blocks brauchst du CMD18. Siehe SD Spezifikation.
-
Thread
Installation von CentiPad-Host-SW auf Debian
vmlinux: 919976 bytes ( 898 kBytes) target/initrd: 2793472 bytes (2728 kBytes) section 0x0001: crc32: 0xfa5494c7, 919986 bytes ( 898 kBytes) section 0x0002: crc32: 0x76fc731e, 2793482 bytes (2728 kBytes) section 0x0000: crc32: 0xffffffff, 10 bytes ( 0 kBytes) bootimage size: 3713482
vmlinux: 919944 bytes ( 898 kBytes) target/initrd: 2793472 bytes (2728 kBytes) section 0x0001: crc32: 0x90071689, 919954 bytes ( 898 kBytes) section 0x0002: crc32: 0xf8c039c7, 2793482 bytes (2728 kBytes) section 0x0000: crc32: 0xffffffff, 10 bytes ( 0 kBytes) bootimage size: 3713450
-
Thread
SHT75 - CRC Check: Ich finde den Fehler nicht
myMesswerte->TTicks,pChecksumme,0); // Hier erfolgt die Validierung des Ergebnisse mittels einer CRC Prüfung. if (Fehler == 0){ SwitchOnRelais(0); CRC = CalcCRC(MESSE_TEMP,CRC_IV); // Erstes Bit, der gesendete Befehl CRC = CalcCRC((uint8_t)(myMesswerte->TTicks
Linearisierung und Temperaturkompensation BerechneT_RF(myMesswerte); } [/c] Berechnung der CRC mittels der LUT: [c] uint8_t CalcCRC(uint8_t x, uint8_t crc){ return gCRC_LUT[x ^ crc]; // bitweises XOR } [/c] Dazugehörige LUT: [c] // Lookuptable zur byteweise Berechnung des CRC Wertes
-
Thread
pgm_read_word_far und Compiler-Warnung
0x9DE8,0x8DC9,0x7C26,0x6C07,0x5C64,0x4C45,0x3CA2,0x2C83,0x1CE0,0x0CC1, 0xEF1F,0xFF3E,0xCF5D,0xDF7C,0xAF9B,0xBFBA,0x8FD9,0x9FF8,0x6E17,0x7E36, 0x4E55,0x5E74,0x2E93,0x3EB2,0x0ED1,0x1EF0 } ; Tu8 CRC_Test (Tu32 u32_Start, Tu32 u32_End) { Tu16 uiCRC = 0; //Start-CRC = 0 Tu32 u32
Fehler = 0; for (u32_ByteInd = u32_Start; u32_ByteInd < u32_End-2; u32_ByteInd++) { uiCRC = pgm_read_word_far(Crctab + (uiCRC >> 8)) ^ ((uiCRC & 0x00ff) << 8) ^ pgm_read_byte_far(u32_ByteInd); } if ( ((uiCRC >> 8) != pgm_read_byte_far(u32_End-2)) || ((uiCRC & 0xFF) !=
-
Thread
Update Funktion für eigenes Projekt
Image geflasht. Über alles zusammen (gefundene Datei, Größe, CRC) wurde auf der Karte ein Logfile geschrieben.
internen Flash. Bei mir ergibt das folgendes Layout (kein AVR sondern MCS51) - Firmware 0x0000-0x17FD - Update 0x1800-0x27FD - Flasher 0x3000-0x37FF Die letzten beiden Bytes enthalten jeweils eine 16Bit CRC Prüfsume. Das eigentliche Update wird dann beim Start aufgerufen wenn sich die CRC
-
Thread
MP3 Decoder in C der wenig Ressourcen braucht.
17, 5, 17, 1, 18, 6, 17, 1, 20, 4, 19, 3, 17, 1, 18, 2, 17, 5, 18, 2, 18, 6, 19, 7, 19, 3, 19, 3, 17, 1, 17, 5, 20, 4, 19, 3, 18, 6, 20, 4, 20, 8, 20, 8, 18, 2, 20, 4, 19, 3, 20, 8, 17, 1, 19, 7, 19, 7, 19, 7, 20, 4, 18, 2, 20, 4, 17, 5, 18, 6, 18, 6, 20, 4, 17, 1, 18, 6, 20, 8, 19, 3, 19, 3, 17, 1, 20, 8, 17, 5, 17, 5, 17, 1, 20, 8, 18, 6, 20, 8, 20, 8, 17, 1, 18, 2, 17, 5, 18, 2, 19, 3, 19, 7, 19, 7, 19, 7, 17, 5, 20 (Auszug)
-
Thread
Zeitgleiches Versenden von Nachrichten mit dem AT90CAN
die dynamische Ermittlung von CRC und Bitstopfen basierend auf der effektiven Bitsequenz auf dem CAN-Bus anstatt auf Grundlage der jeweiligen Sendesequenzen dar. Damit entsteht eine Rückwärtskompatibilität, sodass Steuergeräte, die
die Telegramme zeitgleich sendest, ist spätestens aufgrund des unterschiedlichen Inhaltes bei der CRC Schluss. Dann siehst du nur Active-/Passive-Fehler.
-
Thread
Probleme mit RDS Synchronisation
Multiplizieren kling kompliziert, vereinfacht: Wenn in Deinem Bitstrom aus 26 Bits z.B. als 3.,4. und 17. Bit eine 1 auftaucht, mußt Du die Zeile 3, 4 und 17 von der H-Matrix miteinander XOR-verknüpfen. Es kommen also 26 Bit rein, und nach der XOR-Verknüpfung derjenigen Zeilen, die entsprechend Deinem
RDS_Standard.pdf Seite 63. @ruepel: Dankeschön! Genau da lag das Problem. Ich hatte immer probiert das CRC, also die letzten 10 Bits, mit der Matrix zu multiplizieren statt alle 26. Die 1er Bits des Datenwortes wurden korrekt einbezogen, aber eben auch das kompl. CRC. Kein Wunder, dass meine Ergebnisse
-
Thread
sd-Karte Elm Chan DMA
funktionieren oder ist der Ansatz völlig daneben? In der Funktion xmit_datablock wird nach 512bytes eine CRC abgefragt. Kann man das weglassen oder muss die dma auf 512bytes reduziert werden?
btr); /* Store trailing data to the buffer */ xchg_spi(0xFF); xchg_spi(0xFF); /* Discard CRC */ return 1; /* Function succeeded */ } [/c]
-
Thread
Neues Terminal-Programm für Windows
Bei Kommunikation über das MODBUS-Protokoll wird an eine Zeile immer eine zweistellige Checksumme (CRC-16) angehängt. Wenn ich jetzt eine Zeile eingebe und für die Checksumme nur noch auf eine Knopf drücken müsste, wäre cooL ;-) Meines Wissens sind CRC-8, CRC-16 und CRC-32 die gängisgsten Typen.
debuggen - Möglichkeit das/die Zeilenende-Zeichen frei einzustellen (z.B. 0x1B60) - Möglichkeit eine CRC berechnen zu lassen, z.B. von markierten Zeichen. Universell lässt sich das recht schön lösen wie es die Jungs von "Hex Workshop" gemacht haben: Man kann die CRC Breite (16/32), das Polynom, Startwert
-
Thread
AD7177 SPI Kommunikation durch Schleifringe
Der AD7177 hat ein recht cooles Feature, man kann mit einer CRC überprüfen, ob die Daten korrekt sind. Also kann man ihn nach jedem CRC-Fehler mit 64 1-Bits neu synchronisieren. Und mit dem Bit CRC_ERROR kann man überprüfen, ob er selber alles richtig verstanden
Peter D. schrieb im Beitrag #6626308: > Der AD7177 hat ein recht cooles Feature, man kann mit einer CRC > überprüfen, ob die Daten korrekt sind. Also kann man ihn nach jedem > CRC-Fehler mit 64 1-Bits neu synchronisieren. > Und mit dem Bit CRC_ERROR kann man überprüfen, ob er selber alles > richtig
-
Thread
Sinnhaftigkeit: i2c mit crc absichern ?
100Khz, die Länge über verdrillte Litze etwa 30cm (Ist das zu viel ?). Wieviel Sinn macht es, eine CRC-Prüfsume mit einzubauen ? Die Fehler treten nur manchmal auf.
Ja, CRC klingt gut.
-
Thread
CRC-16: Ergebnis der Summenbildung
kannst du es mit den beiden folgenden Formeln, die ohne Tabellenzugriffe arbeiten testen: [c] u16 CRC_XMODEM( u8* pData, u16 crc){ crc = crc ^ (u16)*pData++; for(u8 i = 0; i < 8 ; i++){ if(crc & 0x8000) crc = (crc << 1) ^ 0x1021; else crc <<= 1; } return crc; } [/c] oder [c] u16 CRC_CCITT( u8* pData, u16 crc){ crc = (u8)(crc >> 8) | (crc << 8); crc ^= *pData++ ^ (u8)(crc) >> 4; crc ^= (crc << 8) << 4; crc ^= ((crc & 0xff) << 4) << 1; return crc; } [/c]
-
Thread
c++ Code langsam
test_native_hash_larson_agner.exe C,Larson-Hash Seconds=0.63 MB/sec=721.6 test_native_hash_x17_agner.exe C,X17-Hash Seconds=0.62 MB/sec=733.2 test_native_n2.exe C,N^2 Seconds=0.41 MB/sec=1108.8 test_native_hash_crc32_agner.exe C,HW-Hash Seconds=0.26
test_native_hash_larson_agner.exe C,Larson-Hash Seconds=1.07 MB/sec=463.6 test_native_hash_x17_agner.exe C,X17-Hash Seconds=1.03 MB/sec=481.6 test_native_hash_simple_winobj.exe C,Simple_Hash Seconds=0.90 MB/sec=551.1 test_native_hash_crc32_agner.exe C,HW-Hash Seconds=0.87
-
Thread
Modbus RS485: Wie oft Stopp/Startbits ?
Byte2:Adress:8Bit]-HH-S-[Byte3:DATA:8Bit]-HH-S-[Byte4:CRC_LSB:8Bit]-HH-S-[Byte5:CRC_MSB:8Bit]-HH (CRC muss ja getauscht werden MSB<->LSB)
schrieb im Beitrag #4126314: > Also wirklich jedes Byte? Ja. > Wie verhält es sich mit dem 16-Bit-CRC? Das sind zwei 2 Bytes. Also: Siehe oben.
-
Thread
CRC Berechnung
000010 CRC = Rest = 0010 Wie kann ich das dezimal berechnen? 10101010100000 mod 10001 = 10912 (dezimal) mod 17 (dezimal) = 15 (dezimal) = 1111 1111 != CRC Vielen Dank
Bereich Informatik und Mathematik die einschlägige Fachliteratur – falls dich die Theorie hinter den CRC-Berechnungen interessiert.
-
Thread
wrapper in c (quellcode ist C++ und QT)
nach Funktionen welche dein Gerät initialisieren, Daten sendet (bestimmt ein eigenes Protokoll mit CRC), die Daten empfangen und CRC prüft, Verbindung mit Gerät trennt.
Funktionen welche > dein Gerät initialisieren, Daten sendet (bestimmt ein eigenes Protokoll > mit CRC), die Daten empfangen und CRC prüft, Verbindung mit Gerät > trennt. Genau das habe ich als erst versucht aber leider ich bekomme stets einen Unhandled exception. Ich habe in meinem C++ Quellencode
-
Thread
Checksumme decodieren
ist das dasselbe, wenn Du die Rechenformel umstellst: Bei Deinem Beispiel muss halt die Summe MINUS Crc gleich $MAGIC (hier 0) sein.
82 00 17 01 09 7B 00 CC 47 02 E2 00 00 47 B1 03 C5 00 00 00 00 77 00 0B 00 8A B7 91 82 00 63 32 00 8B 00 00 00 00 00 00 00 00 02 02 02 FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 91