-
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
-
Thread
Hilfe bei dsl20000
Beitrag #4674377: > So habe auch jetzt den Download probiert und komme auf 2,1Mib/s! 2,1 MiB/s sind 17,6 Mbit/s Nutzdatenrate. Das ist dicht genug dran. Etwas Protokoll kommt noch oben drauf
A. K. schrieb im Beitrag #4674533: > 2,1 MiB/s sind 17,6 Mbit/s Nutzdatenrate. Das ist dicht genug dran. > Etwas Protokoll kommt noch oben drauf Wie errechnet man das? Sorry bin leider kein Profi! Lg
-
Thread
1wire Slave Tester ATmega8 Assembler
Bis zu 64 Slaves können sich gleichzeitig am Bus befinden. Alle ROM-ID werden ermittelt und ein CRC Check durchgeführt. Bei einigen Temperatursensoren z.B. DS1820, DS18s20 und DS18s22, (Fam x10 x22 x28) kann das Scratchpad ausgelesen (inc. CRC) und die Temperatur angezeigt werden. Ein separater
Dabei wird der erforderliche Strom über einen µC-Pin zur Verfügung gestellt. Diverse Fehler z.B. CRC bei der ROM-ID werden automatisch angezeigt. Bernhard
-
Thread
CRC Prüfsumme für BMS
Wenn ich die Dokumentation richtig interpretiere, ist das Verfahren zur Berechnung der Prüfsumme CRC 16. Ich habe also verschiedene Rechner im Netz bemüht, komme aber immer zu einem anderen Ergebnis als in den Beispielen. Hier ist z.B. 06 04 00 17 00 01 80 79 als Befehel genannt. Die letzten beiden
Probiere mal: - https://www.lddgo.net/en/encrypt/crc - 060400170001 - Content Type: Hex - Algorithm: CRC-16-MODBUS - Polynomial Formula(HEX): 8005 - Initial Value(HEX): FFFF -=>Check Result(HEX): 7980 Das mit dem "Polynomial 0x8005" steht auch
-
Thread
WLAN Ubuntu 16.04 akzeptiert Passwort nicht
sub 17aa:4035 [ 17.821530] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 1 dfs 0 testmode 0 [ 17.822002] ath10k_pci 0000:01:00.0: firmware ver WLAN.TF.1.0-00267-1 api 5 features ignore-otp crc32 79cea2c7 [ 17.938617] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id N/A crc32 93da0176 [ 19.720068] ath10k_pci 0000:01:00.0: htt-ver 3.1 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto
-
Thread
RFM12 an XMEGA
for( i = 0 ; i<RFM12_Data[0] + 1 ; i++ ) { crc_chk = crcUpdate( crc_chk, RFM12_Data[ i ] ); } crc = RFM12_Data[ i++ ]; crc |= RFM12_Data[ i ] << 8; RFM12_status.New = 0; /* if( crc != crc_chk ) { return( 253 );
crc = (crc<<1) ^ 0x1021; } else { crc = crc << 1; } tmp = tmp << 1; } return crc; } //------------------------------------------------------------------------
-
Thread
Modbus RTU Slave fuer AVR
void modbus_processSlaveFrame(uint8_t *query, int query_length) { uint8_t cnt = 0; if (check_crc16(query, query_length) == query_length) { modbus_slave_manage(query, query_length); } else { for (cnt = 0; cnt < UART_RX_BUFFER_SIZE; cnt++) { query[cnt] = 0; } } } [/c] sehen ob der CRC Check durchgeht. Ich hatte schon modpoll Programme die einen eigenen CRC Key verwendeten. Wenn der CRC check durchgeht, im selben File in der Funktion modbus_slave_manage() [c] switch (sft.function
-
Thread
Trennungsbedingungen im VzK
der Prozessplaner keine Lust oder Ahnung von seinem Job hat, muß ich laufend mit zigtausend FEC- und CRC Fehlern, ettlichen LoS und FoS im Modem die Verbindung ins Netz versauen lassen? Glaube ich aber eher nicht > wofür gibt es Vorgaben über Trennungsbedingungen? In dem Fall nur Schlafmützen und Loser
selbst, wenn du mit 17 MBit/s synchron bist, es ein Stück Technik im Netz der Telekom gibt, was dich trotzdem auf z.B. 6 MBit/s runterbremsen kann. Das der Router sich selbstständig (neu-)verbindet ist schon klar, aber man
-
Thread
OneWire Problem DS2413
"); for( i = 0; i < 8; i++) { Serial.print(addr[i], HEX); Serial.print(" "); } // crc check if ( OneWire::crc8( addr, 7) != addr[7]) { Serial.print("CRC is not valid!\n"); return; } // check if DS2413 if ( addr[0] != 0x3A) { Serial.print("Device is not
stimmt, danke. und dann sollte es funktionieren? ich begreife nicht ganz warum im datenblatt seite 17 (PIO ACCESS WRITE EXAMPLE) so viele schritte gemacht werden. schreiben, invertiert schreiben,2 mal lesen, wieder schreiben... ? versteht das jemand oder ist das ein etwas spezielles beispiel ?
-
Thread
Abtastzeitpunkt bei CAN verschieben (Phasesegm1, Phasesegm2 und SJW)?
DLC 0x1 und einen die Daten 0x3 also 1011001001, 1, 10 aber raus kommt 0x2C9, DLC 0x16 oder 0x17 und Wert 0 1011001001, 10110 oder 10111 und Daten 0
irgendein seltsames Verhalten weil das Bit in der Analyzer Software nicht maskiert wurde. (Angabe von .17 (dezimal?) anstelle von .1 Daten Byte in der Gui und bringt auch irgendwie die Datenausgabe durcheinander)
-
Thread
RFM70-Funkmodul funkt nicht!
const unsigned int Bank0_Reg0_29[18]= { // address data (0x20|0x00), 0x72, //Disable CRC ,CRC=1byte, POWER UP, TX (0x20|0x01), 0x01, //Enable auto acknowledgement data pipe0 (0x20|0x02), 0x01, //Enable RX Addresses pipe0 (0x20|0x03), 0x03, //RX/TX address field width
commands uint8_t bank0Init[][2]= { // address data { (0x20|0x00), 0x0F }, //Disable CRC ,CRC=1byte, POWER UP, TX { (0x20|0x01), 0x3F }, //Enable auto acknowledgement data pipe0 { (0x20|0x02), 0x3F }, //Enable RX Addresses pipe0 { (0x20|0x03), 0x03 }, //RX/TX address
-
Thread
Serielle Kommunikation mit 7x7 LED Matrix
Nutzendaten <rgbN> binär gesendet. Die <Kopfdaten> könnten einfach eine fortlaufende Nunmmer sein; die <crc-16> ist eine binäre 16 Bit CRC Checksumme. <Kopfdaten><rgbN>..<crc-16>
16MHz/16/8 ==> 125,000 kBit/s 16MHz/16/9 ==> 111,111 kBit/s Fall b) mit Vorteiler 1:8 16MHz/8/17 ==> 117,647 kBit/s *relativer Fehler* error = (1 - 117,647 kBit/s /115,200 kBit/s) *100 error = +2,12%
-
Thread
SPI Bustreiber 74HC125
MISO) über das Protokoll gesteuert aktiviert, ist > es kein Standard-SPI. So arbeiten z.B. MCP23S17 von Microchip. Die haben drei Adresselinien wie auch MCP23017 für I2C. Deshalb können auf einer ~SS - Linie bis acht MCP23S17 sitzen. MCP23S17 brauchen immer 3 Bytes: zuerst wird Adresse übertragen, dann Registeradresse innerhalb von MCP23S17, und danach wird Byte geschrieben oder gelesen. Microchip nennt das auch "SPI".
-
Thread
MAF 8031AH-2 12P - Wie macht der die Prüfziffer
Könnte ne CRC sein, schau mal auf die Maxim seite, die haben da einige beschrieben für den 1-Wire Bus. Falls ne CRC nicht gleich paßt, die kann auch invertiert, gespiegelt, mit 0x00(00) oder 0xFF(FF) startend
als ich dachte. Habs schon fertig in VB. [code]püfziffer = 127 prüfziffer = prüfziffer - 116 Xor 17 Xor 65 Xor 75 Xor 80 Xor 73 Xor 90 Xor 84 Xor 79 Xor 32 Xor 78 Xor 65 Xor 70 Xor 69 Xor 83 Xor 83 Xor 13 Label1.Caption = prüfziffer[/code] DANKE an RENE