- fchao-Sinus-Wechselrichter AliExpress         
Ergebnis 1 bis 10 von 10

Thema: Fehlerhafte bytes bei Printbin

  1. #1
    Erfahrener Benutzer Roboter Genie Avatar von Willa
    Registriert seit
    26.10.2006
    Ort
    Bremen
    Alter
    43
    Beiträge
    1.273

    Fehlerhafte bytes bei Printbin

    Anzeige

    Powerstation Test
    Hallo,
    ich habe ein Problem mit dem Befehl "printbin". Ich möchte einfach vier bytes + crc8 checksumme per UART senden (im Moment sende ich an meinen Computer). Das senden geschieht einmal per FTDI USB-> UART Wandler und einmal drahtlos per xbee. Ob ich per Funk sende oder per Kabel macht keinen Unterschied, das Ergebnis ist gleich. Hier der gekürzte Code den ich benutze:

    Code:
    $regfile = "m328pdef.dat"
    $framesize = 256
    $swstack = 256
    $hwstack = 256
    $crystal = 8000000
    $baud = 38400
    
    Config Serialout = Buffered , Size = 120
    Clear Serialout
    Enable Interrupts
    
    Dim Command(5) As Byte
    Dim I As Byte
    
    Do
    For I = 0 To 255
    Command(1) = 255 - I
    Command(2) = I
    Command(3) = 255 - I
    Command(4) = I
    Command(5) = Crc8(command(1) , 4)       'checksumme aus den ersten vier bytes berechnen
    Printbin Command(1) ; 5
    Waitms 50
    Next
    loop
    Komischerweise wird der Bytearray sehr oft fehlerhaft übertragen / losgeschickt. Die checksumme stimmt manchmal während 1-2 sekunden nicht, danach fängt sie sich wieder, stimmt aber sehr oft wieder nicht. Außerdem kommt es manchmal vor, dass bytes verrutschen, also z.B. command(2) plötzlich command(3) ist. Ich dachte so etwas sei eigentlich nicht möglich - wird denn nicht vor dem bytearray eine startmarkierung gesendet, und danach noch eine stoppmarkierung? Wie kann das dann verrutschen? Hat jemand einen Tipp wie ich eine zuverlässige und fehlerfreie UART Verbindung für 4 Bytes hinbekomme...?
    Vielen Dank für eure Tipps...!

    Zur vollständigkeit: Ich empfange die Daten per VB.NET, mit folgenden Befehlen:
    Code:
    'bytearray "input" mit den 5 Bytes füllen
    serialport1.Read(input,1,5)
    
    
    'crc8 berechnen (code aus Bascom Hilfe):
    unction Docrc8(ByVal s As String) As Byte
    Dim j As Byte
    Dim k As Byte
    Dim crc8 As Byte
    Dim m As integer
    Dim x As integer
    crc8 = 0
    For m = 1 To Len(s)
    x = Asc(Mid(s, m, 1))
    For k = 0 To 7
    j = 1 And (x Xor crc8)
    crc8 = Fix(crc8 / 2) And &HFF
    x = Fix(x / 2) And &HFF
    If j <> 0 Then
    	crc8 = crc8 Xor &H8C
    End If
    Next k
    Next
    Docrc8 = crc8
    End Function
    Viele Grüße, William
    -> http://william.thielicke.org/

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    18.05.2007
    Ort
    Berlin
    Alter
    52
    Beiträge
    765
    Da könnte ein Buffer (am PC) überlaufen. Auf dem PC empfange ich immer in einen "Endlosstrig" und schneide bei einem chr(13) ab. Teste es mal mit einer längeren Pause vor dem Next.
    Wenn das Herz involviert ist, steht die Logik außen vor! \/

  3. #3
    Erfahrener Benutzer Roboter Genie Avatar von Willa
    Registriert seit
    26.10.2006
    Ort
    Bremen
    Alter
    43
    Beiträge
    1.273
    Hi,
    ich glaube nicht, dass der Buffer überläuft. Der ist standardmäßig auf ~4000 bytes eingestellt und wird ständig geleert. Eine längere Pause hatte ich bereits versucht, aber bei 38400 baud sollte der controller doch 5 bytes mit 20Hz übertragen können...?
    Das Problem ist, ich weiss nicht ob mein PCProgramm nen Fehler hat, oder ob mein controller falsch sendet. Gibt es ein Terminalprogramm mit dem ich bytes loggen kann? Realterm kann zwar bytes anzeigen, speichert die Daten aber nur als ascii oder Hex. Beides kann man sich danach nicht sinnvoll angucken.
    Viele Grüße, William
    -> http://william.thielicke.org/

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    18.05.2007
    Ort
    Berlin
    Alter
    52
    Beiträge
    765
    ja, so eines habe ich mal selbst geproggt. sollte also auch in deinen möglichkeiten liegen. ansonsten gibt es tools mit logger im namen. ich glaub sogar von systernals.
    Wenn das Herz involviert ist, steht die Logik außen vor! \/

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    49
    Beiträge
    2.253
    8000000Hz != Baudratenquarz ?
    Vor den Erfolg haben die Götter den Schweiß gesetzt

  6. #6
    Erfahrener Benutzer Roboter Genie Avatar von Willa
    Registriert seit
    26.10.2006
    Ort
    Bremen
    Alter
    43
    Beiträge
    1.273
    8000000Hz != Baudratenquarz ?
    Macht das denn wirklich so viel aus...? Ich nutze sonst nur 16MHz controller... Und dort funktionierte 115200 baud ASCII übertragung bisher immer ohne irgendeinen Fehler (bzw. ich habe nie einen Fehler bemerkt). Aber ich werde mal versuchen die Baudrate hoch bzw. runterzusetzen, vielleicht hat das ja irgendeinen Effekt. Wie rechne ich aus wie lange 5 Bytes bei X baud zur Übertragung brauchen? Hat jemand die Formel im Kopf?
    Viele Grüße, William
    -> http://william.thielicke.org/

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.555
    Lade Dir mal HTerm heruter, ist Freeware und zeigt die Daten in allen
    Formaten in der Reihenfolge wie sie Kommen an. Ist sehr gut!

    1 Startbit, 8 Datenbit,Pariy (kein),1 Stopbit =10 Bit. 1/(Baudrate/10)*5

    sollte bei 1 / ((115200/10)*5) ~17 µs dauern wenn ich mich nicht
    vertippt habe.

    Gruß Richard

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.555
    Lade Dir mal HTerm heruter, ist Freeware und zeigt die Daten in allen
    Formaten in der Reihenfolge wie sie Kommen an. Ist sehr gut!

    1 Startbit, 8 Datenbit,Pariy (kein),1 Stopbit =10 Bit. 1/(Baudrate/10)*5

    sollte bei 1 / ((115200/10)*5) ~17 µs dauern wenn ich mich nicht
    vertippt habe.

    Gruß Richard

  9. #9
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    49
    Beiträge
    2.253
    nunja, die Abweichung er Baudrate war bei mir der häufigste Fehler mit solchen Auswirkungen. Bits verrutscht oder Zeichen verloren dazwischen weil die COM-Schnittstelle da nen Framing Error gesehen haben will etc.
    Vor den Erfolg haben die Götter den Schweiß gesetzt

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.555
    Du könntest auch einmal den Hard und Software Stack testweise erhöhen,
    nicht das Du eine Stak Overlow konstruierst, 259 Byte sind nicht gerade
    viel, man weiß ja nicht was der Compiler b.z.w. das Compilierte Programm
    an Stak Speicher wirklich braucht. Bascom hat aber einen Stak-Rechner
    (Tools), Der könnte helfen.


    Gruß Richard

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test