[ERLEDIGT] UART Interrupt Problem(?)

UART Interrupt Problem(?)

Hey,

ich stehe gerade mal wieder total auf dem Schlauch. Ich arbeite zur Zeit an der UART Empfangsroutine für meinen CAN-Knoten. Der Spaß soll über Interrupt laufen, damit das Hauptprogramm nicht gestört wird.
Der Einfachheit halber habe ich ein einzelnes Testprogramm geschrieben (und weil es viel zu lange dauert das CAN Programm dauernd neu zu flashen.....).
Das Testprogramm sieht so aus:

Code:

'Mikrocontroller $regfile = "m32def.dat" $crystal = 16000000 'Stacks $hwstack = 250 $swstack = 250 $framesize = 500 'UART konfigurieren $baud = 9600 Dim Zeichen As Byte Dim Eingabe As String * 50 Dim Eingabe_overlay(50) As Byte At Eingabe Overlay Dim Buffer_laenge As Byte Declare Sub Auswertung 'Interrupts einstellen Enable Interrupts 'Interrupts aktivieren ' 'Sprungmarke für INT0 On Urxc Uart_recieved Enable Urxc Enable Int0 Do Loop End Sub Auswertung Local Laenge As Byte Local Count As Byte Laenge = Len(eingabe) Print Eingabe; Select Case Eingabe Case "?" : Print "Fragezeichen" Case Else : Print "Falsch" End Select For Count = 0 To Laenge Eingabe_overlay(count) = 0 Next End Sub Uart_recieved: Zeichen = Udr If Zeichen = 13 Then Eingabe = Eingabe + Chr(13) Incr Buffer_laenge Auswertung Elseif Zeichen > 13 Then Eingabe = Eingabe + Chr(zeichen) Incr Buffer_laenge If Buffer_laenge > 49 Then Auswertung End If End If Return

Das Empfangen usw. klappt auch soweit ganz gut. Nur bei der Select-Case Abfrage macht das Programm nicht das was es soll.
Ich sende via Hexterminal ein 3F(?) und ein 0D(CR) und es wird mir auch mir durch den Print-Befehl auch zurück gegeben.
Allerdings gibt das Hexterminal auch 46 61 6C 73 63 68 0D 0A aus, was laut ASCII-Tabelle ein "Falsch" + CR + LF ist.
Aber wieso wird mir kein "Fragezeichen" zurück gegeben wenn ich ein 3F und 0D sende?
Hier ist nochmal der Screenshot vom Terminal:

Bild hier

Weiß da jemand Rat?
Danke schon mal und einen schönen ersten Advent.

Hallo Kampi,

ich habe jetzt nur ganz schnell einmal drübergeguckt. Könnte es sein, dass das Problem ist, dass dein String 50 Zeichen lang ist und dementsprechend die Terminierung (Nullbyte) erst beim 51. Zeichen erfolgt? Dann würden diese 50 Zeichen mit dem "?" verglichen und der Vergleich müsste immer zu "unwahr" führen. Wenn das "?" immer am Index 1 im String steht, wäre es vielleicht günstiger, nicht den String abzufragen sonden das erste Byte des Overlays.

Vielleicht ist's Unfug, das war mein erster Gedanke...

Gruß
Malte

Hey,

danke für den Hinweis. Ich teste es mal.
Das "?" ist einfach nur ein Test. Das Overlay wird im eigentlichen Programm nur verwendet um den String zu löschen, weitergearbeitet wird da mit dem String "Eingabe" (also im Grunde so wie es in dem Testprogramm ist).
Ein Eingabestring sieht dann z.B. so aus: Data,7,4,78,56,23,99 und der wird dann bei jedem "," geteilt und separat ausgewertet.
Ich habe jetzt mal testweise den String auf 49 Zeichen verkleinert aber das Problem bleibt leider noch :(

Hallo Kampi,

so ganz richtig ist das glaube ich auch nicht was ich da auf die Schnelle abgesondert habe. Das Nullbyte sollte ja immer da stehen, wo der aktuell gespeicherte String endet. Aber könnte das Problem trotzdem in die Richtung gehen? Das CR steht doch zumindest auch mit in dem String, würde das beim Vergleich mit nur "?" nicht dann zu "falsch" führen? Aber jetzt höre ich erstmal auf mit dem Gerate...

Gruß
Malte

Wenn in die Sub Auswertung gesprungen wird, dann hat Eingabe den Wert "?<CR>", wie soll ein Vergleich auf "?" da jemals zutreffen ?
Außerdem musst Du Buffer_laenge auch wieder zurücksetzen.

Zitat:

Zitat von malthy

Hallo Kampi,

so ganz richtig ist das glaube ich auch nicht was ich da auf die Schnelle abgesondert habe. Das Nullbyte sollte ja immer da stehen, wo der aktuell gespeicherte String endet. Aber könnte das Problem trotzdem in die Richtung gehen? Das CR steht doch zumindest auch mit in dem String, würde das beim Vergleich mit nur "?" nicht dann zu "falsch" führen? Aber jetzt höre ich erstmal auf mit dem Gerate...

Gruß
Malte

HA!
Das war es :D
Dank dir dafür. Gar nicht dran gedacht, dass das CR ja nicht mit abgefragt wird.....
Vielen dank nochmal!

Edit:
Dank dir MagicWSmoke :)
Hab es auch gerade mal auf mein CAN-Programm übertragen und es klappt.....jetzt kann der sch...... "Input" wenigstens mal raus :)

Hallo Kampi,
ich habe so das Gefühl, dass du die Nummer mit den Overlays noch nicht so richtig drin hast.
Wenn du ein Overlay von Bytes über einen String legst, dann ist einer der entscheidenen Vorteile in Punkto Geschwindigkeit, dass du so etwas
Eingabe = Eingabe + Chr(Zeichen)
nicht machen musst. Ebensowenig ein
Laenge = Len(Eingabe)
Dein URXC ISR sollte dann so aussehen:

Code:

Uart_received: Zeichen = Udr If Zeichen = 13 Then Eingabe_overlay(buffer_laenge) = 13 ´warum machst du das überhaupt? Eingabe_overlay(buffer_laenge + 1) = 0 ´string ende Auswertung Elseif Zeichen > 13 Then Eingabe_overlay(buffer_laenge) = zeichen Incr Buffer_laenge If Buffer_laenge > 49 Then Eingabe_overlay(buffer_laenge + 1) = 0 ´string ende Auswertung End If End If Return

Wenn du 13 eigentlich gar nicht benötigst würde ich es so verkürzen:

Code:

Uart_received: Zeichen=UDR If Zeichen>13 then Eingabe_overlay(buffer_laenge) = zeichen Incr Buffer_laenge End if If Zeichen=13 or Buffer_laenge = 50 then Eingabe_overlay(buffer_laenge+1)=0 Auswertung end if Return

Ah ok.
Ich ändere es mal um :)
Die 13 nutze ich eigtl nur um das Ende einer Übertragung zu signalisieren. Oder hast du da eine besere Idee?

Wie gesagt, speichere die 13 erst gar nicht ab, dann hast du auch nicht das "?<CR>" Problem.

Ah....ja das habe ich ja schon entfernt. Ich nutze die 13 jetzt nur um direkt in die Auswertung zu hüpfen.
Und ich habe deine Variante gerade ausprobiert....funktioniert auch, nur dass die Variable "Buffer_laenge" dann mit 1 initialisiert werden muss und nicht mit 0 (da Arrays in Bascom ja standardmässig bei 1 anfangen)