RS232 Hardware-Flußkontrolle auf Software-Flußkontrolle

[Dschen Reinecke (Laptop)]

Hallo!

Ich suche einen Wandler von RS232-Hardware-Flußkontrolle auf
Software-Flußkontrolle. Dabei spielt es keine Rolle, ob dies auf
TTL-Pegeln oder Rs232-Pegeln passiert. Gibt es dafür irgendwas fertiges,
oder brauche ich einen ľC?

Hat jemand genauere Infos, über beide Protokoll-Versionen, also welchen
mit denen ich dies im Zweifelsfall implementieren kann.

Ciao Dschen

 

[Olaf Kaluza]

Dschen Reinecke (Laptop) <mail@dschen.de> wrote:

TTL-Pegeln oder Rs232-Pegeln passiert. Gibt es dafür irgendwas fertiges,
oder brauche ich einen ľC?

Du brauchst auf jeden Fall einen Prozessor. Bedenke bitte
Softwareprotokol bedeutet eigentlich das dir zwei Bytes fuer das
Handshake verloren gehen und die duerfen dann nicht mehr in den Daten
vorkommen. Mit anderen Worten die muss der Prozessor dann durch zwei
andere Bytes ersetzen. Mit anderen Worten du brauchst eine schnellere
Datenuebertragung wenn dies nach aussen transparent sein soll.

Hat jemand genauere Infos, über beide Protokoll-Versionen, also welchen
mit denen ich dies im Zweifelsfall implementieren kann.

Es gibt da eigentlich nicht DAS protokoll. Es waere z.B denkbar das du
die uebertragenden Daten die du versenden moechtest mal genau
analysiert. Vielleicht findest du ja zwei Bytes die nie verwendet
werden. Dann koenntest du dir dein Leben erheblich vereinfachen.

Olaf

--
D.i.e.s.S. (K.)

 

[Rafael Deliano]

Hat jemand genauere Infos, über beide Protokoll-Versionen, also welchen
mit denen ich dies im Zweifelsfall implementieren kann.
http://www.embeddedFORTH.de Heft 3

Die Hardwarevariante sind die Handshakeleitungen RTS CTS.
Die Softwarevariante die Steuerzeichen XON XOFF.
Ein Controller mit 2 UARTs wäre als Wandler also ideal.
Da aber eventuell grösserer Buffer auch wünschenswert ist,
eventuell auch ein Controller mit externem Bus für RAM wo
man die 2. UART noch hinklebt.

MfG JRD

 

[Gernot Fink]

In article <3F93F19E.AE5FEC9C@dschen.de>,
"Dschen Reinecke (Laptop)" <mail@dschen.de> writes:

Hallo!
Ich suche einen Wandler von RS232-Hardware-Flußkontrolle auf
Software-Flußkontrolle. Dabei spielt es keine Rolle, ob dies auf
TTL-Pegeln oder Rs232-Pegeln passiert. Gibt es dafür irgendwas fertiges,
oder brauche ich einen ľC?
Hat jemand genauere Infos, über beide Protokoll-Versionen, also welchen> mit denen ich dies im Zweifelsfall implementieren kann.
Ciao Dschen

Das wird gar nicht so einfach. Was bei Hardwareprotokoll über die Pins
CTS/DTR übertragen wird, muß bei Software über 2 Steuerzeichen (Xon/Xoff)
erledigt werden.
Diese beiden Zeichen müssen in den Datenstom eingefügt werden.
Dadurch hast du keine Transparente 7 oder 8bit übertragung mehr,mußt
Steuerzeichen umkodieren und Lücken für die Steuerzeichen erzeugen.

Mit einem Microcontroller mit 2 Seriellen Schnittstellen kann man das
schaffen. Zumindest solange keine Transparente Verbindung nötig
ist.

--
MFG Gernot

 

In <Hn2Aq1.3A2@criseis.ruhr.de> Olaf Kaluza wrote:

Dschen Reinecke (Laptop) <mail@dschen.de> wrote:

TTL-Pegeln oder Rs232-Pegeln passiert. Gibt es dafür irgendwas
fertiges,
oder brauche ich einen ľC?

