|
Anzeige
|
CRC Berechnung wie die Funktion aufrufen?Hab wieder mal ein Problem: Es geht um eine CRC Berechnung. Über die suche habe ich schon eine passende Funktion gefunden: Beitrag "CRC Berechnung" Jetzt wollte ich von einem String den CRC berechnen: 020600000001 CRC: 4839 Dazu habe ich die Routine kopiert und will sie nun folgendermaßen aufrufen:
Leider sendet die Schnittstelle gleich 16 Zeichen statt nur die zwei CRC Werte. Muss ich noch eine typumwandlung vornehmen? Oder wo liegt der Fehler?
Gast
#3120494
Chris tian schrieb: > Leider sendet die Schnittstelle gleich 16 Zeichen statt nur die zwei CRC > Werte. Muss ich noch eine typumwandlung vornehmen? Oder wo liegt der > Fehler? du sendest doch überhaupt nichts? > uart_puts(); zeig mal etwas mehr code. oh vergessen:
Gast
#3120499
> uart_puts(temp);
uart_puts braucht bestimt keinen int als paramter.
Gast
#3120507
temp = (uint8_t) num; //(Lowbyte. uint8_t oder char typcasten) temp = (uint8_t) (num>>8); // Highbyte ist genauso unsinn, der 2. Anweisung überschreibt die 1. Dann gibt es die CRC funktion schon in der AVR Lib, die muss man nicht kopieren. ok das wusste ich nicht. In welcher lib muss ich denn sucehn und wie heißt die funktion? Es muss CRC (Modbus) sein. wie man hier berechnen kann: http://www.lammertbies.nl/comm/info/crc-calculation.html
Gast
#3120513
Chris tian schrieb: > ok das wusste ich nicht. In welcher lib muss ich denn sucehn und wie schau einfach mal ein den include verzeichniss vom AVR nach, dort liegt eine crc header dateien rum. > heißt die funktion? keine ahung, steht in der header datei > Es muss CRC (Modbus) sein. wie man hier berechnen kann: auch keine Ahnung ob sie gleich sein. Aber das ändert nichts an den Fehlern in deinem Programm, das senden ist falsch.
Gast
#3120518
Hallo, du führst eine byte-weise Berechnung einer 16-bit chksum durch, dann musst du auch die Daten byte-weise anliefern und einen 16-bit Wert zurückgeben also: > uint16_t checkSum(uint8_t input[], uint8_t length) > { > int16_t crc = 0xFFFF; > int16_t mask = 0x01; > int16_t CRC = 0xA001; > > > > for (uint8_t i=0 ; i<length ; i++) > { > crc = crc ^input[i]; > > for (uint8_t j=0 ; j<8 ; j++) > { > if((crc & mask) == 0) > { > crc = crc >> 1; > } > else > > { > crc = crc >> 1; > crc = crc ^ CRC; > } > } > } > > return crc; > > } Den Aufruf dementsprechend abändern !!! Gruss Karlheinz Hab das jetzt so abgeändert:
Aufruf:
Jetzt gibt er mir auch nur noch 2 Zeichen aus., Allerdings sidn das noch nicht die richtigen Ausgegeben wird 0x57 0x43 und nicht 0x39 0x48 Deine Verwendung von int16_ macht mich nervös. Wenn du auf Byte-Ebene arbeitest, dann ist der Datentyp der Wahl praktisch IMMER ein unsigned Wert. Alle 8 Bit sind gleichberechtigt - es gibt keine Sonderfälle, weil eines der Bits die Sonderrolle eines Vorzeichenbits hat und anders behandelt werden muss. uint8_t bzw. uint16_t Was denkst du, was wohl crc = crc >> 1; ergibt, wenn crc den Wert 0xFFFF hat und vom Datentyp int16_t ist? Gut, um fair zu sein: Das Ergebnis davon ist laut C-Standard undefiniert, aber auf allen Implementierungen, die 2-er Komplement-Arithmetik benutzen kommt immer dasselbe raus. Nämlich 0xFFFF. Wodurch sich automatisch die Frage ergibt: wozu dann überhaupt schieben, wenn das Ergebnis sowieso wieder identisch zum Ausgangspunkt ist? Der, von dem du die Funktion abgeschrieben hast, war genauso auf einem Auge blind und hat sein Heil in der Verwendung eines int32_t(!) gesucht, anstatt den Stier bei den Hörnern zu packen und sich darüber klar zu werden, dass Datentypen nicht einfach nur eine 'Verzierung' des Codes bedeuten sondern dass da etwas dahinter steckt. Und gewöhn dir sowas
char buffer[6];
..
buffer[0]= 0x02;
buffer[1]= 0x06;
buffer[2]= 0x00;
buffer[3]= 0x00;
buffer[4]= 0x00;
buffer[5]= 0x01;
ab!
char verwendest du, wenn du es mit Strings, also mit Texten, zu tun
hast! Und zu sonst nichts anderem.
Für Byte benutzt du immer und ausschliesslich uint8_t und nichts
anderes. Selbst dann, wenn du von irgendwo Code bekommst, bei dem ein
char als Ersatz für 'Byte' benutzt wird. Dann siehst du den Code durch,
ob es irgendwo ein Anzeichen gibt, ob hier ein char als 'signed'
aufgefasst wird und wenn nicht, dann änderst du das um auf uint8_t.
Am besten du machst es dir zur Regel, dass du 3 'kleine' Datentypen
hast.
int8_t für kleine Zahlen, die ein Vorzeichen brauchen
uint8_t für kleine Zahlen, die kein Vorzeichen haben.
Das ist genau das, was weithin als Byte bekannt ist
char Für Zeichen bzw. Texte.
Benutze die Datentypen sinngemäss nach diesem einfachen Schema und du
hast weniger Probleme.
Danke für deine Hinweise, ich werde versuchen mich daran zu halten.
>>char buffer[6];
hatte ich in späteren posts schon abgeändert.
ICh muss ja auch zugeben das ich keine ahnung von der CRC Berechnung
habe.
Aber eshalb habe ich mir auch vermeintlich lauffähige Funktionen
gesucht, welche ich übernehmen knn und das Rasd nicht nochmal neu
erfinden.
Da ich dachte das die Funktion läuft wie im anderen Threat beschrieben,
habe ich einfach diese genommen.
Da sie aber niciht das macht was sie soll hab ich eben hier gefragt, wo
der Fehler liegt. Da jemand der jeden Tag mit sowas zu tun hat bestimmt
mehr Ahnung hat.
Ich bin den Anweisungen gefolgt aber es kommt immernoch ein falscher
Wert raus.
Kann mir jetzt nochmal jemand helfen das Teil zum laufen zu bringen?
Chris tian schrieb: > Jetzt gibt er mir auch nur noch 2 Zeichen aus., Allerdings sidn das noch > nicht die richtigen Er macht genau das, was du programmiert hast. putc(c) erwartet als Parameter ein druckbares Zeichen. Du übergibst aber eine 8-Bit Zahl. Also entweder die 8 Bit in zwei HEX Werte wandeln oder per itoa() in einen String wandeln und dann ausgeben.
Gast
#3121186
Georg G. schrieb: > Er macht genau das, was du programmiert hast. putc(c) erwartet als > Parameter ein druckbares Zeichen. Du übergibst aber eine 8-Bit Zahl. > Also entweder die 8 Bit in zwei HEX Werte wandeln oder per itoa() in > einen String wandeln und dann ausgeben. er will (vermutlich) es aber als binary übertragen und nicht als Text. Das Problem wird wohl die CRC selber und nicht mehr die übertragung sein.
Gast
#3121190
Peter II schrieb: > erwartet als >> Parameter ein druckbares Zeichen das stimm auch nicht. Er erwartet 8bit und diese werden übertragen. Peter II schrieb: > Peter II schrieb: >> erwartet als >>> Parameter ein druckbares Zeichen > > das stimm auch nicht. Er erwartet 8bit und diese werden übertragen. "putc" steht mit Sicherheit für "put char". Und char bedeutet dabei Zeichen, wie Karl Heinz dargestellt hat.
Gast
#3121385
Simon K. schrieb: > "putc" steht mit Sicherheit für "put char". Und char bedeutet dabei > Zeichen, wie Karl Heinz dargestellt hat. es geht aber um die übertragung auf UART und diese kennt keine zeichen. Hier gibt es um 8bit. Es macht wenig sinn noch eine Extra funktion für unsigned char zu schreiben. Aus dem Grund kann man hier damit leben das man der funktion einfach einen uint8 geben kann. Simon K. schrieb: > Peter II schrieb: >> Peter II schrieb: >>> erwartet als >>>> Parameter ein druckbares Zeichen >> >> das stimm auch nicht. Er erwartet 8bit und diese werden übertragen. > > "putc" steht mit Sicherheit für "put char". Und char bedeutet dabei > Zeichen, wie Karl Heinz dargestellt hat. Yep. Wobei ich das historisch sehen würde. Die Funktion ja schon zu Zeiten Kernighan&Ritchies putc geheissen. > Es macht wenig sinn noch eine Extra funktion für unsigned char zu > schreiben. Aber auch nur, weil wir wissen, dass dieses putc zb nach einem CR kein LF nachschieben wird und zb XON/XOFF nicht ausfiltert. Ich kann nur jedem raten: Nehmt die Unterscheidung Zeichen-Byte ernst! Und nur weil man bisher mit ignorieren durchgekommen ist, bedeutet das nicht, dass das immer so sein wird. das bringt mich leider alles nicht weiter.
Gast
#3121520
Zur Implementierung von dem http://www.lammertbies.nl/comm/info/crc-calculation.html habe ich mich in Beitrag "Yet another CRC32 Code" relativ erschöpfend geäußert. Das kann an mehreren Punkten haken und ist relativ frickelig: Bytereihenfolge, Initialisierung etc. pp. Cheers Detlef
Gast
#3121530
Ok, Du willst CRC16, hatte ich überlesen. Vergiss die Einlassung. Cheers Detlef Nun mach doch mal einen ganz simplen Test: Ersetze alle int16_t durch uint16_t, kompiliere und lass laufen. Und dann freu dich. (zumindest mein Standard-C Compiler, Borland Museum, gibt dir dann den gesuchten CRC) Chris tian schrieb: > Es muss CRC (Modbus) sein. wie man hier berechnen kann: LOL, über 20 Beiträge, was in einem beantwortet werden kann: http://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf Schau dir die Seiten 42 und 43 an, da wird dir eine CRC16 Berechnung auf Array-Ebene vorgekaut. nur geringfügig anpassen und fertig ist das ganze Hier sonst noch meine Version (Läuft auf einem STM32 einwandfrei, und ist auch mit diversen Modbus-Test-Programmen überprüft worden)
P.S. Ist ziemlich sicher die schnellere Variante. Gruss So habs noch schneller hinbekommen:
Das ist eine Funktion von der http://www.lammertbies.nl/comm/info/crc-calculation.html Seite. Hier gerade mit der Prüfsumme aus 0202. Funzt prima!
Gast
#3121763
Chris tian schrieb: > Funzt prima! und du hast nicht mal verstehen müssen, warum! JUHUU..... Peter II schrieb: > Simon K. schrieb: >> "putc" steht mit Sicherheit für "put char". Und char bedeutet dabei >> Zeichen, wie Karl Heinz dargestellt hat. > > es geht aber um die übertragung auf UART und diese kennt keine zeichen. > Hier gibt es um 8bit. Es macht wenig sinn noch eine Extra funktion für > unsigned char zu schreiben. Aus dem Grund kann man hier damit leben das > man der funktion einfach einen uint8 geben kann. Du weißt aber doch gar nicht, was putc macht? Vielleicht wandelt es Zeichen von lowercase nach uppercase oder ähnliches. Man macht genau das mit der Funktion, wofür sie gedacht ist. Binärbytes übertragen mit dieser Funktion ist das nunmal nicht. Chris tian schrieb: > Hier gerade mit der Prüfsumme aus 0202. Funzt prima! Und nix gelernt aus dem was hier geschrieben wurde. Prima! EDIT: Karl Heinz Beispiel bzgl. putc mit XON/XOFF ist sogar noch besser als meines.
Gast
#3121792
Simon K. schrieb: > Man macht genau das mit der Funktion, wofür sie gedacht ist. Binärbytes > übertragen mit dieser Funktion ist das nunmal nicht. dann bau doch die Lib um wenn du willst. Ich weiss das sie auch Binärbytes sauber überträgt und verwende sie einfach. Peter II schrieb: > Simon K. schrieb: >> Man macht genau das mit der Funktion, wofür sie gedacht ist. Binärbytes >> übertragen mit dieser Funktion ist das nunmal nicht. > > dann bau doch die Lib um wenn du willst. Ich weiss das sie auch > Binärbytes sauber überträgt und verwende sie einfach. Tu das. Nur wunder dich nicht, wenn man über dich flucht, wenn dein Programm an jemand mit mehr Anspruch an Struktur und Ordnung gerät. Stichwort defensives Programmieren. Das sollte so mancher mal hier nachschlagen. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
