🚀 go-pugleaf

matze@risc.boeblingen.netsurf.de (Mathias Winter) writes:

> Ich habe eine RS485-Schnittstelle, aber ich weis nicht wie ich diese
> dazu bringen kann mit 10 Mbps zu senden.

Warum sollte sie das?  Sie fährt doch ein ganz gewöhnliches async, nur
daß im Unterschied zur RS-232 die Leitungen Differenzsignale über-
tragen.

10 Mbit/s ist Ethernet, das muß man schon bissel was anderes auffahren.

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

On 12 Mar 1996, J Wunsch wrote:

> matze@risc.boeblingen.netsurf.de (Mathias Winter) writes:
> 
> > Ich habe eine RS485-Schnittstelle, aber ich weis nicht wie ich diese
> > dazu bringen kann mit 10 Mbps zu senden.
>  
> 10 Mbit/s ist Ethernet, das muß man schon bissel was anderes auffahren.

Nein, nein 10 Mbit/s sind mit RS485 durchaus machbar. Das sind doch
heute keine Geschwindigkeiten mehr.
 
Helmut
-------------------------------------------------------------------------------
Helmut FAUGEL                       |  Tel.   : +49 / 089 / 3299 2245
Max-Planck-Institut f. Plasmaphysik |  Fax    : +49 / 089 / 3299 2558
Boltzmannstr. 2                     |  E-Mail : faugel@ipp-garching.mpg.de
D-85748 Garching bei Muenchen       | 
Germany                             |          
-------------------------------------------------------------------------------

Helmut Faugel TE wrote:

> Nein, nein 10 Mbit/s sind mit RS485 durchaus machbar. Das sind doch
> heute keine Geschwindigkeiten mehr.

Ich habe da irgenwie das gleiche Problem!
Ich habe mir die RS485 Schnittstelle von ELV gekauft und versuche diese
unter Watcom C anzusteuern.
Das klappt auch alles wunderbar. Mein Problem ist die Geschwindigkeit!
Ich bekomme irgendwie nur maximal 115200 Baud hin. Aber 10Mbit/s sollen
moeglich sein.
Kann mir irgend jemand sagen, was ich an meinem Programm aendern muss?

Vielen Dank im Vorraus!!

e-tricky 

-- 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 My e-mail adress: e-tricky@herrenberg.netsurf.de   
 My Homepage: http://www.shop.de/priv/hp/170

What is physics? Two man in a dark room are
searching for a black cat.
What is religion? Two man in a dark room are
searching for a black cat that isn't where.
What is policy? One of the two shouts: 
'I've got it!'
_________________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

matze@risc.boeblingen.netsurf.de (Mathias Winter) wrote:

>Ich habe eine RS485-Schnittstelle, aber ich weis nicht wie ich diese
>dazu bringen kann mit 10 Mbps zu senden.
>In der 'Anleitung' stand, dass ich die Schnittstelle wie eine normale
>RS232 ansteuern koennte. Das klappt zwar ganz gut, doch bringe ich die
>RS485 lediglich dazu, wie eine RS232, mit maximal 115200 bps zu
>senden.

>Kann mir vielleicht einer sagen, wie ich die Schnittstelle dazu
>bringen kann mit den 10 Mbps zu senden?

Die Normen RS-232 und RS-485 bschreiben die elektrischen Eigenschaften
von zwei Uebertragungsverfahren. RS-232 arbeitet mit Masse-bezogenen
Signalen (1 Ader pro Signal), waehrend RS-485 mit differentiellen
Signalpegeln arbeitet (1 Aderpaar = 2 Adern pro Signal). Durch das
differentielle Verfahren ist die RS-484-Uebertragung erheblich
stoersicherer als RS-232.
Die "offiziellen" Grenzwerte habe ich gerade nicht im Kopf, aber fuer
RS-232 gelten (glaub' ich) max 19200 Bit/s bei max. 12 m
Uebertragungsstrecke; RS-485 liegt bei 1 MBit/s und max. 500 m,
Uebertragungsstrecke ist aber abhaengig von der Geschwindigkeit).

All' dies sagt nur aus, was elektrisch moeglich (!) ist. Das muss man
aber erst ein asynchrones Signal mit dieser Geschwindigkeit erzeugen.
Mit dem Schnittstellenbaustein, der in PCs (und den seriellen Karten)
üblicherweise eingebaut ist, geht das nicht (!), da ist die Obergrenze
tatsaechlich 115200 Bit/s.

Auch die RS-485-Schnittstellenkarten, die ueblicherweise fuer PC's
verkauft werden, koennen max. 115200 Bit/s, da sie den gleichen
Schnittstellenbaustein verwenden, damit sie software-kompatibel sind.

Eine Schnittstellenkarte fuer 1 oder 10 MBit/s erfordert sowieso einen
eigenen Prozessor bzw. Controller (vgl. Netzwerkkarten), da die CPU
des PC's gar nicht in der Lage ist, so schnell die seriellen Zeichen
entgegenzunehmen (10 bzw. 1 Microsekunde pro Zeichen!).