Du brauchst auf jeden Fall einen Prozessor. Bedenke bitte
Softwareprotokol bedeutet eigentlich das dir zwei Bytes fuer das
Handshake verloren gehen und die duerfen dann nicht mehr in den Daten
vorkommen. Mit anderen Worten die muss der Prozessor dann durch zwei
andere Bytes ersetzen. Mit anderen Worten du brauchst eine schnellere
Datenuebertragung wenn dies nach aussen transparent sein soll.

Hat jemand genauere Infos, über beide Protokoll-Versionen, also
welchen
mit denen ich dies im Zweifelsfall implementieren kann.

Es gibt da eigentlich nicht DAS protokoll. Es waere z.B denkbar das du
die uebertragenden Daten die du versenden moechtest mal genau
analysiert. Vielleicht findest du ja zwei Bytes die nie verwendet
werden. Dann koenntest du dir dein Leben erheblich vereinfachen.

Olaf

.... aber dann hätte er sowieso Bandbreite verschenkt.

Aber an einer kleinen 'Statemachine' wird er wohl nicht vorbei kommen,
ausser:

Warum brauchst Du denn ein HW-Handshake? Wenn Du das Ganze in Software
gießt, dann ist Dein Receiver sowieso immer in Empfangsbereitschaft,
-warum dann nicht Deinem Sender vorgaukeln, dass er senden darf? (Sprich
eine einfache Drahtbrücke löst senderseitg das Handshake-Problem
DSR/CTS).

Henry


--

----------------------------------------------------------------------
snail mail : Henry Koplien \|/
From the Center of Nowhere o(O O)o
---- eMail : Henry@NiKo-Internetpraesenz.de ----ooOo---(_)---oOoo-----

 

[Ulrich Prinz]

Rafael Deliano wrote:

Hat jemand genauere Infos, über beide Protokoll-Versionen, also welchen
mit denen ich dies im Zweifelsfall implementieren kann.

http://www.embeddedFORTH.de Heft 3
Die Hardwarevariante sind die Handshakeleitungen RTS CTS.
Die Softwarevariante die Steuerzeichen XON XOFF.
Ein Controller mit 2 UARTs wäre als Wandler also ideal.
Da aber eventuell grösserer Buffer auch wünschenswert ist,
eventuell auch ein Controller mit externem Bus für RAM wo
man die 2. UART noch hinklebt.

MfG JRD

Ein größerer Puffer ist nicht nötig, da beide Seiten der Strecke über
Flußkontrolle verfügen. Daher kann der uC die RTS/CTS Strecke ausbremsen
um das STX/ETX dazwischen zu schieben.
Eventuell muss aber eine Codewandlung vorgenommen werden, um das bereits
genannt Byte-Problem zu lösen. (STX,ETX und einige andere Bytes dürfen
ja nicht mehr vorkommen.) Dazu bitte nachsehen, welches
Übertragungsprotokoll die RTS/CTS-Strecke schon verwendet. Bei reinen
Tex-Übertragungen können diese Zeichen ja eh nicht vorkommen. Bei
Datenstrecken muß das Protokoll geändert werden.
Bis 19200Baud reicht der kleinste AVR mit einer Seriellen aus um eine
zweite Serielle in Software auch Full-Duplex zu emulieren. Das habe ich
jedenfalls so am laufen um ein Siemens 14-Bit Protokoll auf 8-Bit
seriell zu übersetzen. Die 14-Bit Schnittstelle ist komplett in Software
gelöst und eine kleine Code-Umwandlung und CRC-Prüfung findet ebenfalls
noch statt.

Gruß,

Ulrich

 

[Ulrich Prinz]

Gernot Fink wrote:

In article <3F93F19E.AE5FEC9C@dschen.de>,
"Dschen Reinecke (Laptop)" <mail@dschen.de> writes:

Hallo!
Ich suche einen Wandler von RS232-Hardware-Flußkontrolle auf
Software-Flußkontrolle. Dabei spielt es keine Rolle, ob dies auf
TTL-Pegeln oder Rs232-Pegeln passiert. Gibt es dafür irgendwas fertiges,
oder brauche ich einen ľC?
Hat jemand genauere Infos, über beide Protokoll-Versionen, also welchen> mit denen ich dies im Zweifelsfall implementieren kann.
Ciao Dschen


