Re: Ansteuerung einer seriellen Schnittstelle

From: Bernd Walter <ticso(at)cicely8.cicely.de>
Date: Tue, 26 Mar 2002 15:53:16 +0100

On Tue, Mar 26, 2002 at 01:48:42PM +0100, Harold Gutch wrote:
> On Mon, Mar 25, 2002 at 12:42:44AM +0000, Peter Much wrote:
> > <logix(at)foobar.franken.de> aka Harold Gutch schrieb
> > mit Datum Sun, 24 Mar 2002 13:49:41 +0100 in m2n.de.fbsd.questions:
> >
> > !Ja, sowas haette ich auch zuerst vermutet, dann wuerde es aber
> > !doch wohl auch mit dem fork() nicht klappen, oder? Dort holt ja
> > !auch ein einziger read() mehr Zeichen ab als in dem Echo des
> > !Befehls alleine stehen, also werden auch hier von dem Telefon
> > !"auf einmal" mehr Zeichen geliefert, und eben nicht nur der
> > !Beginn meines Befehls.
> >
> > Nicht "auf einmal". Die Zeichen werden ja eh mit der Baudrate
> > geliefert. Und der read() geht auf das Interface und sammelt
> > Zeichen ein, solange er halt dazu lustig ist. Wie lange das ist,
> > hm, wenn ich mich nicht taeusche, haengt das mit der "line
> > discipline" zusammen. Das koennte ueber irgendwelche ioctl() Orgien
> > einstellbar sein. Ueberhaupt kenne ich serielle Bedienungen nur
>
> Schon klar, dass die Zeichen nicht "auf einmal" da sind.
> Allerdings erklaert das alles immer noch nicht, warum im einen
> Fall (mit fork() ) das Interface dem read() ein paar Zeichen
> zurueckliefert (die ge-echo-ten und ein bisschen Reply), im
> anderen Fall (ohne fork(), mit einem read() erst nach dem write() )
> aber gar keine zurueckliefert. Der eine read() liefert ja 8
> Zeichen zurueck und nicht nur 1, das interpretiere ich so, als ob
> die Schnittstelle da ein wenig puffert. Im anderen Fall sollte
> sie das fuer mein Verstaendnis ebenso tun, da liegt halt nicht
> sofort ein read() an, sondern erst sehr kurz spaeter - aber der
> bekommt dann gar nichts.

Wie schon gesagt ist das intern komplexer.
Auch wenn du cuaa* benutzt ist es intern immer noch eine TTY mit
anderen defaults.
Default line discipline ist cannonical - also Zeilenweise.
Shortreads kommen im Gegensatz zu Sockets nicht zustande, weil noch
nicht alle Daten da sind, sondern wegen Signals und Co.
Der read wartet im blocking Fall durchaus auf die gewünschte Datenmenge
und puffert selber.
Kurzum durch den read erzeugst du erst den ausreichend großen Buffer.
Im raw Mode oder non-blocking sieht es wieder etwas anders aus.
Wenn du es genau wissen willst solltest du die Funktion ttread
in src/sys/kern/tty.c lesen.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 26 Mar 2002 - 16:01:46 CET

search this site