-
Thread
SAMC20: DMAC->CRC != srec_cat −crc32-l-e
(crc32_val))/2]; crc32_val = tmp_data; tmp_data = NVM_MEMORY[(NVMCTRL_FLASH_SIZE-sizeof(crc32_val)+2)/2]; crc32_val |= ((uint32_t)tmp_data<<16) & 0xFFFF0000; DMAC->CRCCTRL.reg = DMAC_CRCCTRL_CRCSRC_IO
? > Welchen Wert erwartest du und welchen bekommst du? [code] .hex: 10FFF000 F...F 563EC74F 63 crc32_val: 0x4fc73e56 crc: 0x68f46c17 [/code] Ich erwarte die gleichen Werte; Positionsfehler könnte ich noch verstehen, aber Werte die keinerlei Ähnlichkeit haben nicht. > Die von dir eingelesene
-
Thread
Floppy FDD Diskette an AVR Mikrocontroller ATmega Beispiele Assembler
Motor-B on/off - Drehzahlmessung - Spur Step +/- - Spur NULL anfahren - Head-Umschaltung - alle 17 Pin-Zustände anzeigen (bei Motor off--> alle HIGH) - Data read (sowieso aktiv, wenn Motor on, Pegelwechsel an RDDATA) - Data Write (eine konstante Frequenz wird an WRDATA angelegt) MFM beherrscht
> Problem: Ich komme mit der CRC-Berechnung nicht klar, könnte jemand > bitte helfen? https://info-coach.fr/atari/hardware/FD-Hard.php Am Ende der Seite sind die Abschnitte, "Computing CRC in hardware" und "Computing CRC in
-
Thread
xmega128a1 EBI SDRAM
Crc1 = _crc_ccitt_update(Crc1 ,Val++);// CRC bilden } // *(uint16_t*) 0x7654 = 0xBEAF; // Fehler erzwingen for(i=SDRAM_ADDR; i < 0xffff - SDRAM_ADDR; i++) { Val = *(uint8_t*) i; // Speicher lesen Crc2 = _crc_ccitt_update(Crc2 ,Val); // CRC bilden } if (Crc1 == Crc2) { LED0_GREEN; } // passt? else { LED0_RED; } // Speicherfehler // if(Crc1 == Crc2) LED0_OFF;
-
Thread
Problem Codesegment
das mit den Wortadressen wusste ich nicht. Der vollständighalber die verarbeitende Routine \\\ CRC16: ;CRC-Berechnung mit Tabelle ;Polynom 0xA001 PUSH YL PUSH YH SBRC State, CRC_Init RJMP CalcCRC16 LDI CRC_Low, 0xFF LDI CRC_High, 0xFF SBR State, 1<<CRC_Init CalcCRC16: ;Index berechnen MOV TempLow, CRC_Low EOR TempLow, Received ;High-Byte ins Low-Byte schieben MOV CRC_Low, CRC_High LDI CRC_High, 0x00 LDI ZH, HIGH(CRC16_Table_Low
-
Thread
SOLIS Mini 1000 4G über Modbus auslesen
lcd.setCursor(10,0); lcd.print("Hz"); lcd.home(); delay(2500); } uint16_t calculateCRC(uint8_t *array, uint8_t num) { uint16_t _crc, _flag; _crc = 0xFFFF; for (uint8_t i = 0; i < num; i++) { _crc = _crc ^ array[i]; for (uint8_t j = 8; j; j--) { _flag = _crc & 0x0001; _crc >>= 1; if (_flag) _crc ^= 0xA001; } } return _crc; } [/c] [1] https://www.scss.tcd.ie/coghlan/Elios4you/RS485_MODBUS-Hybrid-BACoghlan-201811228-1854.pdf https://github.com
-
Thread
ebus protokoll mitschnitt bei einem Wolf Heizkessel
[pre]#F0#52#50#14#07#07#00#30#80#11#00#6A#ED#00#09#00#01#CD#2D#00#80#14#8C#00#D1#00 06.12.2008 17:38:53[/pre] Byte 7+8 --> Soll Vorlauftemperatur Mischerkreis Byte 17+18 --> Ist Temperatur Mischerkreis BSP: Soll Vorlauftemp: 48,5° Byte7 = #30 --> 48 Byte8 = #80 --> 128 --> 128/255
#30#80#11#00#6A#2F#00#09#00#01#E6#2D#00#80#14#8C#00#2E#00[/pre] In diesem Bsp. war die Raumtemp 17,7° Byte 9 = #11 --> 17 Die Kommastelle konnt ich noch nicht finden.
-
Thread
Braucht ein PHY einen MAC um Link aufzubauen?
> Das kratzt doch den PHY nicht. > Und wo hört der Funktionsumfang des PHY auf? Macht er auch CRC, > Paketlänge, ... oder hört es bem bloßen Signalstandardwandel auf? Ich kenn's nur bei PHYs, die PTP unterstuetzen, dass die irgendwas am Packerl und damit auch der CRC anfassen muessen. Anundpfirsich
OSI-1 > Fpgakuechle K. schrieb: >> Und wo hört der Funktionsumfang des PHY auf? Macht er auch CRC, >> Paketlänge, ... oder hört es bem bloßen Signalstandardwandel auf? > > Verstehe. In diesem Fall würde ich sagen er macht kein CRC Es ist ja nicht unbedingt CRC, kann ja auch SHA sein. Oder
-
Thread
die Warteschleife und MISRA
= 0, .syslib_version = (uint32_t) &SYSLIB_VERSION, .source_date_epoch = 0, .crc = 0, };[/c]
ich schon verstanden ... > C only. Nicht mehr: ist auch in C++ verfügbar (weiß grad nicht ob 17 oder 20)
-
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