Das wird gar nicht so einfach. Was bei Hardwareprotokoll über die Pins
CTS/DTR übertragen wird, muß bei Software über 2 Steuerzeichen (Xon/Xoff)
erledigt werden.
Diese beiden Zeichen müssen in den Datenstom eingefügt werden.
Dadurch hast du keine Transparente 7 oder 8bit übertragung mehr,mußt
Steuerzeichen umkodieren und Lücken für die Steuerzeichen erzeugen.

Mit einem Microcontroller mit 2 Seriellen Schnittstellen kann man das
schaffen. Zumindest solange keine Transparente Verbindung nötig
ist.

Dschen sollte uns auf jeden Fall mal verraten, ob Daten oder nur Text
übertragen wird. Wenn Daten, dann müssen wir wissen, ob diese die
kritischen Zeichen enthalten können oder nicht. Wenn ja, dann muss er
sich klar sein, dass er auch Zugriff auf das Zielsystem mit dem
Software-Handshake haben muss um dort eine Codewandlung durchzuführen.
Damit kann die Umsetzbox den Datenstrom auf STX/ETX anpassen und das
Zielsystem dekodiert das ganze wieder.

Ich vermute aber mal, dass er für die Übertragung RTS/CTS braucht, aber
nur drei Adern zur Verfügung hat (RXD, TXD und GND). Damit müßte er nur
zwei Boxen bauen, eine als Encoder schalten, eine als Decoder. Die
Übertragung kann vollständig transparent laufen, wenn man 9-Bit für die
Übertragung verwendet, das Bit 9 ist einfach der Zustand von RTS, resp. CTS.

Oder er möchet eine auf STX/ETX basierende Hardware an etwas schalten,
dass nur RTS/CTS kann, dann hat er kein Problem, weil der Host ja der
langsame ist und das Protokoll bereits mit STX/ETX funktioniert. Dann
kann die Kiste sehr einfach realisiert werden.

Fragen über Fragen...

Gruß

Ulrich

 

[Dschen Reinecke (Laptop)]

Ulrich Prinz schrieb:

Ich suche einen Wandler von RS232-Hardware-Flußkontrolle auf
Software-Flußkontrolle. Dabei spielt es keine Rolle, ob dies auf
TTL-Pegeln oder Rs232-Pegeln passiert. Gibt es dafür irgendwas fertiges,
oder brauche ich einen ľC?

Ich vermute aber mal, dass er für die Übertragung RTS/CTS braucht, aber
nur drei Adern zur Verfügung hat (RXD, TXD und GND). Damit müßte er nur
zwei Boxen bauen, eine als Encoder schalten, eine als Decoder. Die
Übertragung kann vollständig transparent laufen, wenn man 9-Bit für die
Übertragung verwendet, das Bit 9 ist einfach der Zustand von RTS, resp. CTS.

Leider nicht.

Ich habe eine Datenstrecke, die Hardware-Handshake nutzt. Ob verbotene
Zeichen vorkommen weiß ich noch nicht.

Leider ist sowohl die Client-Software nicht erreich- und änderbar, als
auch die PC-Software ist uralt und soll nicht geändert werden.

Es geht darum an das Client-Gerät um einen Infrarotanschluß zu erweitern
(so wie einen RS232 mit Software-Handshake). Dieser ist intelligent und
wandelt mir das IrDA-Protokoll in ein RS232 mit Software-Handshake. Dazu
wird ein schon entwickelter automatischer Umschalter dazwischen
geschaltet, der den Client auf den aktiven Eingang (also bestehender PC,
den Infrarotport oder auch einen RS232-Port mit Software-Handshake). Da
die Wandlung von Software auf Hardware muß am Ausgang immer erfolgen, da
der Umschalter kein Hardware-Handshake unterstützt. An einem Eingang
(dem vom PC kommend) muß immer eine Wandlung von Hardware auf Software
erfolgen.

Die Reihenfolge der Wandlung ist natürlich Quatsch, denn die Wandlung
muß ja immer in beide Richtungen erfolgen.

Wenn ich einen ľC verwenden muß, dann würde ich in diesen auch die
Umschaltung integrieren.

Oder er möchet eine auf STX/ETX basierende Hardware an etwas schalten,
dass nur RTS/CTS kann, dann hat er kein Problem, weil der Host ja der
langsame ist und das Protokoll bereits mit STX/ETX funktioniert. Dann
kann die Kiste sehr einfach realisiert werden.

