-
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
auf sd karte bytes (ohne filesystem) reinbangen und diese lesen, obwohl karte fat32 drauf hat? Gesperrt
ein fat system hat und mir den inhalt der textdatei auf die konsole raufballern lassen, d. h. der cmd17 befehl funktionert (cmd17 signalisiert der karte, man will lesen). jetzt will ich aber einfach nen 512 block nummerieren und auf die karte bomben, und den nummerierten block auslesen. die initialisierung klappt, die karte zu beschreiben klappt auch, das lesen leider nicht. auf den befehl cmd17 erhalte ich keine antwort. meine vermutung ist die, dass ich einfach so nen byte block nicht reinklatschen kann, weil die karte auf fat32 formatiert ist. falls dem so sein sollte, wie kann ich
-
Thread
mal wieder: Spass mit Linux Gesperrt
Nacht! :-) http://www.jimbeam.com/sites/default/files/product/8188_JBRS_Straight_R1_EURO_0.png?crc=9c6c58b5
mit Windows 8, 8.1 und schließlich Windows 10 dermaßen sauer gewesen,dass ich mir Linux Mint Mate 17.3 installiert habe. Hatte auch Chinamon und XFCE getestet, aber Mate sagt mir am ehesten zu. Hilfe habe ich in Linux Foren gefunden und ich bin froh dass ich Windows nicht mehr brauche. Man
-
Thread
Kickstarter OpenSource SmartHome (Hardware und Software)
[Adresse] [Port] [Byte 2 und 3 für Daten] [Terminator] [CRC8] Auf Signale der Knoten gibt es kein OK des Servers. Das ist vielleicht nicht ganz ideal, hat sich aber in der Praxis als besser herausgestellt, da ansonsten der Multi-Master betrieb zu viele Kollisionen
gegenüber einer Funklösung. Einzig das geteilte Medium ist ein anderes. Besitzt Dein Busprotokoll eine CRC o.ä., damit wenigstens Fehler erkannt werden, wenn mehrere Teilnehmer gleichzeitig auf den Bus senden? Gruß, Stefan
-
Thread
SMART Verständnisfrage
198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 1 201 Soft_Read_Error_Rate 0x0032
Min/Max 14/43 Ist: 34 Grad sind "nur" 9 Grad Reserve. Bernd: Min/Max 14/59 Ist: 42 Grad, macht 17 Grad Reserve... MFG, EGS aus dem sonnigen Mexico...ach nee ist ja mittlerweile dunkel aber dennoch warm ?
-
Thread
Datenrettung mit ddrescue
- 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 17 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 3 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 1
-
Thread
STM32F446ret6 JTAG-Problem
würde ich immer "verify flash download" auch noch anschalten, jedenfalls sofern Deine Software keine CRC über sich selbst bildet und auf dem Target auch prüft. Du könntest Dir natürlich auch CoFlash mal installieren, das sollte mit ST-Link umgehen können: http://www.coocox.org/software/CoFlash.php
Bit 0 - 5 [PLLM= /16] = 010000 Bit 6 - 14 [PLLN= *192] = 0110 0000 0 Bit 15 - 17 [PLLP= /2] = 00 */ RCC->PLLCFGR |= 0x00403010; /* SystemClock = PLLCLK AHB-Precaler = /1 */ RCC-> CFGR |= 0x00000001; /*Bit 0 und 1: 01 HSE as System Clock*/
-
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
BME280 per OneWire mit DS28E17
// I2C Register to read BME.write(0x02); // Number of data bytes to be read BME.write(crc); // CRC 16 [/c] 1. Der BME280 hat mit SDO auf GND eine 7bit Adresse von 0x76. Der DS28E17 erwartet eine 7bit Adresse und schaltet das R/W bit selbständig. Ist es dann korrekt 0xEC zu senden? 2. Der DS28E17 erwartet einen CRC16 auf die gesendeten Bytes. In der OneWire Library sind ja CRC16 Routinen enthalten. Dort muss aber ein crc Wert übergeben werden. Wie hab ich das zu verstehen? [c] uint16_t OneWire
-
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
Neue Library: RFID Desfire EV1 Karten mit Arduino programmieren
Befehle berechnen eine CMAC, andere nicht. Wenn ein neuer Schlüssel auf die Karte geladen wird müssen 2 CRC32 Werte berechnet werden, der alte Schlüssel wird mit dem neuen verexklusivodert (XOR) mit Nullen aufgefüllt und mit dem Session Key verschlüsselt. Jeder Schlüssel Typ has seine Besonderheiten: AES
verloren Logisch. Aber wie im Artikel beschrieben liefert ein 12V Trafo eine Peak Spannung von 17 Volt. Effektivspannung mit Wurzel(2) multiplizieren -> Peak Spannung. 12 Volt wären sowieso zu wenig, da die Battarie ja (wie im Artikel beschrieben) permanent auf 13,6 Volt gehalten wird.
-
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
RFM12BP mit ATmega48 ansteuern
werden ohne das vorher noch gemessen werden muss. Zum Schluß werden auf der Request-Seite der ID, die CRC und der Zeitstempel vom Antwortpaket überprüft. Ist alles OK dann wird Erfolg gemeldet. Stromverbrauch, Abmessungen und Übertragungsgeschwindichkeit waren nicht kritisch. Die beiden Module sind auch
Torsten K. schrieb im Beitrag #4635035: > RFM12BP-0.01.zip (17 MB, 1 Downloads) Du lädst auch alles hoch, was die Panasonic HX-WA20 so hergibt, oder? Ohne die drei Monsterbilder wird das schon viel handlicher.
-
Thread
welches Filesystem
dem µC Daten von so einem Filesystem zu lesen. naja, man kann es auch übertreiben, eine einfache CRC32 (oder zur not md5/SHA512) sollte man eh über die Firmware machen. Damit sind schon alles Fehler im Dateisystem ausgeschlossen.
Peter II schrieb im Beitrag #4621920: > naja, man kann es auch übertreiben, eine einfache CRC32 (oder zur not > md5/SHA512) sollte man eh über die Firmware machen. Damit sind schon > alles Fehler im Dateisystem ausgeschlossen. Ja, ein CRC32 ist in der Datei vorhanden und liegt auch später
-
Thread
ATMEGA 328p Programm Upload nicht Möglich avrdude: stk500_loadaddr(): (a) protocol error, expect=0x1
flashen (was misslingt) und hier https://www.mikrocontroller.net/attachment/296990/2016-06-20_17h21_04.png ist es 3e00 mit 512 words (aber ohne BOOTSRST), was dann aber gelingt. Weißt Du, was Du da tust?
was misslingt) > > und hier > > https://www.mikrocontroller.net/attachment/296990/2016-06-20_17h21_04.png > > ist es 3e00 mit 512 words (aber ohne BOOTSRST), was dann aber gelingt. > > Weißt Du, was Du da tust? ähm ... was soll ich jetzt sagen ... ganz erlich ich schrieb schon das das
-
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
Welchen Bus nehmen? Smart Home / Temperaturmessung und mehr
> RS485. … Slew rate limited Treiber Das ist doch auch schon fast CAN. Und CAN nimmt Dir noch CRC-Check, Error-Frames usw. ab. Größere Datenblöcke per ISO-TP. µCs mit CAN gibt es massenhaft billig. Und dort dann z.B. einen DHT22 dran. Knoten-Adresse per CAN oder VCOM einstellbar, in EEPROM
Wärmetauscher allerdings krass wirkungsvoll, wie ich finde. 20°C Abluft wärme die kalte Frischluft auf rund 17° vor, so dass ich nur 3° Differenz wieder aufheizen muss. Die Topologie des 1-Wire Netzes ist inzwischen ein wenig modifiziert, es sind inzwischen glaube 3 oder vier direkt angeschlossene Netze und
-
Artikel
AVR-Bootloader mit Verschlüsselung von Hagen Re
XTAL von 600 bis zu 256000 Baud per USB-RS232 XTEA Verschlüsselung für FLASH/EEPROM Schreiben 16Bit CRC für die komplette Datenübertragung, Senden & Empfangen FLASH schreiben/löschen mit implizitem Verify separates FLASH Verify EEPROM schreiben/lesen, schreiben mit implizitem Verify SRAM schreiben/lesen
wurden einige Watchdog Reset Aufrufe anders plaziert. 15.03.2009 22:52 16.03.2009 00:49 Version 6.0. 17.03.2009 03:36 Updates /Bugfix zur Anpassung an AVR-Studio 4.16
-
Thread
Hex-Werte in Temperaturen umrechnen?
if( (SignalHash!=SignalHashPrevious) || (RepeatingTimer+1000<millis()) ) { //SignalCRC=bitstream; // not seen the RF packet recently } else { return true; // already seen the RF packet recently } //====
=05; 07.06.2016 22:13:15 - 20;09;Imagintronix;ID=0003;TEMP=0014;HUM=05; 07.06.2016 22:16:23 - 20;17;Imagintronix;ID=0003;TEMP=0013;HUM=05; 07.06.2016 22:17:57 - 20;22;Imagintronix;ID=0003;TEMP=0013;HUM=05; 07.06.2016 22:19:31 - 20;2D;Imagintronix;ID=0003;TEMP=0013;HUM=05; 07.06.2016 22:24:13 - 20
-
Thread
Protokoll einer Wetterstation - Prüfsumme vorhanden?
//Regenmenge (Aufsteigend) Byte 15: 01 //Regen (Durchschnitt)? Byte 16: 00 //Regen (Max)? Byte 17: 08 //UV Wert Byte 18: 3F //Unbekannt - Immer 3F Byte 19: B1 //Unbekannt - Immer B1 Byte 20: E7 //Unbekannt - über längere Zeit der Selbe Wert aber steigend Byte 21: 00 //Unbekannt Byte 22: D9 /
4mm), uv=uvindex (*10) ld=lightningstorm-distance (km, 3F is max) lllh=strikecount-low/high (#) crc (poly 0x31, init 0xff, revin&revout, xorout 0x00) ?? as of yet unknown I found the crc using revenge (reveng.sourceforge.net) Edit: typos
-
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
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
RFM12-433 gegen 868 tauschen
richtig ankommt. Auch wenn bei Versuchen Sender und Empfäger direkt nebeneinander liegen (beide mit 17cm Wurfantenne) gibt es immer wieder ein paar Aussetzter. Jetzt war die Überlegung das RFM12-Modul gegen ein RFM12-868 auszutauschen. Würde das so ohne weiteres mit derselben Software funktionieren
ca. alle 3s ein Paket. Das Protokoll der Dinger hat jemand mal analysiert, ist sehr komplex mit CRC und speziellen Paddingbits. Bei denen ist mir beim Test so gut wie nie aufgefallen, daß ein Paket nicht ankam. Auch hier wird ein Paket ja ohne jede Quittung und nur einmal gesendet. Gruß aus Berlin
-
Thread
1Wire-Bus SEARCH ROM missverstanden?
using parasitic power rc = ds18B20_read_temp(&x); if (rc) { Serial.println(F("CRC error!")); } else { Serial.print(F("T: ")); Serial.print(x / 10); Serial.print('.'); Serial.print(abs(x) % 10); Serial.println(F(" C")); }
temperature of DS18S20 1 : T Raw: 343 = 21.4 °C Reading temperature of DS18S20 2 : T Raw: 282 = 17.6 °C Reading temperature of DS18S20 3 : T Raw: 289 = 18.1 °C [/code] Damit steht fest: 1. Die Library von Volker U. bzw. von Peter Dannegger versagt bei mehreren Sensoren 2. Du hast Dir mit Deiner
-
Thread
Proxxon MF70-CNC-Ready Einstellungen
Forum viel gelernt und auch einiges verstanden. Eine Vorstellung meiner Hard/Software : Meine CRC-Maschine ist eine MF 70 CNC-Ready: http://www.proxxon.com/de/micromot/27112.php also mit von Proxxon installierten Steppermotoren http://de.nanotec.com/fileadmin/files/Datenblaetter/Schrittmotoren
von ESTLCam rum. Ich wollte mal fragen welche Werte ihr da genommen habt. Zur Zeit nutze ich Nema 17 Motoren und habe 1600 Umdrehungen und 1,0mm Wege je Umdrehung eingestellt. Meine Teile werden aber glaube ich zu klein. Hätte vielleicht mal jemand eine kleine Beispieldatei um ein einfaches PCB-Layout
-
Thread
FT800 / FT810 Library
: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC I (14061) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x 17 I (14066) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x 17 I (14071) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x 17 I (14076) Touch: 0xFE 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x 17 I (14511) Touch: 0x 0
entschlüsseln (dekomprimieren) kann. Viele Bytes sind nebeneinander liegend gleich, also kann man statt 17 x ein FF auch eine Ankündigung z.B. "(" (Hex 28) für "Es folgt eine Verschlüsselung gleiche Bytes", dann eine 17 (17 mal das folgende Byte) und dann ein FF. Also aus 17 Bytes sind so 3 Bytes geworden
-
Thread
Protokoll für Serialle Kommunikation
Beispiel: *D12,34,56,129# *C74,"Hello World",17,9600# * Startmarkierung D Datensatz folgt C Config folgt , Trenner zwischen Daten # Ende des Datensatzes Sender und Empfänger können unabhängig voneinander mit einem simplen Terminalprogramm
Dauergast schrieb im Beitrag #4546311: > Beispiel: > > *D12,34,56,129# > *C74,"Hello World",17,9600# > > * Startmarkierung > D Datensatz folgt > C Config folgt > , Trenner zwischen Daten > # Ende des Datensatzes > > Sender und Empfänger können unabhängig voneinander mit einem simplen