Wenn du eine Uebertragung mit 1 oder 10 MBit/s brauchst, kommst du um
eine echte Netzwerkkarte nicht rum.

Ruediger Kloeckner (RKloeckner@t-online.de)

RKloeckner@t-online.de (Ruediger Kloeckner) writes:

> Auch die RS-485-Schnittstellenkarten, die ueblicherweise fuer PC's
> verkauft werden, koennen max. 115200 Bit/s, da sie den gleichen
> Schnittstellenbaustein verwenden, damit sie software-kompatibel sind.

Das stimmt nicht ganz.  Die meisten der heutzutage darauf eingesetzten
Chips sind für (teilweise erheblich) mehr spezifiziert als die 1.8
MHz, mit denen sie aus Gründen der plug&pray-Kompatibilität zum
8088-PC betrieben werden.  Einige wenige Karten gestatten wohl auch
ein (hartes oder weiches) Umkonfigurieren des Vorteilers.

> Eine Schnittstellenkarte fuer 1 oder 10 MBit/s erfordert sowieso einen
> eigenen Prozessor bzw. Controller (vgl. Netzwerkkarten), da die CPU
> des PC's gar nicht in der Lage ist, so schnell die seriellen Zeichen
> entgegenzunehmen (10 bzw. 1 Microsekunde pro Zeichen!).

Das ist Quatsch.  Dafür gibt es FIFO's, modernere Chips (16650) haben
davon 32 Bytes.  Selbst, wenn man ,,nur'' einen 16550 hat, kann man
den FIFO-Triggerwert auf 14 setzen, wenn nur die Interruptroutine
einigermaßen schnell genug ist.

Einen 386sx/16 lastet man mit etwa 38 k UART-Interrupts je Sekunde aus
(38 kpbs mit 16450), wenn er die Zeichen auch noch verarbeiten soll
;), wenngleich er auch 115 k Interrupts pro Sekunde zumindest noch
annehmen kann, wenn er in der Interruptroutine lediglich CTS
zurücknehmen muß (hardware flow control).  Diese Werte kannste nun auf
einen i586/133 mit 16650 hochrechnen, wenn es Dir Spaß macht. :)
(Obige Werte bezogen sich auf ein Betriebssystem im Multitasking.)

Ich gebe allerdings zu, daß es sinnvollere Methoden gibt, eine CPU
auszulasten.  Allerdings fragt danach sonst auch niemand, siehe IDE
oder AHA-2920.

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

J Wunsch (j@uriah.heep.sax.de) wrote:
> Das ist Quatsch.  Dafür gibt es FIFO's, modernere Chips (16650) haben
> davon 32 Bytes.  Selbst, wenn man ,,nur'' einen 16550 hat, kann man
> den FIFO-Triggerwert auf 14 setzen, wenn nur die Interruptroutine
> einigermaßen schnell genug ist.

Wenn man den FIFO Schwellenwert auf 14 setzt, dann hat man noch 2 Plaetze im
FIFO frei + einen im THR, d.h. die Interruptroutine muss innerhalb von 3us
(bei 10Mb) das erste Zeichen vom UART abgeholt haben. Das ist so gut wie
unmoeglich, selbst wenn keine weiteren Interrupts dazwischenfunken.

> Einen 386sx/16 lastet man mit etwa 38 k UART-Interrupts je Sekunde aus
> (38 kpbs mit 16450), wenn er die Zeichen auch noch verarbeiten soll
[...]
> (Obige Werte bezogen sich auf ein Betriebssystem im Multitasking.)

Dann muss man aber solange die Platte abklemmen :-)
In einem normalen PC hat der Interrupt der Festplatte eine hoehere
Prioritaet als die serielle Schnittstelle, d.h. bei jedem Plattenzugriff
gehen u.U. Zeichen verloren - auch und gerade auf einem Multitasking-BS.

Ich denke, Deine Schaetzungen sind durchweg um mindestens Faktor 2 zu
guenstig angenommen...

Das gilt natuerlich besonders, wenn man in C programmiert, weil man dann den
Overhead der Hochsprache gegenueber Assembler hat (puh, fast waere mir nix
mehr eingefallen, wie ich den Artikel wieder on-topic kriege :-).

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

Ullrich von Bassewitz <uz@ibb.schwaben.com> wrote:

>Wenn man den FIFO Schwellenwert auf 14 setzt, dann hat man noch 2 Plaetze im
>FIFO frei + einen im THR, d.h. die Interruptroutine muss innerhalb von 3us
>(bei 10Mb) das erste Zeichen vom UART abgeholt haben. Das ist so gut wie
>unmoeglich, selbst wenn keine weiteren Interrupts dazwischenfunken.

Hmm.  Heutige Prozessoren werden mit 100 MHz getaktet, und dabei
arbeiten sie teilweise noch parallel.  Das macht 300 Takte, damit
sollte man grundsätzlich die Zeichen puffern können.