Das ist mir leider nicht klar. Da ich nicht Zugriff auf das Client-Gerät
und auf den PC-Quellcode habe, muß ich dies noch klären.

Ciao Dschen

 

[Ulrich Prinz]

Dschen Reinecke (Laptop) wrote:

Ulrich Prinz schrieb:


Ich suche einen Wandler von RS232-Hardware-Flußkontrolle auf
Software-Flußkontrolle. Dabei spielt es keine Rolle, ob dies auf
TTL-Pegeln oder Rs232-Pegeln passiert. Gibt es dafür irgendwas fertiges,
oder brauche ich einen ľC?


Ich vermute aber mal, dass er für die Übertragung RTS/CTS braucht, aber
nur drei Adern zur Verfügung hat (RXD, TXD und GND). Damit müßte er nur
zwei Boxen bauen, eine als Encoder schalten, eine als Decoder. Die
Übertragung kann vollständig transparent laufen, wenn man 9-Bit für die
Übertragung verwendet, das Bit 9 ist einfach der Zustand von RTS, resp. CTS.


Leider nicht.

Ich habe eine Datenstrecke, die Hardware-Handshake nutzt. Ob verbotene
Zeichen vorkommen weiß ich noch nicht.

Das wäre wichtig herauszufinden.

Leider ist sowohl die Client-Software nicht erreich- und änderbar, als
auch die PC-Software ist uralt und soll nicht geändert werden.

Es geht darum an das Client-Gerät um einen Infrarotanschluß zu erweitern
(so wie einen RS232 mit Software-Handshake). Dieser ist intelligent und
wandelt mir das IrDA-Protokoll in ein RS232 mit Software-Handshake. Dazu
wird ein schon entwickelter automatischer Umschalter dazwischen
geschaltet, der den Client auf den aktiven Eingang (also bestehender PC,
den Infrarotport oder auch einen RS232-Port mit Software-Handshake). Da
die Wandlung von Software auf Hardware muß am Ausgang immer erfolgen, da
der Umschalter kein Hardware-Handshake unterstützt. An einem Eingang
(dem vom PC kommend) muß immer eine Wandlung von Hardware auf Software
erfolgen.

Moment, also Du hast eine bestehende Hardware-Handshake Strecke, die nun
auf einen IrDa Port geschaltet werden soll. (Welche der beiden Seiten
ist ja egal.) Dann ist meine Frage jetzt nur noch, ob der IrDa Zweig von
Dir selbst in seinem Protokoll, vor allem der Geschwindigkeit beeinflußt
werden kann. Wenn ja, dann hast Du kein Problem, denn wenn Du die Daten
schnell genug abholen / verarbeiten kannst, dann brauchst Du kein
Handshake. Wenn doch, dann stell die IrDa Verbindung immer auf die
nächst höhere Geschwindikeit im Vergleich zur Hardware-Handshake Strecke
ein. Dann paßt das STX/ETX immer noch dazwischen.
Wie immer gibt es dabei auch eine Falle: Entweder sendest Du jedes Paket
verzögert, damit der Controller nicht puffern muß, oder du mußt in
Erfahrung bringen, wie groß ein übliches Datenpaket in der Übertragung
ist, und der Controller muß puffern.

Die Reihenfolge der Wandlung ist natürlich Quatsch, denn die Wandlung
muß ja immer in beide Richtungen erfolgen.

Jep!

Wenn ich einen ľC verwenden muß, dann würde ich in diesen auch die
Umschaltung integrieren.

Logisch. Was nicht weiter sschwer wäre, da man vom Controller aus bei
einem Software-UART einfach andere Pinne für RX/TX verwenden kann. An
einem Pärchen hängt der eine Hardware-Port, an einem Anderen das IrDa-Modul.

Oder er möchet eine auf STX/ETX basierende Hardware an etwas schalten,
dass nur RTS/CTS kann, dann hat er kein Problem, weil der Host ja der
langsame ist und das Protokoll bereits mit STX/ETX funktioniert. Dann
kann die Kiste sehr einfach realisiert werden.


Das ist mir leider nicht klar. Da ich nicht Zugriff auf das Client-Gerät
und auf den PC-Quellcode habe, muß ich dies noch klären.

