Strings empfangen klappt nicht

[LotadaC]

So... jetzt mal Ordnung machen:
-Du hast diesen Software-Flugsimulator auf dem PC zu laufen
-es gibt ein Plugin dazu (deviceLink), mit welchem "man" über das Netzwerk (UDP) requests an das "Spiel" schicken kann und welches darauf Antwortet
(-insbesondere kann ein request auch zur Eingabe verwendet werden ->

Query packet           - R/40/81\1.6e-1
  Return the aircraft altitude, and set the power to 1.6e-1.

-Du hast weiterhin (von einem User) ein Programm, welches automatisiert (von Dir "auswählbare") requests verschickt, die answers ab-/empfängt, und an die serielle Schnittstelle des PC weiterleitet (Spekulation!!!)
Das User-Programm selbst ist nicht mehr bidirektional?

Bitte meine Vermutungen bis hier bestätigen/korrigieren!

Anfrage ans Forum:
Wäre es dann nicht am sinnigsten, den AVR mit einem Ethernet-Modul auszustatten (Wiznet oder so), welches selbst bereits die hardware-Stacks bis UDP kann? (sollte es doch geben)
Anbindung an den AVR dann über (HW)SPI - dann würde er den Datenstring eben über SPI byteweise einladen und zerpflücken müssen.
Letzendlich sollte er damit nicht nur einen AVR-gesteuerten (pseudo-)Analogen Tacho etc. umsetzen können, sondern Gasknüppel/Knöppe/Schalter gleich mit dazu (halt alles, wo's in der deviceLink SETtable Keys gibt)

 

[Ditron]

Du hast recht, mittlerweile ist der Thread etwas unübersichtlich, da ich von einer kleinen Anfrage auf das ganze Projekt gekommen bin.

-Du hast diesen Software-Flugsimulator auf dem PC zu laufen

Ja

-es gibt ein Plugin dazu (deviceLink), mit welchem "man" über das Netzwerk (UDP) requests an das "Spiel" schicken kann und welches darauf Antwortet

Ja

(-insbesondere kann ein request auch zur Eingabe verwendet werden ->

Ja, aber für mich nicht relevant.

Du hast weiterhin (von einem User) ein Programm, welches automatisiert (von Dir "auswählbare") requests verschickt, die answers ab-/empfängt, und an die serielle Schnittstelle des PC weiterleitet (Spekulation!!!)

Ja, genau so.
Derzeit nutze ich einen zweiten PC, d.h. auf PC1 läuft der Flugsimulator und PC2 greift auf die UDP-Daten zu und schickt diese an die eigene Com-Schnittstelle und damit an den uC.

Das User-Programm selbst ist nicht mehr bidirektional?

Stimmt, brauche ich nicht. Ich gebe dem Programm per Config vor, was ich für Daten ich haben will. Diese werden abgefragt und deren Antwort an die Com geschickt. Es ist nicht bidirektional.

Anfrage ans Forum:
Wäre es dann nicht am sinnigsten, den AVR mit einem Ethernet-Modul auszustatten (Wiznet oder so), welches selbst bereits die hardware-Stacks bis UDP kann? (sollte es doch geben)

Ja... aber: das geht mir einen Schritt zu weit. Ich hab mir das auf der Seite von dem Ben klickmich angeschaut und das ist für mich tiefste Netzwerktechnik. Daher hatte ich mich für den "einfacherern" Weg entschieden, die Daten an der Com zu "empfangen" und auszuwerten. Das ich dabei auf solche Probleme stoßen werde, hätte ich so nicht gedacht.

Aber:
Wie ich schon schrieb, auch das dekodieren der Daten, die ich in AVR Term eingebe, funktionieren nicht. Und das gibt mir zu denken.

 

[LotadaC]

Ok, Deine Sache...
Wie gesagt prüf erstmal, ob Du die ankommenden einzelnen Bytes ordentlich als String zusammengesetzt auf's LCD bekommst.
Danach bringst Du etwas Ordnung in Deine Case-Blöcke
Neu und Erwarten kannst Du als Bit definieren (bei erwarten dann im Programm 0 und 1 verwenden)
Die Abfrage auf neu braucht keinen case-Block, da reicht if, aber ich würde das eher so machen:

select case A               'hat Cassio ja schon empfohlen
  case 65 :                 '="A" nichts zu tun (kA, ob Bascom das schluckt)
  case 47 :                 '="/"
    erwarten=0              'Instrument erwartet
    ' neue LCD-Ausgabe signalisieren
    'Instrument- und Wert-String kopieren und zurücksetzen
  case 92 :                 '="\"
    erwarten=1              'Wert erwartet
  case else                 'sonst
    if erwarten = 0 then
      'Char(A) an Instrument-String anhängen
    else
      'Char(A) an Wert-String anhängen
    end if
end select

das ganze in der UART-ISR, im Hauptprogramm dann halt auf das neue LCD-Signal reagieren, und die kopierten Daten anzeigen lassen.
Wenn das Kopieren der Strings in der ISR zu lange dauert, kann man das auch aufteilen (Instrument-String in der case 92 kopieren).
Somit können schon wieder bytes eintrudeln, während das LCD noch aktualisiert.

Edit: genau genommen ist das je eigentlich kein "neue LCD-Ausgabe"-Signal, sondern ein "neues Instrument-Wert-Paar"-Signal, aber erstmal willst Du es ja auf das LCD...

 

[Ditron]

Ok, Deine Sache...

Oder ist das doch nicht so schwer?

Ich werde mir in den nächsten Tag auch das Programm mal anschauen... klickmich!

 

[LotadaC]

Naja, das wesentliche daran kannste ja von "Ben" übernehmen - insbesondere die ... ähm ... Vervariablung der ganzen Registeradressen und der bits davon. Auch die write/read-Prozeduren usw...

 

[Ditron]

Ich glaube, ich habs...

Ich habe, wie LotadaC empfohlen, nochmal von vorne angefangen. Wie erwartet, war der String "kaputt", bzw. ergab keinen Sinn. Interessanterweise ging es aber, wenn das letzte Zeichen ein @ statt einem / war. Also habe ich, mal statt nur einem /, ein /@ angehangen... nun sieht der String gut aus.

Nun heißt es auswerten und abwarten. Wenn DAS echt der Fehler gewesen sein sollte, dann möchte ich gerne wissen warum... ich melde mich gleich wieder.

 

[dino03]

Interessanterweise ging es aber, wenn das letzte Zeichen ein @ statt einem / war. Also habe ich, mal statt nur einem /, ein /@ angehangen... nun sieht der String gut aus.

Alles sehr komisch. Es muß gehen das man X-beliebige Zeichenketten über den UART sendet oder empfängt. Irgendwo ist da der Wurm drin.

Gruß
Dino

 

[Ditron]

Irgendwie kommt das Programm nicht mit dem letzten Zeichen klar - welches auch immer das ist.

Wie ist das denn mit den ganzen Einstellungen?
Derzeit ist Databits=8, Parity=N, Stopbits=1 in AVR Term

 

[Ditron]

Ich werde nun mal was ganz anderes machen:
Den String komplett empfangen, zerlegen und anzeigen lassen.
Vielleicht klappt es ja nicht, weil der uC es während des Empfang analysieren soll.

 

[LotadaC]

Stell mal den letzten Code rein.

 

[Ditron]

$regfile = "m32def.dat"
$crystal = 16000000
$baud = 9600

$hwstack = 100
$swstack = 100
$framesize = 100

Config Portd = Output
Config Lcdpin = Pin , Db4 = Porta.4 , Db5 = Porta.5 , Db6 = Porta.6 , Db7 = Porta.7 , E = Porta.3 , Rs = Porta.1
Config Lcd = 16 * 2
Cls

Config Serialin = Buffered , Size = 50
Enable Interrupts

' Die LEDs dienen nur zur Kontrolle
Led1 Alias Portb.0
   Config Led1 = Output
Led2 Alias Portb.1
   Config Led2 = Output
Led3 Alias Portb.2
   Config Led3 = Output
Led4 Alias Portb.3
   Config Led4 = Output
Led5 Alias Portb.4
   Config Led5 = Output

Dim A As Byte
Dim Neu As Byte
Dim Erwarten As Byte
Dim Instempf As Byte
Dim S As String * 5
Dim Instrument As String * 10
Dim Wert As String * 10


Do
   If Ischarwaiting() = 1 Then
   A = Inkey()
   If A <> 0 Then
      S = Chr(a)
      If Erwarten = 2 And A = 47 Then                       'Wert erwartet? Ja! Dieser endet mit einem / -> anzeigen!
         Toggle Led5
         Cls
         Lcd Instrument
         Locate 2 , 1
         Lcd Wert
         Erwarten = 0
         Instrument = ""
         Wert = ""
      End If

      Select Case A
         Case 47 :
           Erwarten = 1                                     ' es wird ein Instrument erwartet
           Toggle Led1
         Case 92 :
           Erwarten = 2                                     ' es wird ein Wert erwartet
           Toggle Led2
      End Select

      If Erwarten = 1 And A <> 92 Then                      'es wird ein Instrument erwartet und das Zeichen ist kein \ -> also eine Zahl!
         Instrument = Instrument + S
         Neu = 0                                            'Merker Neu zurücksetzen: Zeichen wurde ausgewertet
         Toggle Led3
      End If
      If Erwarten = 2 And A <> 47 Then                      'es wird ein Wert erwartet und das Zeichen ist kein / -> also eine Zahl!
         Wert = Wert + S
         Neu = 0                                            'Merker Neu zurücksetzen: Zeichen wurde ausgewertet
         Toggle Led4
      End If
   End If
   End If
Loop

End

So, das funktioniert einigermaßen. Bitte vergesst alles, was da oben mit / \ und Problemen steht.

Der Fehler war zwischen den Kopfhörern. Der Block If Erwarten = 2 And A = 47 Then gehört nach oben, damit er vor neuem setzen von Erwarten die Sachen raushaut.

Morgen werde ich mal versuchen das ganze mit Interrupt zu lösen. Für sowas ist es nun zu spät

 

[LotadaC]

So übernimmst Du aber das "A" und die slashes vor jedem String mit, oder?
Trotzdem ist mir nicht klar, warum meine Variante nicht gehen sollte. Wenn irgendein slash kommt, ist der String vorher fertig (und wenns Anfangs ein leerer war), sodaß ich den rausgeben, und den Puffer leeren kann. Wenn der Wert-String fertig ist, stimmt außerdem das Paar. Durch das select else halte ich die slashes und jedes(!) "A" aus den Strings raus.


(Ifischarwaiting fragt das UART recieve interrupt flag ab, und inkey holt das Byte aus dem UDR, oder wie?)

 

[Ditron]

Um ehrlich zu sein, habe ich deinen Code noch nicht getestet.

Mit dem A hast du recht... aber das kann ich ja recht einfach rausfiltern (if a <> 0 AND a <> 65 THEN ... ). Heut Abend werde ich mir deinen Code nochmal anschauen u testen.

Die Idee mit dem If ischarwaiting habe ich aus dem Listing von Bonze (siehe seinen Thread vor ein paar Wochen)

 

[Ditron]

Seit gestern Abend funktioniert es! Ich gebe zZ vier verschiedene Werte (Geschwindigkeit, Kurs, Höhe, Variometer) auf einem LCD-Display aus. Am Wochenende werde ich drei der Werte mal auf drei Servos geben.

Achja, ein Bug ist noch drin: der erste Wert, der direkt nach dem A ausgegeben wird, wird nur jedes zweite Mal erfasst. Damit kann ich aber erstmal leben.

Danke nochmal an alle für die geduldige Hilfe!

 

[Ditron]

Hier mal eine kleine "Demo":

http://www.youtube.com/watch?v=Q3-G9i2Cy-E&feature=player_embedded

Zum Testen hab ich mal ein Spielzeugflugzeug an einen Servo befestigt, dass somit den Rollbewegungen folgt. Im Hintergrund zeigt der eine Servo dann noch die Steig-/Sinkgeschwindigkeit (Variometer) und die Fluggeschwindigkeit (ändert sich kaum in diesem Beispiel):

 

[Cassio]

Hi Ditron!

Das sieht ja schon richtig gut aus.
Vielleicht habe ich ja irgendwann mal die Gelegenheit einen Probeflug zu machen.

Allerdings mache ich den erst, wenn dein Höhenanzeiger zuverlässig funktioniert.
Bei meinem Sturzflug würde der sich sonst überschlagen, oder auseinander brechen.


Grüße,
Cassio

 

[Grandpa]

......

 

[Ditron]

Wenn das Ganze vorzeigbar ist, könnt ihr gerne zu einem Testflug vorbei kommen. Aber gebt mir bitte noch etwas (mechanische ) Zeit...

 

[Grandpa]

......

 

[Cassio]

gebt mir bitte noch etwas (mechanische ) Zeit...

Hi!

Ja, ja.... das altbekannte Problem!

Na gut!
Wieviele Mikrosekunden benötigst du denn noch?
Oder in welcher Zeiteinheit rechnen alle AVR-Programmierer noch gleich?

Grüße,
Cassio