Nullmodem

Lang ist es her - aber ich habe mal einen Treiber dafuer geschrieben und IIRC kann der das gar nicht (weder der 8250 noch der 16550). Aus dem Gedaechnis: Wenn sein RX-Puffer voll ist setzt er nur ein Statusbit plus den Interrupt und den HS-Pin muss dann die CPU togglen. Zu hohe Interruptlatenz (z.B. wegen non-realtime OS) => RX Overflow kann nicht ausgeschlossen werden, egal bei welcher Bitrate.

Micha

Stell dir vor, das weiß ich. Hatte sogar mal das Datenblatt. Aber IBM hat sie ins Gesamtsystem integriert und deswegen sind sie schuldig. Mag sein, das Intel einen blöden Chip entwarf.

- Henry

OK. Stellt sich nun die Frage wie der Chipdesigner sich ein BS vorgestellt hat??? Selbst ein Echtzeitsystem für mittelharte Anwendungsfälle hat hier ein Problem!

- Henry

Der 8250 ist so alt, da hatte man an heutige Einsatzgebiete vmtl. gar nicht gedacht (jedenfalls noch nicht von Windows getraeumt). Und wenn der Murks mal in der Welt ist muss man im PC-Bereich ja _um_jeden_Preis_ kompatibel bleiben. So gab es dann spaeter den 16550 mit FIFO und heute gibts bestimmt auch welche mit noch groesserem FIFO. Das loest das Problem nicht, entschaerft aber die RT-Anforderungen.

Fuer Maeuse und Modems hats gereicht. Gelegentlich mal Datenverlust war bei einer Maus egal und bei einem Modem haben es halt die hoeheren Protokollschichten reparieren muessen. Offenbar war es "gut genug" fuer den Zielmarkt ...

Micha

Nachdem er im originalen PC zu finden war (so man die Karte einbaute), wuerde ich mal auf vor 1982 tippen. U.U. gehoerte er sogar noch zum 8080 und damals waren Gatter teuer.

Gab es, sogar 100% kompatibel zum 16550A, nur mehr Platz im FIFO.

Gerrit

Ist aber nicht einfach bei Datenverlusten - wo setzt Du neu auf, wenn STX/ETX in den Daten selber auftreten kann?

Ethernet ist paketorientiert, und der Empfänger hat immer genug Speicher, um ein Paket komplett am Stück zu empfangen - wenn nicht, gibt es Datensalat.

BTW: aktuelles Ethernet hat durchaus das Äquivalent zu RTS/CTS: das nennt sich "pause frame" - damit kann der MAC die Gegenseite ausbremsen, bis er wieder Platz in seinen Empfangspuffern hat.

cu Michael

Korrekt, der 8250 ist übel - nicht ohne Grund hat es im Laufe der Zeit so viele erweiterte Versionen davon gegeben. Die aktuellen sind sogar recht brauchbar, einziger Nachteil ist das verkorkste Registerlayout - man muß ja zum 8250 voll kompatibel bleiben :-(

cu Michael

Es gibt heute welche, die (optional, man muß ja kompatibel bleiben) RTS/CTS in Hardware können, damit ist das Problem dann 100% gelöst und nicht nur unwahrscheinlicher gemacht.

cu Michael

PPP bzw. (C)SLIP existieren und damit ist das Problem als geloest zu betrachten.

Ist aber nicht zwangslaeufig eingeschaltet. Aktuelle NIC arbeiten per DMA, da solltest du keine Probleme mit dem Puffer haben. :)

Gerrit

Michael Schwingen schrieb:

Wegen Ack/Nak wird das nächste Paket erst nach der Quittung geschickt. Das synchronisiert irgendwann zwangsläufig.

Wegen der dadurch entstehenden Latenzen, arbeitet bspw. ZMODEM(?) nur mit Nak. Der Sender sendet solange volles Rohr, bis der Empfänger ein Nak schickt.

Das wäre aber eher das Äquivalent zu XOFF.

Falk, der schon mal per NFS-Mount via PLIP ein Notebook installiert hat.

Ich hoffe diese Einstellung wird sich nicht allzuweit verbreiten. Wird schon gehen, meistens.

- Henry

Falk Willberg schrieb:

Och, da halte ich mit: Apple MacOS über LocalTalk gezogen. Geht problemlos.

- Henry

Jein: auf MAC-Ebene sind das spezielle Datenmuster, die im normalen Datenstrom nicht vorkommen können - also eben nicht das klassische inband signalling, auch, wenn alles über ein Adernpaar geht.

Dito. Compaq Aero 4/33C - ein PCMCIA-Slot, und da steckt zwangsweise der nicht-hotplugfähige Floppy-Adapter 'drin.

cu Michael

Am 02.07.2008, 02:55 Uhr, schrieb Henry Kiefer :

Die ge-FIFO-ten seriellen Schnittstellen sind seit spätestens der

Ansgar

Diese Eigenschaft hat sich bereits weit verbreitet...

Gerrit