Es wäre wirklich wichtig die Art der Daten zu klären. Eventuell wird da
ohne Dein Wissen schon ein einfaches Handshke-Protokoll verwendet.
Gerade wenn das alles so alt ist, kann es gut sein, dass die Streck
half-Duplex ist und immer nur einer auf Anforderung durch den Anderen
sendet. Damit ist es dann kinderleicht STX/ETX um die Datenpakete zu
legen und das ganze per IrDa zu verdsenden. Dazu muß der Controller nur
mithören und eventuell mitzählen oder bestimmte Sequenzen erkennen.

Sonst klemm doch einfach mal einen Monitor in die Datenstrecke und
lausche mit. Mit etwas Glück läßt sich daran schon was sinnvolles
erkennen. Solche Monitore kann man mit einem PC mit zwei seriellen
Ports, einer Kabelpeitsche aus Bastelkram und diverser im Internet
verfügbarer Software schnell selber zuwege bringen. Der Eine port liest
die TX-Strecke, der andere die RX mit.

Gruß,

Ulrich

 

[Jochen Tanneberger]

Dschen Reinecke (Laptop) <mail@dschen.de> schrieb in im Newsbeitrag:
3F93F19E.AE5FEC9C@dschen.de...
Hallo!

Ich suche einen Wandler von RS232-Hardware-Flußkontrolle auf
Software-Flußkontrolle. Dabei spielt es keine Rolle, ob dies auf
TTL-Pegeln oder Rs232-Pegeln passiert. Gibt es dafür irgendwas fertiges,
oder brauche ich einen ľC?

Hat jemand genauere Infos, über beide Protokoll-Versionen, also welchen
mit denen ich dies im Zweifelsfall implementieren kann.

Ciao Dschen

Hallo Dschen,

ich bin zur Zeit bei diesen Schnittstellen noch an Erfahrung zu sammeln. ET
3. Semester. Ich habe so einen Wandler bisher noch nicht kennen gelernt.
Aber ich denke, dass es nur mit einer ľC-Lösung gehen dürfte. Ein Terminal
soll es, so wie ich hieraus zu erkennen vermag, ja nicht sein? Die
Hardwarekontrolle liegt im Prinzip als Pegelinformation an den
Schnittstelleleitungen an: S1/108 oder M???, aber schlag mich jetzt nicht,
wenn sie nicht genau so heisen. Kann man nachlesen. Aber sie liegen als
Pegel an. Die Softwarekontrolle wird durch Bitkombinationen im Nutzband in
den entsprechenden Informationsheadern des Rahmenpakets übermittelt. Ich
will jetzt mal über Offsets und Statusbits, keine Sprüche schwingen, ich
muss darüber selber noch sehr viel lernen. Aber mir wird hierbei sehr
schnell deutlich, dass man ähnlich, wie es ein Router macht, eine Bewertung
des Datensitromes vornehmen muss. Und dabei muss man in Betracht ziehen,
nach welchem Ünertragungsverfahren ein Trägersignal konzipiert ist. Was
vielleicht noch rein hardwaremäßig machbar sein dürfte, ist die
Informationspegel der Hardwareflusskontrolle an den Schnittstellen
herauszulesen und durch entsprechende Logikschaltungen als Bitkombinationen
in den Datenstrom zu filtern. Dabei stellt sich dann die Frage, ob gerade
jetzt der Rahmen gebildet wird oder ob sie in den Informationsheader eines
bestehenden Rahmens eingefiltert werden müssen. Und da spätestens im
umgekehrten Fall, müssen die Bitinformationen der Softwarekontrolle
herausgefiltert werden und als einfache Pegel an die Schnittstellenleitungen
gelegt werden. Wie soll dass durch eine reine Logikschaltung realisiert
werden? Das Datensignal muss ja untersucht werden, wo das entsprechende Bit
zu suchen ist. Wenn dann noch das ganze OSI-Referenzmodell beachtet wird,
können ja Rahmenpakete über Rahmenpakete geschichtet sein. Eine
Hardwarelösung auch für diesen Fall, stelle ich mir nur vor, wenn das
Übertragungsverfahren genau feststeht. Aber vielleicht werde ich eines
besseren belehrt und jemand postet uns etwas hier hinein.

 

[Ulrich Prinz]

Jochen Tanneberger wrote:

[...]

