-
Thread
PIC628: ORG und ab ins Nirwana ...
retlw 12h retlw 9 retlw 16h retlw 0bh retlw 17h ... ; viele retlw Zeilen ... retlw 0fh end ################################### Werden nur die Zeilen org 300h und data_crc-300h auf eine andere
grenze crc_1: addlw 30 crc_2: addlw low(data_crc) ; low adresse von data_crc dazu movwf retten ; zusätzlicher speicherplatz movlw high(data_crc) ; high adresse von
-
Thread
Byterkennung UART
Impulsen. Das Signal wird durch ein 18ner Array erzeugt, wobei die Felder Aray 3,5,7,9,11,13,15 und 17 mit entsprechenden Werten für die Impulslängen beschrieben werden. Nun werden bei einem empfangenen Byte die einzelnen Bits auf 0 oder 1 verglichen. Ist das erste Bit 1 schreibe eine 30 in das Feld 3
als Command or Data Erkennung. Das naechste Byte als Commandlength oder Datalength und zum Schluss CRC und ein Stopbyte. So kannst du wirklich sicher sein das ein komplettes Frame empfangen wurde. Vom Programmiertechnischen hat dir schon Bjoern Mueller weitergeholfen. Gruß, Dirk
-
Thread
SD macht Mist
ich noch jedes Byte einzeln geladen und ausgegeben. Dann habe ich das Prog. optimiert(CMD+Argumente+CRC)alle in Register und in einem Rutsch ausgeben. Seit dieser Zeit komme ich nur noch bis CMD10(CID) R1=00, aber das Startbyte ist grundsätzlich nur noch $FC, was eigentlich das StartByte bei "Block Write
Daten nur noch Mist(aber es kommen welche). Egal was ich mache,(Pausen zwischen den Bytes,CMD9(CSD),CMD17(Single Block Read)) es bleibt bei $FC als Startbyte. In einem Rechner geht die Karte ohne Probleme und ist auch nicht gesperrt. Die Sende und Empfangsdaten habe ich übrigens mit einem 4-Kanal Oszi getestet
-
Thread
1-Wire Slave auf AVR
einfach mit eingefügt und nun geht’s ohne Probleme. Für den Counter muss wohl ein Attiny25 herhalten. CRC16 und die 80 Bit die zur Abfrage getauscht werden müssen... das geht einfach nicht in 1k. Aber ein alternativer Counter der nicht Kompatibel zu Dallas ist geht bestimmt. Vielleicht mit CRC8 und
und 0xA5 0xA5 + 2 Byte Adresse die nicht ausgewertet werden liefert: X C0 C1 C2 C3 0 0 0 0 CRC0 CRC1 X: letztes (eigentlich adressiertes) Byte C0 C1 C2 C3: 4 Byte Counter LSB first 0 0 0 0: 4 mal 0 nach Spezifikation CRC0 CRC1: 2 Byte CRC LSB first Weis jemand ob dass das SRAM des
-
Thread
DCF Auswerte Konzept
Paritätsfehler, und das Ergebnis ist wieder richtig. Passiert bei mir gelegentlich so. Hier wäre ein CRC-Verfahren vermutlich besser, aber da wäre ein DCF-Datenpaket etwas umfangreicher. Besser wäre kein Update der Uhr jede Minute, sondern: 1 Minute Uhrzeitdaten, eine weitere Minute Redundanzdaten, wäre
hellhörig sein und Änderungen (Umschaltzeitpunkte sind ja bekannt) prompt durchschalten. Eine CRC-Prüfung wäre auch damals (als die Auswertung noch mit Hardware geschah) mit dem vorhandenen Schieberegister recht einfach gewesen. Hat man aber nicht gemacht. Dafür aber doppeltes Parity.
-
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
U-Blox GPS Modul sendet nur wirres Zeug.
KF moding parameters to defaults:<19>›°³ ¢<\0><26>ÿKF AltConstraint: enabled<\n><27>°³ ¢<\0><17>ÿKF AltMode: auto<6>i°³ ¢<\0><26>ÿKF AltSource: last KF alt<9>b°³ ¢<\0><26>ÿKF DegradedMode: t_then_d<9>ä°³ ¢<\0><27>ÿKF DegradedTimeout: 10 sec<9>½°³ ¢<\0><21>ÿKF DRTimeout: 10 sec<7>C°³ ¢<\0><23>ÿKF
keine Parität *0C Prüfsumme <--muss neu angepasst werden. Berechnung hier: http://www.kh-gps.de/crc.htm
-
Thread
Block-Lesen von SD-Karte klappt nicht
nichts darüber, wie man die Karte adressiert. Ich schicke folgendes Kommando: "READ_SINGLE_BLOCK" (CMD17), "0x00" (soll Adresse Null heißen). Was mache ich falsch. Andy
> 16 & 0xFF); SPI_SendeByte(data >> 8 & 0xFF); SPI_SendeByte(data & 0xFF); SPI_SendeByte(crc); SPI_SendeByte(DUMMY); // 8 Dummy-Clocks senden
-
Thread
MMC/SD-Karte mit FAT16 an AVR
ich mit 0xff um die Antwort von der SD-Karte zu bekommen. Normalerweise müste ich doch nun nach dem CRC irgendwann eine 0x01 von der Karte zurückbekommen. Komisch ist das die SD-Karte schon ab dem vierten 0x00 Block des Kommandos,immer mit 0xFE und gleich dannach mit 0x03 antwortet. Dann bekomme ich
Kingston-Karte steckt eine halbe Kopie der CSD in dem CID- Register. Bei der Platinum-Karte stimmt die CRC7 bei CSD nicht. Was wieder eine ganze Reihe von Fragen aufwirft. ;-) Vielen Dank! August
-
Thread
Integer Math Lib
Appnotes/Algorithm/math folgendes: Appnotes Description Date Launch TB043 KEELOQ® CRC Verification Routines 11/8/04 AN670 Floating Point to ASCII Conversion 9/11/01 AN752 AN752 CRC Algorithm for MCRF45X Read/Write Device 3/15/01 TB040 Fast Integer Square Root
Floating Point Routines 8/26/97 AN643 Adaptive Differential Pulse Code Modulation using the PIC16/17 8/26/97 AN544 Math Utility Routines 8/26/97 AN617 Fixed Point Routines 8/26/97
-
Thread
winziger Webserver mit enc28j60+mega32
zwei alternative Bezugsquellen gepostet ;) Status Platinen: Sind in Fertigung, Lieferung KW11 -> ~17.03.06 denk ich Gruss, Simon
wirklich die paar bytes bzw mehr geschwindigkeit :) >Tatsache, der enc kann ja echt selber nen crc berechnen So wie es aussieht braucht es doch aber die CRC gar nicht? (also die, die ganz am Ende des Packets hin kommt) praktisch 100% der Pakete die ich mit Ethereal angeschaut habe, haben diese
-
Thread
RS232 per Funk über 500m
Empfänger nur dann was dorthinleiten wenn das Telemetriepaket korrekt empfangen wurde (z.B. durch CRC). Diversity nennt man das Prinzip. Viel Baß beim spasteln... Hendrik.
gar nichts. Ich hab hier mal ein pdf von der Schulung meiner Telemetriesoftware (siehe Seite ab 17): ftp://schildknecht.info/Schulung_Racestudio.pdf 2MB Hier mal ein Link auf die Internetseite meines Teamkollegen (leider mit Moterschaden meinerseits) mit dem Wankel : http://www.timo-weigert.de
-
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
MMC Read Single Block CMD1
möchte. Die MMC bekomme ich nun auch initialisiert und bis in den TranState. Nun möchte ich mit CMD17 Read_Single_Block Bytes von der MMC lesen. Wie muß ich nun hier genau vorgehen? Welche Register müssen wann gesetzt werden und welche Commandos braucht die MMC? Den Datenblättern konnte ich zwar einiges
Hallo Thomas Ich stehe genau an der Stelle, wo Deine Frage hier ansetzte: also CMD 17. Karte ist initialisiert, CMD 7 ist raus, und jetzt??? Kommt nun zuerst das CMD 17 und dann die Initialisierung im µC?? Oder umgekehrt?? Ich habe es so weit, dass ich im MMINT des AT89 die Meldung
-
Thread
8051er Microcontroller Programm
A9 P2.2 = A10 P2.3 = A11 P2.4 = A12 P2.5 = A13 P2.6 = A14 P2.7 = A15 P1.0 = A16 P1.1 = A17 P1.2 = A18 P1.3 = A19 P1.4 = A20 P1.5 = A21 P1.6 = A22 P1.7 = Doppel so schnelle Taktung wie auf P0.0 = AD0?? Ist das möglich?? Vielen Dank Rolf
einem EPROM kann ein einzelnes falsch übertragenes Bit die Daten unbrauchbar machen. Also entweder CRC berechnen und zum Schluß separat ausgeben, oder die Daten gleich z.B. im Intel-Hex Format übertragen.
-
Thread
Webserver zur Temperaturmessung
Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 main.c -o main.o In Datei, eingefügt von main.h:17, von main.c:29: ./avr/signal.h:36:2: Warnung: #warning "This header file is obsolete. Use <avr/interrupt.h>." In Datei, eingefügt von main.h:23, von main.c
und Sender) vom Controller zur Fernbedienung geführt werden." -> Sender heißt in dem Fall DOUT (Pin17) am HX2262? Danke Thomas
-
Thread
Elektor - nächste Ausgabe mit R8C/13 Platine
gerade das Datenblatt angesehen und komme wieder ins Schwärmen: CAN on Board, HW-32-bit-Multiplier, HW-CRC-16-CCITT, X/Y-Converter, das ist ein feines Teil: es sind 16 16-bit-Register, die man zeilen- UND spaltenweise auslesen kann, also optimal, wenn man z.B. Graphiken um 90° drehen will. Ich muss
Seite von elektor: "denn am 17. November erscheint mit dem Dezember-Heft inkl. Gratis-Starterkit (bestehend aus dem R8C-Mikrocontroller-Board + dazugehöriger Software-CD) " also noch etwas Geduld. Die Schneckenpost ist halt nicht
-
Thread
Messabweichung beim 1-wire DS1
direkt nebeneinander messen aber unterschiedliche Werte. Sensor 1: Temperatur in Grad Celsius: + 17.5 °C 16 2 Sensor 2: Temperatur in Grad Celsius: + 19.5 °C 16 5 Um die Sache noch spannender zu machen ein normales Thermometer (Analog/Quecksilber ;-)) misst an der selben Position 22 °C. Hat
@Jörn Ich wollte als nächstes den CRC Code schreiben damit ich mir sicher bin das die Werte stimmen. Was aber nicht so trivial ist. @Ratber Das mit den tiefen Temperaturen sollte klar sein ;-) bevor ich die Teile in flüssigen Stickstoff
-
Thread
CRC16
Ok, hat sich erledigt. Meine Lösung ist folgende: [C] unsigned short crc16(unsigned char * pBuffer, unsigned short len) { unsigned short crc = 0; for(int i=0; i<len; i++) crc = (unsigned short)((crc >> 8) ^ crc16tab[*pBuffer++^(crc&0x00FF)]); return crc; } int main(void) { unsigned char Buffer[] = "12"; printf("\r\nCRC16 = 0x%04X", crc16(Buffer, 2)); return 0; } [/C]
-
Thread
USB2.0 Core
never used. WARNING:Xst:647 - Input <int_seqerr_set> is never used. WARNING:Xst:647 - Input <int_crc16_set> is never used. WARNING:Xst:647 - Input <pid_SPLIT> is never used. WARNING:Xst:647 - Input <pid_NACK> is never used. WARNING:Xst:647 - Input <crc5_err> is never used. WARNING:Xst:647 - Input
OpMode_pad_o<0>" LOC = "J24" ; NET "OpMode_pad_o<1>" LOC = "H24" ; NET "phy_clk_pad_i" LOC = "C17" ; NET "phy_rst_pad_o" LOC = "B16" ; NET "resume_req_i" LOC = "D16" ; NET "rst_i" LOC = "B17" ; NET "RxActive_pad_i" LOC = "A17" ; NET "RxError_pad_i" LOC = "A16" ; NET "RxValid_pad_i
-
Thread
Wie serielle Kommunikation zwischen µC und PC aufbauen???
, sollte man diese stückeln oder kann man die am Stück rüberschieben? Ich weiß, dass es unzählige CRC Prüfroutinen usw. gibt, aber das ist wohl alles sehr aufwendig zu implementieren und mich würde mal interresieren, wie das Ihr so macht? Vielleicht habt ihr ja ein paar Ansätze und Informationen
noch eine Checksumme sein: Also einfach Zeilen dieser Form: 4 123 542 669 7 9832 0023 9862 17 0000001 435 453 5 -434 +43 -386 Das ist absolut eindeutig, und in diesem Beispiel ist die letzte Zahl schon eine einfache Prüfsumme. Dieses Protokoll ist auch tolerant: Es gibt keine Probleme mit
-
Thread
Datenübertragung per Licht oder Laser
10m müßte mit einem TSOP17XX gehen. Der schafft laut Datenblatt 9600 kbps. Wäre wohl die einfachste und billigste Lösung.
Die TSOP17XX Serie ist veraltet und wird IMHO nicht mehr hergestellt, besser ist die TSOP48XX Serie. Ich komme mit einem 40 khz TSOP4840 nur auf max. 2 kbps, mit 10cycle bursts, 10 cycle Pause. Also weit unterhalb
-
Thread
Belohnung: Wer macht mit bei meinem Projekt?
Tom, Du hast recht, aber gegen die PC Lösung (wir haben schon ein kleines, schnelles 17x17cm Industrie MiniITX Board mit Pentium M benutzt) spricht erstens der Stromverbrauch und zweitens daß der PC-Bus seine Grenzen erreicht hat. Da ich aber beabsichtige demnächst die nächste (und übernächste
1 f = feedback 2 DD = Data to or from the bus 3 CRCOUT = 16-bit edge triggered result (current CRC) 4 CRCOUT(15:0) are sent on matching order bits of DD(15:0) 5 CRCIN = Output of combinatorial logic (next CRC)
-
Thread
Handlicher Ethernet-Controller mit SPI von Microchip
schicken, da muss bestimmt zumindest der Header selbst gebastelt werden, aber wenigstens macht er den CRC selber... Bei 10 MBits/s ist doch ein AVR ganz gut beschäftigt - oder?
immer 0x83 drin. Beim einstellen des PerPacketBytes aendert er jedoch auch nix, bzw haengt er keine CRC dran. Ist ein Bug im MACON3 bekannt? Benutze leicht umgebaut eigentlich den AVRLIB code. Gruss Daniel
-
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
Programm zur billigen Relaisplatine 8FA
@Thomas: Das Problem tritt immer auf wenn mehr als 17 Karten kaskadiert werden. Es werden die Karten zwar angesprochen, aber mit den Rückmeldungen klappt es nicht mehr. Bis 17 Karten werden alle erkannt beim -i. Ich hab jetzt auch experimente mit einer
Karte gemacht. Selbes Problem. Da ich ca. 40 Karten ansteuern muss mache ich jetzt einen Split nach 17 Karten und verpasse den nächsten 17 einen anderen ttyS. Genaue Fehlermeldung beim -i: Es wurden keine Daten empfangen! (timeout) Es wurden keine Relaiskarten gefunden! :-( Das Programm wird auf Grund
-
Thread
AVR Ethernet Platine
über den CPLD laufen, das wären dann 10 Pins, bleiben 34 - 12 - 10 = 12. Man bräuchte aber 8+8+1=17 für den Latch. Stellt sich nun die Frage wie man sich entscheidet. Entweder Addressdekodierung + Latch macht 34 - 11 - 17 = 6 freie Pins am CPLD für zusätzliche Aufgaben. Oder Addressdekoder + MUX
paar Pins und Makro-Zellen für extra Hardware im CPLD frei. Ich denke da z.B. an extra PWM, schnelle CRC-Berechnung oder sowas. Matthias
-
Thread
SourceCode MMC die Zweite
Na ok, CMD0 ist identisch, kann man als CRC senden was man möchte?
Der CRC wird wird im SPI Modus der MMC/SD Karten nicht verwendet (außer beim allerersten Kommando nach dem Einschalten welches die Karte in den SPI Mode schaltet). Man CRC aber auch für den SPI Mode einschalten
-
Thread
AT89C51SND1C
gebacken. Irgendwie kommt von der Karte keine vernünftige Antwort. Mich macht stutzig, das das Bit CRC7 immer auf "0" steht. Über Tips wäre ich sehr dankbar. Übrigens: Wer noch AT89C51SND1C (TFPQ80) braucht, ich habe meistens welche da (24,95 + Versand). Gruß Doc
Jemand hat mir am 17.06.05 eine Antwort geschrieben. Beim Abholen ist Mail verloren gegangen. Bitte nochmals senden. Danke Ich bin weiterhin an einem einfache Source Code in Assembler oder C für AT89C51SND1 interessiert
-
Thread
MMC/SD ansteuern mit AVR
von MMC/SD-Karte for (int a=0;a<16;a++) { *Buffer++ = Read_Byte_MMC(); } //CRC-Byte auslesen tmp = Read_Byte_MMC();//CRC - Byte wird nicht ausgewertet tmp = Read_Byte_MMC(); return(0); }
dem CMD18 und CMD23 erklären ? möchte gerne 200 Blocks am stück auslesen, ohne pausen. bei CMD17 muss ich immer auf 0xFE,anfang jeder Datenuebertragung (Block) warten ...Command(0x51,H,L,0xFF)
-
Thread
DS1820, DS18B20 in C
{ data = ow_buffer[loop_count]; bit_counter = 8; do { feedback_bit = (crc ^ data) & 0x01; if ( feedback_bit == 0x01 ) { crc = crc ^ CRC8POLY; } crc = (crc >> 1) & 0x7F; if ( feedback_bit == 0x01 ) { crc = crc | 0x80;
loop_count++) { b = data[loop_count]; bit_counter = 8; do { feedback_bit = (crc ^ b) & 0x01; if ( feedback_bit == 0x01 ) { crc = crc ^ CRC8POLY; } crc = (crc >> 1) & 0x7F; if ( feedback_bit == 0x01 ) { crc = crc | 0x80; }
-
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
DS1820 - spricht nicht an ...
;wenn 1-wire = 0, dann rjmp _ds1820_reset_wait0_end ;Ende der Schleife dec r17 ;wenn Zeit noch nicht abgelaufen (r17) brne _ds1820_reset_wait0_loop ;dann erneute Schleife breq _ds1820_reset_end ;sonst Z=1 -> break _ds1820_reset_wait0_end: ldi
ds1820_1wr_bit ;maskieren rcall delay400us ;Wartezeit min. 400us + 80us in r17,ds1820_in_port ;1-wire port nach r17 und andi r17,ds1820_1wr_bit ;maskieren eor r16,r17 ;beide unterschiedlich? pop r17 ;Register zurückholen
-
Thread
AVR Bootloader
Hier seine Mail an mich: > Anbei eine neue Version des Bootloaders. > Jetzt ist Verify und CRC-Check mit drin: > 0 = CRC o.k. > -2 = CRC Fehler > -1 = CRC nicht unterstützt (alter Bootloader) > > Read ist auch im AVR drin, nur im PC-Programm fehlts noch. > Mit "RSIZE" kann der PC abfragen
moin, kann mir bitte jemand erklären wie das mit dem CRC funktioniert? steige da überhaupt nicht durch, wäre sehr dankbar. hoffe jemand ist so nett? mfg flo
-
Thread
CRC-16 Prüfsumme (serielle Übertragung)
; crc ^= (unsigned char)(crc & 0xff) >> 4; crc ^= (crc << 8) << 4; crc ^= ((crc & 0xff) << 4) << 1; return (crc); } Keine Loop und fast nur byte oder nibble swaps. Über die Qualität des
, 0xD68D, 0xE70E, 0xF78F }; unsigned short crc_update (unsigned short crc, unsigned char c) { crc = (((crc >> 4) & 0x0FFF) ^ crc_tab[((crc ^ c) & 0x000F)]); crc = (((crc >> 4) & 0x0FFF) ^ crc_tab[((crc ^ (c>>4)) & 0x000F)]); return
-
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
Programmierbeispiele
cp r31,r27 brne rec10 ;noch nicht beim CRC-Pointer angelangt ld temp3,x+ cp temp3,temp2 ;Vergleich eingeles. mit berechn. Pr.-summe brne dinit2 ;High-Byte stimmt nicht! ld temp3,x+ cp temp3,temp1 brne dinit2 ;Low-Byte stimmt nicht! ;hier Empfang der Bytes OK!, Prüfsumme und CRC waren in Ordnung ldi temp1,0 std y-RS+flblock,temp1;erst evt. laufende allFlashausgabe stoppen ldd temp1,y-RS+dbuf+1 ;der Absender ist auch die neue Adresse std y-RS+dwohin,temp1 ldd