|
Anzeige
|
Frage zu Linux Bash-Befehl "echo"
Gast
#961632
Hallo zusammen, ich sitze gerade vor einem Skript eines Embedded Linux (TriCore-System), in dem mit den Echo-Befehl direkt auf die Hardware geschrieben wird: # Revoke request & LED on echo 001 > /dev/gpio/port4 echo 300 > /dev/gpio/port3 Ich verstehe das Format der zu sendenden Daten nicht "001" bzw. "300". Laut echo-Beschreibung sollte das doch immer ein String sein? Wie ist das zu verstehen? Danke Gruß Thomas
Gast
#961638
Es wird einfach der Wert in den entsprechenden Stream geschrieben. Gruss Robert
Gast
#961643
> # Revoke request & LED on > echo 001 > /dev/gpio/port4 > echo 300 > /dev/gpio/port3 > > Ich verstehe das Format der zu sendenden Daten nicht "001" bzw. "300". > Laut echo-Beschreibung sollte das doch immer ein String sein? Ja. > Wie ist das zu verstehen? Es wird ein String gesendet.
Gast
#961928
Dann verstehe ich den Sinn aber nicht, wieso werden zum einschalten der LED an Port4 dann drei Bytes gesendet? Dann sollte doch eins reichen. Übrigens sind in allen Skripten, die derart auf die Ports schreiben immer 3 Zeichen lange Argumente als Datenquelle. Das leuchtet mir nicht ein. Ein String wäre ja ein sequenzielles senden der drei Bytes. ich glaube das alles liegt am betriebssystem hinter den ports. Du schreibst ja nicht "direkt" ne 1 auf das Port sondern schreibst die Info als Text in den Port-Node vom Betriebssystem. Das darinstehende wird dann vom entsprechenden Treiber ausgewertet und bearbeitet... /hannes TOM wrote: > Dann verstehe ich den Sinn aber nicht, wieso werden zum einschalten der > LED an Port4 dann drei Bytes gesendet? Dann sollte doch eins reichen. Du kannst aber nicht ein einzelnes Byte so einfach als einzelnes ASCII-Zeichen senden. Es ist besser, wenn es irgendwie kodiert wird, und da kommt es dann halt darauf an, wie der dahinter liegende Treiber es gerne hätte. Dieser möchte anscheinend durch '\n' separierte Oktalwerte (als String) haben.
Gast
#961988
Jetzt verstehe ich ein bisschen mehr. Mir fehlt wohl etwas das Verständnis wie sich der Treiber dort einhängt und die Übergabe der Werte stattfindet. Ich bin noch nicht fit auf dem Gebiet der Linux-Innereien, aber das wird noch... Danke Euch Gruß Thomas Der Treiber "hängt" sich nicht auf das Device ein. Der Treiber (grob gesagt) erzeugt das Device, also /dev/gpio/*. (fein gesagt: der treiber erzeugt ein node irgendwo in /sys und das darüberliegende device-pogramm [devfs, udev] erzeugt dann die node in /dev) Wenn du dann irgendwas dort hineinschreibst kriegt er (vielleicht) einen Interrupt und behandelt dann das was sich der Erschaffer des Treibers ausgedacht hat...
Gast
#962109
> Dieser möchte anscheinend durch '\n' separierte Oktalwerte > (als String) haben. So etwas macht auch sinn, weil das eben genau erlaubt, den Treiber aus einem Shellskript anzusteuern.
Gast
#962202
@Joggl, (fein gesagt: der treiber erzeugt ein node irgendwo in /sys und das darüberliegende device-pogramm [devfs, udev] erzeugt dann die node in /dev) Mit sysfs hat das nichts zu tun. Entweder man erzeugt den Device Node selber oder man konfiguriert devfs oder udev so das sie den entsprechenden Device Node nach einem Hotplug Event (erzeugt durch den Kernel) anlegen. Gruss, Bernd
Gast
#962827
Mag mich täuschen, aber udev holt sich seine Infos über zu erstellende Devicenodes tatsächlich aus sysfs, und sysfs hat devfs mehr oder weniger abgelöst. Haben wir auf Embeddedsystemen so gemacht: * Treiber wird beim Bootvorgang geladen, trägt seine dynamisch angeforderten Device IDs im sysfs ein * Am Ende des Bootvorgangs liessen wir mdev sysfs durchrasseln und Devicenodes erstellen. Hotplugevents haben wir nicht benutzt, da auf einem Gerät immer dieselben Treiber geladen werden mussten, welche war schon beim Booten klar. Aber wir mussten nicht selber statisch Devicenodes verteilen. Bartli wrote: >> Dieser möchte anscheinend durch '\n' separierte Oktalwerte >> (als String) haben. > > So etwas macht auch sinn, weil das eben genau erlaubt, den Treiber aus > einem Shellskript anzusteuern. Obwohl es im Shellskript auch kein Problem wäre, direkt die Binärdaten zu erzeugen:
Gast
#963128
Weiss ich, aber noch lange nicht jede echo-Implementation kann -e. /proc/devices müsste die Quelle sein (bzw. die Quelle davon). Der 2.4er Kernel kannte noch garkein sysfs. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