ich bin zur Zeit bei diesen Schnittstellen noch an Erfahrung zu sammeln. ET
3. Semester. Ich habe so einen Wandler bisher noch nicht kennen gelernt.
Aber ich denke, dass es nur mit einer ľC-Lösung gehen dürfte. Ein Terminal
soll es, so wie ich hieraus zu erkennen vermag, ja nicht sein? Die
Hardwarekontrolle liegt im Prinzip als Pegelinformation an den
Schnittstelleleitungen an: S1/108 oder M???, aber schlag mich jetzt nicht,
wenn sie nicht genau so heisen. Kann man nachlesen. Aber sie liegen als
Pegel an. Die Softwarekontrolle wird durch Bitkombinationen im Nutzband in
den entsprechenden Informationsheadern des Rahmenpakets übermittelt. Ich

Hä?
Ein Rahmenpaket, wie die Header/Footer-Kombination eines IP-Paketes
wirst Du in einem, seriellen Datenstrom selten antreffen, wenn da nicht
gerade PPP gefahren wird. Natürlich gibt es auch andere serielle
Protokolle, die ein, wie auch immer geartetes, Framing verwenden.
Aber meist ist es so, dass der Empfänger über RTS/CTS dem Sender einfach
nur klar machen will, dass er nahe einem Überlauf ist, und der Sender
doch bitte warten möchte, bis er die bisher eingetrudelten Pakete
verarbeitet hat. Dies kann zu jeder Zeit in einem laufenden Datenstrom
geschehen. Also kein Framing, kein Punkt, an dem man aus dem laufenden
Datenstrom erkennen kann, wann ein STX oder ETX passen würde.

will jetzt mal über Offsets und Statusbits, keine Sprüche schwingen, ich
muss darüber selber noch sehr viel lernen. Aber mir wird hierbei sehr
schnell deutlich, dass man ähnlich, wie es ein Router macht, eine Bewertung
des Datensitromes vornehmen muss. Und dabei muss man in Betracht ziehen,
nach welchem Ünertragungsverfahren ein Trägersignal konzipiert ist. Was
vielleicht noch rein hardwaremäßig machbar sein dürfte, ist die
Informationspegel der Hardwareflusskontrolle an den Schnittstellen
herauszulesen und durch entsprechende Logikschaltungen als Bitkombinationen
in den Datenstrom zu filtern.

Das Problem ist doch, dass Dschen das, weil er das Datenformat weder
kennt, noch beeinflussen kann, absolut transparent machen muss. Er kann
also weder denm Datenstrom bewerten, noch, in diesem Fall sowieso nicht
vorhandene, Bits ausfiltern. Er muß einfach die IrDa Strecke schneller
als die Hardware-Handshake Strecke machen, um bei wechsel von RTS ein
STX resp. ETX einzufügen. Dazu muß er aber sicher sein, dass im
Datenstrom kein STX/ETX als Date vorkommen kann. Um das herauszufinden,
muss er den Datenstrom aber kennen, und das tut er nicht.
Wenn es eine Terminal-Strecke wäre, hätte er das Problem nicht, denn
dann wäre gesichert, dass die Zeichen <20h Steuerzeichen wären und keine
Daten.

Dabei stellt sich dann die Frage, ob gerade

jetzt der Rahmen gebildet wird oder ob sie in den Informationsheader eines
bestehenden Rahmens eingefiltert werden müssen. Und da spätestens im
umgekehrten Fall, müssen die Bitinformationen der Softwarekontrolle
herausgefiltert werden und als einfache Pegel an die Schnittstellenleitungen
gelegt werden. Wie soll dass durch eine reine Logikschaltung realisiert
werden?

Durch ein kleines CPLD kann das jederzeit auch in reiner Hardware
gemacht werden. Für den Empfänger einen 8-Bit Vergleicher auf STX/ETX
und bei Gleicheit den RTS Pegel ändern. Beim Sender würde bei fallendem
CTS einfach ein ETX hinten angehangen, da pssiert nix, weil der Sender
eh schweigt. Bei steigender Flanke ein STX vorweg schicken und selber
das RTS erst danach hochziehen. Damit ist die nötge Verzögerung um ein
Byte geschehen.

Das Datensignal muss ja untersucht werden, wo das entsprechende Bit

zu suchen ist. Wenn dann noch das ganze OSI-Referenzmodell beachtet wird,
können ja Rahmenpakete über Rahmenpakete geschichtet sein. Eine
Hardwarelösung auch für diesen Fall, stelle ich mir nur vor, wenn das
Übertragungsverfahren genau feststeht. Aber vielleicht werde ich eines
besseren belehrt und jemand postet uns etwas hier hinein.

