Frage zu SerialNG / Ansteuerung TxD an COM-PORT

[Muetze1]

Zitat:

Zitat von runger

Zitat:

Wahrscheinlich handelt es sich also nicht um eine synchrone Übertragung, sondern um eine in einem festen Zeitraster - das ist aber bei asynchron genauso der Fall, die Zeit für 1 Bit hängt direkt von der Baudrate ab (bei 9600 Baud also 104 µsec pro bit).

Und was machst du mit den Pausen zwischen den Bytes?
Diese Aussage kannst du vergessen. Sie ist schlichtweg falsch!

Bedingt. Bei keinem Stopp-Bit und keinem Parity, etc wäre die Aussage richtig.

@other: Ich steuer ein solches Schieberegister (LS145) über einen Controller an und habe zuvor zum Test einfach an den Parallelport gehangen. Dort ein Pin als Takt wackeln zu lassen und entsprechend ein anderes Pin mit einem Datenbit zu belegen ist nun wirklich kein Problem.

[Der_Unwissende]

Zitat:

Zitat von texmurphy901

Hatte nur gehofft, es geht, da ja SerialNG angeblich auch zur synchronen Kommunikation verwendet werden kann...

Möchte dazu nochmal kurz etwas loswerden. Synchrone Kommunikation hat nichts mit irgendeinem Takt zu tun. Natürlich kann man über eine asynchrone Schnittstelle synchron Kommunizieren. Synchron Kommunizieren heißt nur, dass man eine Antwort zu einer Anfrage bekommt. Bei vielen Komponenten für die Kommunikation über RS-232 wird man sich selbst um das Warten auf Antwort kümmern müssen, wenn die hier einfach den Prozess schlafen legen, bis eine Antwort kommt, dann erfüllen die schon was die gesagt haben.

Gruß Der Unwissende

[texmurphy901]

Hallo allerseits noch einmal,

da die Diskussion etwas von dem eigentlichen Thema abzuschweifen scheint, möchte ich mein problem nochmal kurz zusammenfassen:

Weiß jemand, ob bzw. wie ich mit der SerialNG - Komponente (oder einer anderen, wenn es da geht)
synchron ein Byte übertragen kann.
Es würde mir auch helfen, wenn jemand weiß, wie ich für ein paar Milisekunden TxD setzen kann.
SerialNG unterstützt nur das Senden von Strings (bzw. über zeiger das Senden beliebiger Daten) , soweit ich bisher herausgefunden habe.

Es gab vor Jahren einmal eine serielle Unit von Jörg Schieb, da ging das ganz einfach: TxD(1) Schaltet ein, TxD(0) schaltet ab etc...
allerdings ist mit dieser Unit nicht möglich, mehrere COM gleichzeitig anzusprechen, was ich leider muss.
Außerdem ist der interessante Code in einer DLL abgelegt, so dass ich auch mit "reverse engineering" nichts werden kann :-(

/* Hilfe */

Murphy

[OldGrumpy]

Du hast die letzten Posts anscheinend nicht gelesen - oder nicht verstanden. *sigh*

[texmurphy901]

gelesen:ja verstanden: nicht wirklich
Bin eben kein Techniker sondern nur ein armer Programmeirer....

Murphy

[Der_Unwissende]

Zitat:

Zitat von texmurphy901

gelesen:ja verstanden: nicht wirklich

Ok, dann nochmal zusammenfassend (und hoffentlich vereinfacht), das was du meinst ist nicht möglich!
Synchron sollte einem Programmierer ein Begriff sein (ein Techniker muss das nicht interessieren). Der Aufruf einer Prozedur in deinen Programmen erfolgt für dich synchron. Du rufst die Prozedur auf und wartest, bis die abgearbeitet ist. Die Abarbeitung geht dabei an einer anderen Stelle weiter, trotzdem wartet das Programm, bis die Prozedur zuende abgearbeitet wurde.
Synchrone Kommunikation funktioniert ganz einfach so, dass du eine Anfrage stellst und auf eine Antwort wartest. Das die RS-232 asynchron arbeitet hat nichts mit der Kommunikation zu tun, die du darauf aufbauen kannst. Verschickst du Daten über die RS-232 Schnittstelle, so ist es einfach Sache des Empfängers irgendwann die Daten zu bearbeiten. Ob du eine Antwort bekommst oder nicht, alles Sache des Empfängers. Du weißt es nicht. Für den Sender ist die Arbeit mit dem Versenden abgeschlossen. Erwartest du eine Antwort, dann musst du das selbst programmieren. Wartest du in deinem Programm auf eine Antwort, dann hast du das Programm synchronisiert (warten auf ein bestimmtes Ereignis).

Du siehst vielleicht schon, Sychron hat nichts damit zu tun, dass du etwas für eine bestimmte Zeit aktiv hälst. Andererseits kannst du auch eine LED schalten, indem du nur schnell genug Impulse schickst. Schaltest du die LED mit einer hohen Frequenz an und aus, dann wird das normale menschliche Auge dank seiner Trägheit nicht wahrnehmen, dass die LED mal nicht an ist.

Gruß Der Unwissende

[OldGrumpy]

Ich hab mal eben kurz in die Specs geschaut, aber die gängigen RS-232 Chips (bzw. deren Nachfahren) kennen anscheinend keine Methode um RXD/TXD gezielt auf einem bestimmten festen Wert zu setzen. Dazu eignen sich viel eher die Handshakeleitungen, die sind nämlich ziemlich gezielt schaltbar. Daher bezweifel ich etwas die Aussage von weiter oben dass das schonmal gegangen sei. Nichtsdestotrotz bleibt mein Kommentar, die Hardware doch bitte mal genauer vorzustellen, auch unbeachtet. Vermutlich ist Dein Problem nämlich eigentlich gar keines. Es fehlt Dir nur an Möglichkeiten, die Problemstellung umfassend zu beschreiben. Du gehst meiner Meinung nach das Problem von der falschen Seite an. Du solltest nicht fragen "ich hab mir das und das zurechtgelegt, wie geht das" sondern einen Schritt früher bereits die Frage stellen "wie löse ich diese Aufgabe". Daher nochmal meine Bitte, näher auf die Hardware einzugehen. Hast Du Dokumentation zur Hardware? Was für Hardware ist das? Ggf. ist einfach die Anbindung an den Rechner das Problem, für so eine LED-Ansteuerung würde ich aus Bequemlichkeit den Printerport nehmen. Wenns denn unbedingt seriell sein soll, gibts aber auch dafür Lösungen. Asynchron/Synchron heisst bei Datenverbindungen einfach nur, ob die Datenübertragung mit einem Taktsignal synchronisiert wird. SCSI kennt zum Beispiel beide Modi, wobei asynchron aufgrund des aufwendigeren Verfahrens deutlich langsamer ist - Wenn beide Seiten über eine Taktleitung synchronisiert werden, sind viel schnellere Transfers möglich.
Daher ist RS-232 eigentlich nicht synchron zu betreiben, das Taktsignal ergibt sich aus dem Busprotokoll und wird nicht separat übertragen. Aber das sind alles nur Details am Rande, worauf ich hinaus wollte, ist eigentlich: Du musst mehr Details liefern und umfangreicher das "grosse" Problem beschreiben, das Detail an dem Du gerade hängst klappt vermutlich nicht, weil Du Dich in eine falsche Sache verrannt hast.