Hallo Leute,
ich sitze seit einer halben Ewigkeit an einer Datenübertragung vom PC
zum Controller.
Es geht um 127 Presets mit je 16 Zeichen Namensstring und 16
Relaiszuständen.
Wenn ich vom Rechner an den Controller Sende und das danach auslese habe
ich nur Schrott drinstehen.
Wenn ich Presets direkt am Gerät bearbeite und dass dann auf den rechner
lade passt die Sache.
Ich wäre sehr froh, wenn jemand da mal drüberschauen könnte, nach 8
Stunden an der selben sch'#@e bin ich wohl so langsam Betriebsblind.
Sendecode (vb.net):
1
Private Sub BwSend_DoWork(ByVal sender As System.Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles BwSend.DoWork
2
Com.Write("S") ' Sende!, Pipe als delimiter
3
Do
4
Loop Until Com.ReadTo("|") = "A"
5
For z1 = 1 To 128
6
' Es gibt keine Fixlängen-Strings unter .NET, daher Eingabefelder begrenzen und nach rechts mit Leerzeichen auffüllen
sub procedure WaitForChar(dim Acknowledge as boolean)
44
do
45
loop until NewReceive=true
46
if acknowledge=TRUE then
47
UART_WRITE_TEXT("A|")
48
end if
49
end sub
50
51
.... ISR....
52
if ReceiveMode = 0 then ' RS232-Empfang
53
TempChar=receivetemp
54
NewReceive=true
55
end if
56
....
Wäre echt Super wenn sich jemand dafür erwärmen könnte mal drüber zu
schauen. Mir raucht so langsam der Kopf, ich komm und komm nicht weiter.
Gruß,
Jens
Schau doch mit nem Terminalprogramm erstmal nach, obs nen Problem auf
der Sender- oder Empfängerseite gibt. Dann kannst du an der
entsprechenden Stelle weitersuchen...
>UART_WRITE_TEXT("A|")>..>WaitForChar(false)
Scheint mir blockierender Betrieb zu sein. So wird das nichts. Mach ne
Zustandsmaschine, die gleichzeitiges Senden und Empfangen zulaesst.
gleichzeitiges Senden und Empfangen ist hier (in diesem Modus des
Programmes) nicht nötig bzw erwünscht.
Es geht immer: Anfordeurng->warten->Acknowledge
Ist zwar hier mit Polling gelöst, aber ist das prinzipiell falsch?
> aber ist das prinzipiell falsch?
Ich finde ja.
Ein Programmpaket, welches nur funktioniert, wenn sich beide so gut
verstehen wie es die eng verzahnten und aufeinander wartenden Prozesse
für ihre fehlerfreie Abarbeitung verlangen, ist meiner Meinung nach
komplett lebensuntauglich.
Eine serielle Kommunikation muß
1. damit zurecht kommen, daß nicht die erwarteten Zeichen kommen und
sich dabei dann resynchronisieren
2. damit zurecht kommen, daß überhaupt kein Zeichen kommt, also einen
TimeOut besitzen.
Deine Delimiter (immer das A) machen es natürlich besonders schwierig,
eine fehlerhafte Kommunikation zu erkennen. Es sollten zumindest nicht
die Buchstaben sein, die wohl auch im Namensfeld erlaubt sind.
Ein loop until NewReceive=true ist doch ein deadlock. Kabel ab Prozessor
steht.
Die ISR sollte jedes Zeichen entgegennehmen und auf Grund des aktuellen
Zustandes dorthin verteilen, wo es hingehört, und wenn das Zeichen dort
nicht hingehört, dann sollte der Zustand auf das geändert werden, wo es
hingehört, also eine Resynchronisation stattfinden.
Gut, vielleicht zur Erklärung warum ich hier den "bequemen" weg nehme:
Dieser Modus des Gerätes dient eigentlich NUR dem übertragen der
PResets. Im Normalbetrieb wird der UART als MIDI-Schnittstelle benutzt,
inklusive Statemachine und allem drum und dran.
Ich dachte mir nur "die paar Hundert Bytes sollten doch auch so gehen".
Wenn bei den 10 Sekunden übertragung dann halt mal das Kabel rausrutscht
steht die Kiste halt, das würde ich in dem Fall als hinnehmbar
akzeptieren.
Nur so als Info für die Nachwelt:
Schuld war natürlich jetzt die pure Dummheit.
Ein einzelnes Zeichen als Delimiter zu verweden mag ja gehen wenn man
ausschliesslich mit Ascii-Zeichen arbeitet und auf Sonderzeichen
verzichen kann. In meinem Fall | (Pipe)
Blöd nur wenn mitten im String auch mal beliebige Relais-Setups
übertragen werden, bei denen sich durchaus auch mal eine Paarung mit dem
Wert 124 ergeben kann.
Manchmal würde man sich dann gerne selber hauen....
