Frage zu Linux Bash-Befehl "echo"

[TOM (Gast)]

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

[RFr (Gast)]

Es wird einfach der Wert in den entsprechenden Stream geschrieben.
Gruss
Robert

[Rolf Magnus (Gast)]

> # 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.

[TOM (Gast)]

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.

[Hannes J. (Firma: eHaJo.de) (joggl)]

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

[Stefan E. (sternst)]

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.

[TOM (Gast)]

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

[Hannes J. (Firma: eHaJo.de) (joggl)]

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...

[Bartli (Gast)]

> 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.

[Bernd (Gast)]

@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

[Bartli (Gast)]

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.

[Εrnst B. (ernst)]

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:

> echo -n -e '\xaa\x55\024\007' | hexdump -C
00000000  aa 55 14 07                                       |.U..|

[Bartli (Gast)]

Weiss ich, aber noch lange nicht jede echo-Implementation kann -e.

[I_ H. (i_h)]

/proc/devices müsste die Quelle sein (bzw. die Quelle davon). Der 2.4er 
Kernel kannte noch garkein sysfs.