Hallo,
könnte jemand so freundlich sein, und sich mal dieses Progrämmchen (8k)
compilieren?
http://www.labyrinth.net.au/~steve/tools/scopegrab.tar.gz
Idealerweise mit einer frei(gegeben)en Schnittstelle.
Bei mir (suse 9.3) bricht das programm leider immer mit einem fehler
(#11) (resource temporarily unavailable) bei fread() (ca. Zeile 176)
ab. Das passiert für ttyS0 und ttyS1, egal ob etwas angeschlossen ist.
Da ich Neuling bin, was diese Sachen angeht, folgende Fragen an die,
die sich damit auskennen:
Ließe sich zum Fehler noch genaueres herausfinden, und ist das
sinnvoll?
Prüft die Funktion fread die Hardwaresignale (DTR, CTS etc.) und
verweigert deshalb den Dienst?
Wenn der Port gerade belegt ist, wieso also? Anderes Programm?
Schreibzugriff noch nicht abgeschlossen, obwohl sleep(2)
dazwischenliegt?
Wie kann ich herausfinden, ob ein anderes Programm den Port blockiert?
Danke schonmal, meine Suchen sind nicht so erfolgreich..
leif
Leif,
lass mal die nodelay-Sachen weg. VMIN/VTIME sollten da reichen.
Also:
if ((fd = open(argv[1], O_RDWR | O_NOCTTY)) == -1)
statt:
if ((fd = open(argv[1], O_RDWR | O_NOCTTY | O_NDELAY)) == -1)
und "fcntl(fd,F_SETFL,FNDELAY);" kann ganz weg.
Gruß,
Falk
"termios" sind die Hölle ;-)
Noch ein paar Details:
Kein Programmierer der Welt würde je ein Programm, das ähnliches tut,
zur Hand nehmen und nachsehen, wie andere das gemacht haben. Nur die
real existierenden tun das ;-)
> Ließe sich zum Fehler noch genaueres herausfinden, und ist das> sinnvoll?
Nein, mehr als Deine Fehlermeldung wirst Du nicht bekommen.
> Prüft die Funktion fread die Hardwaresignale (DTR, CTS etc.) und> verweigert deshalb den Dienst?
Nein: read liest aus dem Dateidescriptor. Punkt. fread macht mehr
,weshalb ich das nie benutze, wenn ich wissen will, was wirklich
passiert. (read(2) ist ein Systemaufruf, fread eine
Bibliotheksfunktion.
RTS/CTS sind Einstellungen für diese spezielle Art eines Gerätes. Das
wird durch ioctls bzw. tcsetattr, das letzten Endes auch ioctl benutzt,
festgelegt.
Hint: Jedes Gerät kennt "open", "close", "read", "write" und
besonders "ioctl". Der marginale Unterschied zwischen einem
Bandlaufwerk und einer seriellen Schnittstelle ist, daß erstere ioctls
für "rewind" und "eject" kennt, aber keines für die Baudrate und
umgekehrt. (Dafür liebe ich Unixe)
> Wenn der Port gerade belegt ist, wieso also? Anderes Programm?
Du könntest "fuser /dev/ttyS0" versuchen.
> Schreibzugriff noch nicht abgeschlossen, obwohl sleep(2)> dazwischenliegt?
Nö, das "write" kommt zurück, wenn es fertig ist. (Das fwrite auch
vorher, wenn ich mich recht erinnere.)
> Wie kann ich herausfinden, ob ein anderes Programm den Port> blockiert?
Ja ;-) Im allgemeinen wird auf "Unixen" eine Datei unter
"/var/lock/LCK...ttyS0" angelegt.
Das ist etwas häßlich, da könnte "O_EXCL" beim "open" helfen.
Ansonsten würde ich mir ein Programm suchen, das solche Sachen macht,
wie "minicom", "pppd", "cu" et al.
Gruß,
Falk
P.S.: "strace" ist Dein Freund!
So, danke nochmals. jetzt scheint's zu gehen. Ich habe aber wohl einen
Hardwarefehler, d.h. sie hat wohl nicht genug saft, um die Antwort vom
Gerät auf die richtige Spannung zu bringen; jedenfalls bekomme ich auch
mit minicon keine antwort :-)
Aber das Programm läuft, und morgen geht's weiter..
so tach, ich bin's nochmal..
es sollte doch problemlos moeglich sein, per loopback dongle mit der
seriellen schnittstelle zu schreiben, und den puffer anschliessend
wieder auszulesen?
ich hab den code auf nem anderen rechner - es funktioniert prinzipiell
auch, aber es kommen in meinem testfall nur 6 unzusammenhaengende von
ca. 20 gesendeten zeichen an. gibt es da eine pauschalfehlerquelle, die
ich mal pruefen koennte?
sonst poste ich nochmal code, wenn ich rausgefunden habe, wie ich meine
zwei susis vernetze, so dass beide ueber eine wlankarte ueber den router
ins netz komme.
also das mag daran gelegen haben, dass ich direkt im anschluss gelesen
habe, und die daten dann noch nicht da waren.. ich werde mich nochmal
ein bisschen schlauer machen, macht ja auf dauer keinen spass sowas auf
gut glueck hinzubekommen (oder auch nicht)..
