Warteschleife. Com mit 2400bit/s

[Flashbanger]

Hallo

ich will ein an der RS232 angeschlossenes Gerät ansprechen. Dazu will ich Synaser benutzen. Klappt auch.

Doch nun die einschränkungen. Das gerät arbeitet nur 2400bit/s. So wenn jetzt die befehle schnell auf einander folgen, dann werden sie quasi ins Lehre gesendet. Das Gerät ignoriert sie dann. Um dem PC zu zeigen, dass es bereit ist setzt es CTS auf High.

So nun kann ich natürlich einen CTS-Check machen und nur senden, wenn CTS=true;

so das würde zwar dafür sorgen, dass die Befehle nur gesendet werden, wenn das Gerät sie auch empfangen kann, aber wenn CTS low ist, dann wird der befehl ja einfach nicht gesendet. Damit bin ich nicht einverstanden. Er soll gesendet werden, sobald CTS wieder high ist. Und wenn dann quasi die Warteschleife zu voll wird, dann soll ein Error ausgegeben werden.

So gibt es bei Synaser ein Event, das ausgelöst wird, wenn CTS high ist(oder wenn CTS seinen Zustand wechselt)
Ich möchte nur ungern mit Threats arbeiten.

1. Weil ich keine Ahnung habe.
2. Weil der Code später auch auf lahmen kisten mit mehreren Geräten gleichzeit laufen soll.

Gruß Flashbanger

[theo]

Funzt es mit OnStatus nicht?

[Christian]

Synaser ist synchron es gibt also keine Events wenn irgendwas eintritt. Du wirst dir also schon nen Thread drumrumkomm

[theo]

Synaser ist synchron es gibt also keine Events wenn irgendwas eintritt. Du wirst dir also schon nen Thread drumrumkomm

Das hatte ich eigentlich auch gedacht.
Aber wie funzt denn der OnStatus mit diesen Werten?

Code: Alles auswählen

Possible status event types for THookSerialStatus
 
    * HR_SerialClose:
    * HR_Connect:
    * HR_CanRead:
    * HR_CanWrite:
    * HR_ReadCount:
    * HR_WriteCount:
    * HR_Wait:

P.S. habe noch nie mit Synaser gearbeitet.

[Christian]

Nein, das OnStatus Event wird nur von anderen metzhoden aufgerufen. Man kann z.b. ne Endlosschleife mit TBlockSocket.CanRead laufen lassen und sobals ein byte empfangen wurde wird ein OnStatus Event mit HR_CanRead aufgerufen. mit if TBlockSocket.Canread then break; würde man in der Schleife das selbe erreichen.

Du kannst dir ohne Threads z.b. so helfen:

Code: Alles auswählen

while True do
  begin
    if TBlockSocket.CTS <> FCTS then
      MyCTSChanged;
    Application.Processmessages;
  end;

Oder das ganze in nen Timer packen.

[Flashbanger]

Naja ein Timer ist denk ich doch zu langsam.

wenn ich mit threats arbeiten will, gibts da vllt einen Threat -Assistenten?

Ach ja. Es soll unter Debian Linux laufen. Aber gern auch mal für Windows kompiliert werden können.

Gruß Flashbanger

[theo]

wenn ich mit threats arbeiten will, gibts da vllt einen Threat -Assistenten?

Ich denke du gehst da mit einer allzu negativen Einstellung ran.
engl. Threat = Bedrohung
engl. Thread = Faden

Kleiner Scherz

Thread Assistent gibt es meines Wissens nicht.
Ob ein Timer zu langsam ist, hängt von der Anwendung ab. Einfach wär's allerdings.

[Christian]

Also das n Timer zu langsam ist kann ich mir nicht vorstellen den bekommst ja bis ca 20 ms Auflösung hin zwar nicht sicher, ich kenne aber Kein Gerät für das, das nicht reichen würde. Es sei denn du willst ne Laser Shutterblende steuern oder ähnliches sicherheitskritisches das macht man aber normalerweise auch nicht über die Serielle Schnittstelle.

Bei einem Thread musst du minimal eine Methode überschreiben, ich denke das bekommt man auch ohne Assistenten hin.

[_Bernd]

Doch nun die einschränkungen. Das gerät arbeitet nur 2400bit/s. So wenn jetzt die befehle schnell auf einander folgen, dann werden sie quasi ins Lehre gesendet. Das Gerät ignoriert sie dann. Um dem PC zu zeigen, dass es bereit ist setzt es CTS auf High.

Um das sogenannte Handshake (Flowcontrol) muß man sich unter Windows/Linux nicht selber kümmern. Das macht das Betriebssystem. Eingestellt wird das über die termios Struktur unter Linux und über den DCB unter Windows.

Gruß, Bernd.

[Flashbanger]

Das mag sein, aber das Gerät stellt mit der CTS leitung noch etwas anders dar.

Es handelt sich übrigens um ein Märklin 6050 Modellbahn Interface. Dies signalisiert durch CTS=high, das es entweder grad nichts empfangen kann oder das ein Kurzschluss vorliegt.

Man muss also auch die Zeit messen, die CTS = high ist. Wenn CTS nur 300ms high ist, dann liegt kein Kurzschluss vor. Wenn aber länger, dann handelt es sich um einen Kurzschluss.

So das wäre das eine. Das Andere wäre, das der handshake doch in beide Richtungen funktionieren muss, oder?

Also der PC muss auch dem interface was anzeigen oder. Da gabs doch meines Wissens eine DTR (DataTerminal-ready) Leitung oder?

Das problem ist ,dass diese Leitung nicht beschaltet ist.

Das Kabel sieht nähmlich so aus.

TXD
CTS
RxD
GND

mehr ist nicht angeschlossen.

So weit ich weis, hat mein Bruder ein Paar Leitungen gebrückt. Im Handbuch stand das man das machen kann aber nicht muss.

Kann man das Handshake denn umschalten? Also das davon ausgegangen wird, das Der PC immer bereit ist zu empfangen.

Gruß Flashbanger

[Christian]

Die Handshake leitungen haben eine feste bedeutung. Umschalten kannst da nix.