-
Thread
CRC Einheit im STM32 -> CRC32 lässt sich nicht bestätigten
Ausgangsdaten Kein Final XOR am Ende Ich habe für den Wert 0x1F7463AB(zufällig gewählt) die CRC32 wie folgt berechnen lassen im STM32: [code] RCC->AHBENR |= RCC_AHBENR_CRCEN; //Enable CRC CRC->CR |= CRC_CR_RESET; //Reset CRC to 0xFFFFFFFF CRC->DR = 0x1F7463AB; //Input
1; } return crc; } uint32_t calculate_stm_crc(uint32_t *data, size_t len) { uint32_t crc = ~0U; while (len--) { crc = do_crc(crc, *data++); } return crc; } [/c] Einfach die Funktion calculate_stm_crc
-
Thread
Strings kopieren in "Arduinoumgebung" mit strncpy
komma[1]] = '\0'; // # CRC-16/XMODEM => CRC berechnen crc_1 = crc16((uint8_t *) Daten_1, strlen(Daten_1), 0x1021, 0, 0, false, false); // # Datenarray CRC-Checksumme extrahieren
= strtol(Daten_1, NULL, 16); // # Checksummenvergleich aus Datenarray und berechnenten CRC if(test == crc_1) { Serial.print("crc Ver-Gleich == gleich"); } else { Serial.println("crc Ver-Gleich == ungleich"); } // # Komma Stellen
-
Thread
Keil C51 und Bitfelder in einer Struktur (8051)
unsigned year : 8; unsigned month : 4; unsigned crc7 : 7; unsigned : 1; unsigned crc16 : 16; unsigned : 0; } T_cid; [/c] In einer Funktion möchte
Ungereimtheiten drin. Erstens besteht das CID aus 128 Bit im SPI und 136 Bit im SD Modus, was genau 16/17 Bytes entsprechen. Du hast aber eine 18 Byte lange Folge für deine CID Daten gepostet und auch bisher nicht erwähnt, in welchem Modus du die Karte ansprichst. Dann ist in deinem Struct am Ende ein crc16
-
Thread
Problem mit Micro-SD-Karte
Null 1654384 (16.54ms) MISO:MOSI 0xFF ÿ : 0x01 ; Dummy CRC 1654677 (16.55ms) MISO:MOSI 0xFF ÿ : 0xFF ÿ ; ... 1654970 (16.55ms) MISO:MOSI 0x00 : 0xFF ÿ ; ReturnCode 0 = OK 1655263 (16.55ms) MISO:MOSI 0xFF ÿ : 0xFF ÿ ; warten ... ... 1719550 (17.20ms
rcvr_spi_multi(buff, btr); /* Receive the data block into buffer */ xchg_spi(0xFF); /* Discard CRC */ xchg_spi(0xFF); return 1; /* Return with success */ } 29d2: df 91 pop r29 29d4: cf 91 pop r28 29d6: 1f 91 pop r17 29d8: 0f 91
-
Thread
CAN CRC mit VHDL berechnen und testen
sollte! begin crc_next_v := crc_next; crc_tmp_v := crc_tmp; crc_xhdl1_v := crc_xhdl1; crc_next_v := data XOR crc_xhdl1_v(14) ; crc_tmp_v := crc_xhdl1_v(13 DOWNTO 0) & '0'; if (crc_next_v = '1') then crc_xhdl1_v := crc_tmp_v xor "100010110011001"; else crc_xhdl1_v := crc_tmp_v ; end if; crc_next <= crc_next_v; crc_tmp <= crc_tmp_v; crc_xhdl1 <= crc_xhdl1
-
Bild
Technische Zeichnung eines Rotors und Schiebers
Rotor drawn at fully counter-clockwise position. M= mark for position of slider. d1 d2 a c b 14±0,1 7,75 ±0,1 d1 a b c d2 designation of terminals
-
Thread
Verschlüsselungsalgo und AVR schaft er das?
Primzahl] q=53 [zweite Primzahl] n=p*q=3233 Modulus [Teil des öffentlichen Schlüssels] e=17 [öffentlicher Exponent (Teil des öffentlichen Schlüssels)] d=2753 [geheimer Exponent (der geheime private Schlüssel)] c=m^17 mod 3233 [Verschlüsselungsvorschrift] d=c^2753 mod 3233
>>Ergebnis 1: >>c=123^17 mod 3233= >>337587917446653715596592958817679803 mod 3233 = 855 dass das so nicht gehen wird liegt wohl an dem ergebnis von 123^17.. ich kenn keinen Datentyp der so eine Zahl fassen könnte
-
Thread
Brauche Hilfe bei SHT11 CRC Berechnung
Check_SHT_CRC(dim Commandbyte,Databyte1,Databyte2,CRC_FromSensor As Byte) As Boolean Dim CRC_calculation As Byte CRC_calculation = 0 CRC_calculation = CRC_Table[Commandbyte] CRC_calculation = CRC_calculation Xor Databyte1 CRC_calculation = CRC_Table[CRC_calculation] CRC_calculation = CRC_calculation Xor Databyte2 CRC_calculation = CRC_Table[CRC_calculation] CRC_calculation
-
Thread
SD Karte mit Ulrich Radigs Software zeigt keine Dateien
der Rest gehen, weil ja die Kommunikation soweit schon klappt. Was bekommst du denn auf ein cmd17 nach der Initialisierung zurück? Quasi nach so einem Kommando: [c] unsigned char cmd[] = {0x40+17,0x00,0x00,0x00,0x00,0xFF}; [/c] Da sollte dann auch irgendwann der Sektor 0 zurück kommen...
>In der AVR Library hier aus dem Forum hat es Fehler drinn... >Es sollte nicht heissen >//CRC-Byte schreiben > mmc_write_byte(0xFF); //Schreibt Dummy CRC > mmc_write_byte(0xFF); //CRC Code wird nicht benutzt > //Fehler beim schreiben? (Data Response XXX00101 = OK) > if((mmc_read_byte
-
Thread
Sensirion SHT11 Code
höhere Auflösung umschalte stimmt das Ergebnis in der Temperatur, ansonsten habe ich statt 25Grad nur 17Grad auf dem Display (wir haben hier gerad rund 25Grad). Auf die Luftfeuchte hat es scheinbar keinen feststellbaren Einfluss. Bitte um Rücknmeldung. Gruß, Thorsten
sbus_read(ACK,0); // read the first byte (MSB) lsb = sbus_read(ACK,0); // read the second byte (LSB) crc = sbus_read(noACK,1); // read checksum // 4 status register bits go into sent crc, but they are 0 if sensor is as we want it if(crc!=lut[lut[lut[command]^msb]^lsb]) return -1; // crc check fails
-
Thread
Wer kann meinen Code (Bitpopelei) vereinfachen?
Folgender Code (CRC32) basiert auf dem entsprechenden Wikipedia-Artikel und nun möchte ihn für den AVR möglichst platzsparend vereinfachen. Es soll einfach eine CRC32 über eine 32-Bit-Zahl berechnet werden. [c]uint32_t crc32(uint32_t x) { static const uint32_t CRC32MASK = 0x04C11DB7; uint32_t c = 0; for (uint8_t i = 0; i < 32; i++) { if ((c >> 31) ^ (x & 1)) c = (c << 1) ^ CRC32MASK; else c <<= 1;
-
Thread
Wert in AVR Register laden: optimalen Code generieren?
PR21683 setzt auch das aktuelle ABI voraus. crt*.o per Symbol zu bespaßen à la [avrasm].byte __0reg17, 0x24 ; CLR __0reg17 / 17[/avrasm] setzt voraus, dass man weiß, welches ABI aktiv ist, d.h. compiler definiert ein Symbol, das denn vom Default-Linkerskript definiert wird: [c] __0reg = DEFINED(__0reg) ? __0reg : 1; __0reg17 = DEFINED(__0reg17) ? __0reg17 : 17 * __0reg; [/c] Ich wüsste jetzt niemand, der *das* Fass aufmachen möchte.
-
Thread
lcd_write Fehlersuche
owx_empfangen( uint8_t *buff /* Pointer to data buffer */ ){ uint8_t len,adr=0; uint8_t crc=0; while(owx_signal);//Anfangssynchronisierung durch Master dly_short; //adr *buff = owx_rx_byte(); adr=*buff; crc=crc+1+*buff; *buff++; //len *buff = owx_rx_byte(); len=*buff-2; crc=crc+1+*buff; *buff++; //4xheader + payload do{ *buff = owx_rx_byte(); crc=crc+1+*buff; *buff++; } while (--len); //crc *buff = owx_rx_byte(); return crc; [/c]
-
Thread
CAN-Bus Fehlerwahrscheinlichkeit
Stelle. Frage: * Ist es wahrscheinlich daß alle ~70 Telegramme eins so verfälscht wird daß die CRC dennoch passt und der CAN Controller den Empfang eines gültigen Telegramms meldet? (Bonusfrage: wie wahrscheinlich ist das überhaupt bei gegebener CRC-Länge, kann man das quantifizieren, mir mangelt
Letzteres halte ich für wahrscheinlicher. CRC-Fehler erkennt der CAN-Controller und setzt dann ggf. ein Error Flag. Das musst du natürlich auswerten. Daher mein Verdacht Software. Zur Mathematik: Der CRC-Code ist 15 Bit lang. Fehler bleiben
-
Thread
Stackprobleme Mega2560
u2_crc_c ^= color_t.blue; while (!(UCSR2A & (1<<UDRE2))) {} UDR2 = color_t.white; u2_crc_c ^= color_t.white; while (!(UCSR2A & (1<<UDRE2))) {} UDR2 = color_b.red;
u2_crc_c ^= color_b.blue; while (!(UCSR2A & (1<<UDRE2))) {} UDR2 = color_b.white; u2_crc_c ^= color_b.white; while (!(UCSR2A & (1<<UDRE2))) {} UDR2 = (BYTE) (symbol
-
Thread
Code unleserlich schreiben um Zeilen zu sparen.
und muss keine externen Tools anwerfen. Leider gibt's ja Protokolle die so vermurkste Nicht-Standard-CRC's nutzen die man nicht mit den CRC-Hardwareeinheiten von Mikrocontrollern erzeugen kann, wie z.B. beim LTC6804.
/projects/tdm-gcc/files/latest/download Gibt es eine C++17 Windows Version und kann man sich eine Windows kompatible C++17 installieren?
-
Thread
Temepratur messen mit DS1820 und ATMEGA8
Adresse meines DS1820 die ich vorher ermittelt habe Dsid(1) = &H10 : Dsid(2) = &H68 : Dsid(3) = &H17 : Dsid(4) = &H25 : Dsid(5) = &H01 : Dsid(6) = &H08 : Dsid(7) = &H00 : Dsid(8) = &H98 Dim Sc(9) As Byte Dim T As Integer Dim T1 As Integer Dim I As Byte Cls Cursor Off Locate 1 , 1 : Lcd "Mein
Du kriegst vom Ds1820 8 Bytes zurück. Wenn diese 8 Bytes einen CRC Fehler haben, dann gibst du bisher auch schon diese 8 Bytes aus. So. Jetzt haben deine Daten keinen CRC Fehler. Nach menschl. Ermessen sollten sie daher richtig sein. Aber ist das tatsächlich so?
-
Thread
ENC28J60 Schritt für Schritt ins Netzwerk einbinden.
Über den gesamten Ethernetframe wird ja eine CRC-Checksumme gebildet. Solange diese OK ist, kann man doch auf die Überprüfung der IP und TCP/UTP/ICMP Checksummen verzichten. Die wären doch nur interesant, wenn man einen Frame mit fehlerhaften CRC verarbeiten möchte um den Fehler einzugrenzen. Die Warscheilichkeit, dass ein Frame mit korrektem CRC trotzdem fehlerhaft ist geht doch gegen 0. Oder !?!
-
Thread
Bluetooth LE BLE Daten von Powermeter entschlüsseln
aber sein, dass sich dazwischen plötzlich ein anderer Wert mogelt. Z.B. 187 18 20 192 54 193 1 17 17 215 4 55 216 137 238 bzw. bb 12 14 c0 36 c1 1 11 d7 4 37 d8 89 ee Nun denkt meine Software natürlich, dass alles zwischen c1 und d8 die Leistung wäre und verwendet folglich 111d7437 für die Leistung
die Kollegen da ein bestehendes, serielles Protokoll auf BLE umgebogen haben. BLE hat eine 24 bit CRC in der Übertragung. Wenn Daten bei Dir ankommen, dann sind die in der Regel korrekt übertragen worden. Eine zusätzlich CRC in den Nutzdaten ist eigentlich überflüssig. Ich würde die einfach ignorieren
-
Thread
RFM70 Wahnsinn..
define TX_SPL 0x00 // parameter for configTxPipe(..): enable static payload for PTX #define CRC0 0x00 // parameter for configCRC(crc): disable CRC #define CRC1 0x01 // parameter for configCRC(crc): 1 byte CRC #define CRC2 0x02 // parameter for configCRC(crc): 2 byte CRC
define TX_SPL 0x00 // parameter for configTxPipe(..): enable static payload for PTX #define CRC0 0x00 // parameter for configCRC(crc): disable CRC #define CRC1 0x01 // parameter for configCRC(crc): 1 byte CRC #define CRC2 0x02 // parameter for configCRC(crc): 2 byte CRC
-
Thread
Das A und O des UART- Puffers
sendet 0xf0 X RX 111101111011110000101111000010111100001111111 -- empfängt 0xf7 0x17, 0x17 und 0x1f 11110111 00010111 00010111 00011111 --> vier Bytes korrekt empfangen, aber Daten korrupt [/pre] > Kannst Du nicht, wenn Du zwischen zwei Streams hin und herschaltest
XXXX <-- Umschalten RX 111101111111110000101111000010111100001111111 -- empfängt 0x17, 0x17 und 0x1f 00010111 00010111 00011111 --> drei Bytes korrekt empfangen, aber Daten korrupt [/pre] Jede andere Kombination ist problemlos vorstellbar...
-
Thread
CRC: Unterschiede in Artikel auf mikrocontroller.net & Wikipedia
%C3%BCfung 2) http://www.mikrocontroller.net/articles/CRC Beispiel: In 2) steht einmal "Zum Beispiel bedeutet CRC16, dass das Generator-Polynom vom Grad 16 ist, sprich es hat 17 Bit." und direkt im nächsten Abschnitt "...wobei N die Anzahl Bits des Generatorpolynoms
Ralf schrieb im Beitrag #3772637: > Beispiel: > In 2) steht einmal "Zum Beispiel bedeutet CRC16, dass das > Generator-Polynom vom Grad 16 ist, sprich es hat 17 Bit." und direkt im > nächsten Abschnitt "...wobei N die Anzahl Bits des Generatorpolynoms > ist. (CRC16 -> 16 Bits)", also erst
-
Thread
CRC-16-Berechnung mit Lookup-Tabelle: zwei Varianten, beide gültig?
i++) { *crc = ((*crc) << 8) ^ crctab[((*crc) >> 8) ^ buf[i]]; } }[/c] Variante B: [c]void crcAlgB(char* buf, unsigned short* crc) { unsigned short i; for(i = 0; i < strlen(buf); i++) {
0x2C83, 0x1CE0, 0x0CC1, 0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8, 0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0 };[/c] Algorithmus A erzeugt einen Wert gemäß CRC-16/XMODEM, soweit OK. Was aber Algorithmus B erzeugt, kann ich einfach nicht sinnvoll beurteilen
-
Thread
Prüfsummenverfahren gesucht.
Nimm einfach die [c] #include <util/crc16.h> [/c]
Blick in die <util/crc16.h> verrät, _crc_ccitt_update() braucht 17 Zyklen. Allerdings ist der Baudratenfehler bei 3,6MHz schon 2,4%. Diee AVRs unterhalten sich daher mit 112,5kBaud und nicht mit 115,2kBaud. Mitlauschen
-
Thread
Jetzt noch eine FritzBox 7390 kaufen?
Bin noch auf Fehlersuche... Wie hoch ist die Leitungsdämpfung? Hast Du nicht behebbare Fehler CRC? LG old.
Ein Dämpfungslied könnte ich mir dennoch mal schnell löten und testen. Allerdings habe ich keine CRC Fehler wie in deinem Fall.
-
Thread
Ist die Festplatte gesund?
2721 194 Temperature_Celsius 0x0022 022 045 000 Old_age Always - 22 (0 17 0 0 0) 195 Hardware_ECC_Recovered 0x001a 009 008 000 Old_age Always - 51973470 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198
muss man beobachten. Gärtner schrieb im Beitrag #5998201: > 188 Command_Timeout 3 > 199 UDMA_CRC_Error_Count 14 Anderes Kabel einsetzen!
-
Thread
Welches CRC16 Verfahren verwenden SD Karten?
be protected is 40 for commands and responses (n = 39), and 120 for the CSD and CID (n = 119). CRC7 Examples The CRC section of the command/response is bolded. CMD0 (Argument=0) --> 01 000000 00000000000000000000000000000000 "1001010" 1 CMD17 (Argument=0) --> 01 010001 00000000000000000000000000000000 "0101010" 1 Response of CMD17 --> 00 010001 00000000000000000000100100000000 "0110011" 1 " "CRC16 In the case of one DAT line usage, the CRC16 is used for payload protection in block transfer mode. The CRC check sum is a 16-bit
-
Thread
CRC-8: Problem mit Berechnen
Hi Also ich weiß, dass es hier viele Threads gibt, die sich mit dem Thema CRC-8 befassen aber ich hab leider nix gefunden, was mich wirklich weiterbringt. Folgendes Problem: Hier wird für Hexadezimale Messages eine CRC 8 Checksumme erstellt und ich soll schaun ob die richtig
Guck mal bei Maxim, die haben für einen Ihrer Temperatursensoren eine Application-Note, in der sie CRC verwenden. Nach dieser habe ich meine eigenen CRC-Funktionen geschrieben. Dann kannst du deinen Quellcode mit deren Code vergleichen. Gruß Ralf
-
Thread
Signalproblem bei langem Kabel
bisher noch keine entsprechenden gefunden. Falls jemand einen kennt immer her damit ;) Das mit dem CRC verstehe ich nicht so ganz, CRC-Codes werden bei einem Filetransfer automatisch vom Betriebssystem geprüft afaik, da kann ich nichts ein- und ausschalten ;)
biderektionalen Datenleitungen. Es gibt aber unidirektionale in beiden Richtungen. > Das mit dem CRC verstehe ich nicht so ganz, CRC-Codes werden bei einem SD werden ja an Microcontroller normalerweise im SPI-Mode angesprochen und da ist per default CRC ausgeschaltet. Das solltest du einschalten
-
Thread
sd-card SDIO Initialisierung
crc =0; if(s == 2) j = 17; for(k=0; k<j; k++) { c = 0; if(k > 0) //for crc culcar b = response_buffer[k-1]; for(i=0; i<8; i++)
SD_TEST_CMD) c |= 0x01; if(k > 0) { crc <<= 1; if((crc ^ b) & 0x80) crc ^= 0x09; b <<= 1; crc &= 0x7f;
-
Thread
Checksumme im Funkprotokoll von Thermo_Hygro-Sensor
und auch das Nibble an ???? stimmt überein. Aber die Prüfsumme hat sich ordentlich verändert... eine CRC kann es damit schon fast nicht mehr sein. Jedenfalls keine CRC16, denn die hätte auf das gleiche Ergebnis kommen müssen. Es macht keinen Sinn bei einem Funkprotokoll eine fortlaufende CRC zu verwenden
crcxor : 0xa766 refin : 1 refout : 1 Results: crc bit by bit : 0x50cc crc bit by bit fast : 0x50cc CU Dirk
-
Thread
Beispielprogramm für RFM12 433MHz Funk-Module
byteweise lesen über interrupt mit 19.200 baud mit einiger logik in der interruptroutine (STX/ETX+CRC8)
16 ldi r16, (1<<SPE)|(1<<MSTR)|(1<<SPR0) out SPCR,r16 RF12_CMD: ;sendet befehl in r16/r17 und empfängt Daten wieder in r16/17 cbi PORT_SPI,SEL ;Chip Select //*** out SPDR,r17 ;Erstes Byte senden t1: sbis SPSR,SPIF ;warten bis Transfer zu Ende rjmp t1 in r17,SPDR
-
Thread
Arduino Uno R4: Besonderheiten und Abhilfen
Datei befindet: [code] void add_crc(unsigned long crc){ unsigned long check = 0x10; // Mask for (byte i = 0; i < 7; i++){ // Check all nibbles if(crc < check){Serial.print(F("0"));}
Add leading 0 check = check << 4;} // Next nibble Serial.print(crc,HEX);} // Add crc } [/code] Viele Grüße Kai
-
Thread
CRC16-CCITT Polynom Verständnisproblem
bit wäre von 0 bis 15 und damit würde alles reinpassen 1 = x^0 x^0, ..., x^16 macht insgesamt 17.
PPS: Ich habe nun das ISO file gefunden - durch Zufall im Netz - und das sagt mir folgendes: The CRC polynomial (0x1021) is x16+x12+x1 The implemented version of the CRC check has the following characteristics reverse CRC CCITT 0x8048 data stream has LSB first the CRC shift register is initialied
-
Thread
Wahrscheinlichkeit für Bitmuster?
>Syncsequenz in den Nutzdaten auftaucht. >Solche "Lösungen" sind Käse... Nö, nicht Käse. Die CRC gibt nur die Erkenntnis das die vorher empfangenen Daten mit der Fehlerwahrscheinlichkeit der CRC eben korrekte Daten sind. Die CRC hat mit dem Resync, der Synchronisation oder dem Magiccode garnichts
fehlen, außer der Sender und Empfänger bewegen sich auseinander. Außerdem implementiert man eine CRC auch nicht in der Bit Ebene. Mir ist schon klar das eine CRC nicht beim Synchronisieren hilft. Aber wenn mal ein Frame kaputt ist sollte man es lieber wegschmeißen.
-
Thread
SD MMC an Atmega8
=(C_SIZE+1)*MULT memorycapacity=BLOCKNR*BLOCK_LEN Mich wundert nur eine Tatsache. Ich habe die CRC Prüfung eingeschalten. Bei der Karte mit einer READ_BLOCK_LEN > 512 Bytes und einem CMD17 bekomme ich keinen CRC fehler wenn ich nur 512 Bytes nach dem OxFE lese. Die CRC Prüfung funktioniert aber einwandfrei
5. 140 192 -> CRC Bytes 5. 255 255 255 255 -> Lesevorgang beendet. Karte gibt nur mehr 512 aus.
-
Thread
CRC Verständnisfrage
gefordert ist. somit sind nur die restlichen bits wirklich zu berechnen. hat zur folge, das bei 17 bit Polinom wie beim CRC 16 ( x16 + ... ) der rest immer 16 bit gross ist. und der aufbau des Polinoms ist nicht egal. da haben sich einige schlaue mathematiker den keks gehörig verbogen um zu beweisen
welches von beiden ist das Richtige? Was meint Ihr? [avrasm] ; Routine zum generieren einer CRC8- Tabelle ;--------------------------------------------- CRC_Build_main: ldi temp3, CRC_Init // mit CRC_Init laden = $FF, Remainder clr temp1 // CRC- Prüfbyte löschen
-
Thread
Verständnis zur Verwendung einer CRC Tabelle
[CRC]^Data. MFG Falk
Also im Prinzip so hier. crc_check: push zh push zl eor daten,crc_byte add zl,daten brcc crc_check1 ldi temp,1 add zh,temp crc_check1: lpm mov crc_byte,r0 pop zl pop zh ldi temp,1<<crc
-
Thread
RFM69 - Beispiel für Initialisierung gesucht
alles, werde den RESET aber sicherheitshalber nicht mehr floaten lassen. Im Moment macht mir die CRC-Funktion Kummer. Ohne CRC läuft es gut, aber mit CRC auf beiden Seiten aktiviert kommt nichts sinnvolles mehr an bzw. CrcOK-Pin wird nicht gesetzt. Wenn man dennoch den FIFO ausliest bekomme ich immer
Um CrcOK habe ich mich nie gekümmert, ich habe die Funktion CrcAutoClear (d.h. Bit 3 im Register 0x37 = 0, Bit 4 = 1, damit Crc überhaupt aktiv ist) aktiviert und frage das Bit PayloadReady ab. Das wird nur
-
Thread
Modbus RS485 minütlich-stündliche Fehler
Der RPi gibt nur raus: Oct 16 17:42:10 openwb Node-RED[362]: 16 Oct 17:42:10 - [warn] [modbus-getter:1000 - 1003] Modbus Failure On State sending Get More About It By Logging Oct 16 17:42:10 openwb Node-RED[362]: 16 Oct 17:42:10 -
Christian B. schrieb im Beitrag #7517370: > Oct 16 17:42:10 openwb Node-RED[362]: 16 Oct 17:42:10 - [error] > [modbus-getter:1000 - 1003] Error: Timed out > Oct 16 17:48:30 openwb Node-RED[362]: 16 Oct 17:48:30 - [warn] Die Frau hat um 17:42 und 17
-
Thread
Branching ARM
(Relocatable Segment) erzeugen. Hier ein Beispiel für Keil ist aber 8051 Assembler: NAME CRC8_Routines PUBLIC CRC8 CRC8_segment SEGMENT CODE RSEG CRC8_segment ;******************************** ;****** CRC8 Routine Start ****** ;******************************** CRC8: push dph ; Save DPH push dpl ; Save DPL push acc ; Save Acc mov dptr,#CRC8_DATA ; Point To Table .............. .............. end Hier ein Beispiel für IAR für ARM um ganz einfach mal Globale Interrupts ein/ausschalten über SWI. Es muss also
-
Thread
Atmega - Aus der Applikation in den Bootloader springen
was Du vorher gesetzt hast oder nen Taster. Bei einem Projekt habe ich sowas kombiniert mit nem CRC des Hauptprogramms. Also der Bootloader prüft ein externes Flag. Wenn das an, springt er in den Bootloader-Teil. Außerdem macht er nen CRC des Hauptprogramms und vergleicht das mit einem Wert am Ende
) ermoeglicht. (Seit commit https://github.com/baerwolf/USBaspLoader/commit/fdd80449610db4cccc152e17b04cdb51de578a61 ) MfG
-
Thread
Symbol redefined ?
____________________________________________________________________________________________ u8 CRC7(u8 * cmd, u32 len) { u8 i, a; u8 crc, Data; crc = 0; // init CRC buffer for (a = 0; a < len ;a++) // for every byte in the msg { Data = cmd[a]; for (i=0;i<8;i++) // for every bit in the byte { crc <<= 1; // shift crc if ((Data & 0x80)^(crc & 0x80)) crc ^=0x09; //xor Data <<= 1; // shift data for next bit } } crc = (crc<<1)|1; // set terminating bit to 1 return
-
Thread
64-Bit Integer Beschleunigung
Rekursion (maximale Rekursionstiefe ist 64, wenn ich mich recht erinnere). [c]bool Searcher::recurse(crc_t pAccumulator, payload_t pMaxLength, bc::number_t pRecursionsLeft) { crc_t aRollingValue = mPolynomial; for (payload_t aLength = 1; aLength < pMaxLength; aLength++) { aRollingValue
Fehlerraten geht. Die alten Hasen erinnern sich vielleicht noch an die argen Schwaechen des XMODEM-CRC...