Es ist sicher aber nicht das, was man sich unbedingt an Hardware
wünscht, da gebe ich Dir recht.

>> Einen 386sx/16 lastet man mit etwa 38 k UART-Interrupts je Sekunde aus
>> (38 kpbs mit 16450), wenn er die Zeichen auch noch verarbeiten soll
>[...]
>> (Obige Werte bezogen sich auf ein Betriebssystem im Multitasking.)
>
>Dann muss man aber solange die Platte abklemmen :-)

Natürlich nicht.  Im Gegenteil, es handelte sich sogar um eine
schröckliche IDE-Platte, die die CPU vergewaltigt, um die Daten
zu schaufeln.  (Meine letzte übrigens...)

>In einem normalen PC hat der Interrupt der Festplatte eine hoehere
>Prioritaet als die serielle Schnittstelle, d.h. bei jedem Plattenzugriff
>gehen u.U. Zeichen verloren - auch und gerade auf einem Multitasking-BS.
>
>Ich denke, Deine Schaetzungen sind durchweg um mindestens Faktor 2 zu
>guenstig angenommen...
>
>Das gilt natuerlich besonders, wenn man in C programmiert, weil man dann den
>Overhead der Hochsprache gegenueber Assembler hat (puh, fast waere mir nix
>mehr eingefallen, wie ich den Artikel wieder on-topic kriege :-).

Dein Denken widerspricht meinen Erfahrungen.  Angegebene Werte waren
nämlich *keine* Schätzungen, sondern die Werte, die mein
altertümliches Notebook (fest eingebaute 16450) unter FreeBSD auf die
Reihe bekommt.  Wenn Du's nicht glaubst, kannste gern einen Ausflug
nach Dresden machen. ;-)
-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

J Wunsch (j@uriah.heep.sax.de) wrote:
> Hmm.  Heutige Prozessoren werden mit 100 MHz getaktet, und dabei
> arbeiten sie teilweise noch parallel.  Das macht 300 Takte, damit
> sollte man grundsätzlich die Zeichen puffern können.

Das ist eine Fehlrechnung:

  * Erstens weiss ich nicht, wie Du von 100MHz auf 300 Takte kommst. Der von
    Dir zitierte FreeBSD Kernel ist mit gcc uebersetzt, der keine Pentium-
    Optimierung kennt, d.h. der Code ist nicht so aufbereitet, dass die
    beiden Pipes des Pentium vernuenftig genutzt werden.

  * Zweitens wird bei einem Interrupt die komplette Pipeline erstmal
    verworfen, auch bei Prozessoren mit Branch Target Buffer (Pentium), weil
    es eben kein Branch ist.

  * Drittens stoeren Interrupts die Lokalitaet des abgearbeiten Codes und Du
    bekommst Probleme mit dem Nachschaufeln der Daten. D.h. massgeblich ist
    hier nicht mehr der interne Prozessortakt, sondern es geht viel mehr in
    Richtung des Bustaktes, und der liegt weit unterhalb des CPU Taktes.

  * Viertens ist I/O bei den Intel Chips wegen der Pruefung der Permission
    Map straeflich langsam. Beim 486 braucht ein Lesen oder Schreiben einer
    I/O Adresse ca. 40(!) Taktzyklen. Wie's beim Pentium aussieht weiss ich
    gerade nicht, wahrscheinlich aber nicht besser. Selbst wenn man Deine
    300 Takte glaubt, lassen sich da nicht besonders viele I/O Zugriffe
    unterbringen.

  * Ausserdem willst Du ja womoeglich sowas wie ein Handshaking machen, auf
    Puffer-Ueberlauf pruefen und aehnliches. 

  * Und letzten Endes soll Dein Programm ja auch noch was anderes machen,
    als Interrupts abzuarbeiten (das ist aber mehr ein Problem der
    Interrupt-Rate als der Reaktionszeit).

Kann natuerlich sein, dass das bei anderen Prozesorfamilien etwas besser
ist, glauben tue ich das aber erst wenn ich es sehe :-)

> Dein Denken widerspricht meinen Erfahrungen.  Angegebene Werte waren
> nämlich *keine* Schätzungen, sondern die Werte, die mein
> altertümliches Notebook (fest eingebaute 16450) unter FreeBSD auf die
> Reihe bekommt.  Wenn Du's nicht glaubst, kannste gern einen Ausflug
> nach Dresden machen. ;-)

Das war nicht nur mein Denken, das sind Erfahrungen :-)

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz) writes:

>   * Viertens ist I/O bei den Intel Chips wegen der Pruefung der Permission
>     Map straeflich langsam.

Ich weiß, daß IO generell langsam ist, aber ich war der Meinung, daß
das vor allem am verkorksten ISA-Bus-(Nicht-)Design liegt.

Werden denn die blöden IO Permission Map Prüfungen nicht weggelassen,
wenn eine solche gar nicht benutzt wird?

(Ok, nun sind wir endgültig weg von de.comp.lang.c.  de.sci.electronics
lese ich aber nicht, also höre ich hier auf.)

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)