Eine Bewertung auf eine OSI-Nähe des verwendeten Datenstromes kann nur
bei Kenntnis des Datenstromes erfolgen. Haben wir nicht. Damit ist das
Problem also im Physical Layer anzusiedeln

Nur mal so als Tip:

Das Studium vermittelt Dir eine Übersicht und viel Theorie über komplexe
Zusammenhänge. Vergesse aber nie, dass man immer ersteinmal den
Bleistift und ein Papier braucht um sich die oft einfachen Zusammenhänge
auf einem Blatt zu malen, bevor man eine Computersimulation auf einer
Cray anwirft.

Also:

RTS fällt, weil Empfänger nicht mehr kann. Box nimmt ebenfals RTS zurück
und sendet ans Ziel ein ETX.
Wenn das RTS wieder kommt, lässt Sie das eigene RTS noch unten und
sendet ersteinmal ein STX und setzt erst dann das eigene RTS. Damit ist
die Byte-Lücke, die das STX benötigt geschlossen.
Dann kann der Datenstrom wieder fließen.

Das gilt aber nur, wenn der Datenstrom selbst kein STX/ETX beinhaltet.

Für den Fall, dass Dschen Zugriff auf die IrDa-Applikation hat, kann er
auch einfach von 8-Bit auf 9-Bit übersetzen. Das Bit 9 ist dann der
Status von RTS/CTS.
Wenn der Datenstrom wirklich Binärdaten beinhaltet, kann er in der Box
auch ein UUEncode durchführen und die Daten per UUDecode auf der
IrDa-Applikation wieder dekodieren. Damit muss aber die IrDa Strecke
eine fast doppelt so hohe Übertragungsrate haben, wie die Hardware-Strecke.

Um die Datenpakete langsamer aber in Rahmen mit kontrolliertem Anfang
und Ende zu übertragen, kann er auch eine RLE-Kompression einbauen, wozu
ein ATMEL allemal schnell genug ist. Damit erhält er auf einen Schlag
viele Vorteile:
- Daten komprimiert = langsamere IrDa Übertragung = höhere Reichweite
- Daten in Frames = Kontrolle über was sind Daten, was ist STX/ETX
- Durch einfache CRC der RLE-Frames ist die Übertragung gesichert.

Das alles sind Möglichkeiten, die sich aber nur dann ergeben, wenn
Kenntnis des Datenstromes und Zugriff auf mind. die IrDa-Seitige
Applikation besteht.

So, damit ist sogar ein wenig das OSI-Modell anwendbar, weil wir
plötzlich Rahmen haben. Aber es hilft alles nichts, zuerst muss Dschen
entwede den Entwickler der laufenden Software dazu überreden das
Protokoll freizugeben, oder er muss mit einerm Tracer mal nachsehen, was
Sache ist.

Gruß,

Ulrich

 

[Dschen Reinecke (Laptop)]

Danke Euch allen!

Ich habe die Entwicklung dafür aufgegeben. Es gibt mir zu viele
Unsicherheiten und meine Zeit gibt es momentan nicht her da alles
auszupobieren.

Es ist also nicht mehr nötig sich darüber Gedanken zu machen. Jedenfalls
benötige ich diese nicht mehr

Ciao Dschen

--

Dschen Reinecke
Computer, Elektronik und Telekommunikation - Handel und Service

Thedinghauser Str. 83
28201 Bremen
fon 0421 594222
genion 0421 8966514
fax 0421 594220
mobil 0179 5349990
http://WWW.DSCHEN.DE und http://WWW.INFRAROTPORT.DE

 

[Dschen Reinecke (Laptop)]

Danke Euch allen!

Ich habe die Entwicklung dafür aufgegeben. Es gibt mir zu viele
Unsicherheiten und meine Zeit gibt es momentan nicht her da alles
auszupobieren.

Es ist also nicht mehr nötig sich darüber Gedanken zu machen. Jedenfalls
benötige ich diese nicht mehr

Ciao Dschen

PS: Wer schnell war, hat dieses Post auch mit meinem Mail-Footer, diesen
wollte ich aus den Werbungs-Grund nicht in den News nutzen, habe mich
aber vertan.