Re: Ansteuerung einer seriellen Schnittstelle

From: Bernd Walter <ticso(at)cicely8.cicely.de>
Date: Sun, 24 Mar 2002 14:22:21 +0100

On Sun, Mar 24, 2002 at 01:49:41PM +0100, Harold Gutch wrote:
> On Sun, Mar 24, 2002 at 11:35:17AM +0100, Bernd Walter wrote:
> > On Sun, Mar 24, 2002 at 04:45:16AM +0100, Harold Gutch wrote:
> > > Hi,
> > >
> > > ich habe letztens ein serielles Kabel fuer das Nokia 6210 in die
> > > Haende bekommen und wollte nun ein wenig damit rumspielen. Das
> > > Telefon versteht AT-Befehle und ist m.W. komplett darueber
> > > ansteuerbar, das ganze sollte also nicht allzu wild sein. Jetzt
> > > habe ich also ein kleines C-Programm zusammengehackt, das im
> > > Prinzip nichts anderes macht als ein "ATI\r" an die Schnittstelle
> > > an der das Geraet haengt zu schicken, und danach mit einem
> > > read() Daten von derselben zu lesen - und an dieser Stelle
> > > blockt das Programm, sprich es scheinen keine Daten zum Lesen
> > > vorzuliegen. Aendere ich das ganze allerdings leicht so dass ich
> > > einen zweiten Prozess forke, den zuerst (blockend) read()en lasse,
> > > dann Daten schreibe, so funktioniert es wie erwartet. Habe ich
> > > jetzt das Konzept von seriellen Schnittstellen nicht verstanden,
> > > oder ist da was anderes kaputt?
> >
> > Die klassischen Programme wie tip und cu starten auch einen eigenen
> > Prozess für jede Richtung.
> > Heutzutage kann man das aber mit non-blocking I/O oder pthreads
> > erledigen.
> > In deinem Programm fehlt auch die Prüfung auf retval -1 und damit
> > der Support für EINTR beim read und write.
>
> Ja, aus "cu" hatte ich auch die Idee (die fuer mich auf den
> ersten Blick nichts mit dem Problem zu tun hat), das ganze auf
> zwei Prozesse aufzuteilen :). Die Fehlerabfrage fehlt
> natuerlich, ebenso z.B. die Fehlerabfrage des open() und noch so
> einiges weitere, es ging mir hierbei auch nur darum, das Problem
> auf moeglichst wenig Zeilen C zu reduzieren. Mache ich das ganze
> uebrigens non-blocking, so liefert mir der read() einen EINVAL
> zurueck.

Aus der read(2) manpage:
     [EINVAL] The pointer associated with d was negative.
Nun d ist der Filedescriptor - das hat eindeutig andere Gründe als
non-blocking - fcntl verändert ja nicht den descriptor.
Vermutlich hast du da einen neuen Fehler reingemacht.

> On Sun, Mar 24, 2002 at 11:40:01AM +0100, Bernd Walter wrote:
> > Gerade habe ich noch die Erklärung für dein Problem vergessen:
> > Der write erzeugt ein echo, das abgeholt werden muss, ansonsten
> > nimmt das Gerät ab einem bestimmten Punkt nicht mehr entgegen.
> > In deinem Fall reicht das scheinbar nicht mal mehr für den einen
> > Befehl.
>
> 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.

Das ist im Hintergrund schon etwas komplexer.

-- 
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 Sun 24 Mar 2002 - 14:24:48 CET

search this site