Hallo, Am Sun, 10 Apr 2011, Thomas Moritz schrieb:
Am Sonntag, 10. April 2011 17:08:29 schrieb David Haller:
bin=$( { echo "ibase=16; obase=2;"; i2cget -y 0 0x27 0 | cut -d 'x' -f2 | tr '[a-f]' '[A-F]' } | bc)
das 'tr' nur zur Sicherheit, weil bc nur Uppercase-Hex-A-F frisst, und ich i2cget nicht kenne, ob das nicht evtl. auch mal lowercase ausgibt.
'lowercase' Genau das war das _eine_ Problem! Siehe meine weiteren Postings...
Jo ;)
i2c* stammen aus den 'i2c-tools'
$ i2c<TAB><TAB> i2c-stub-from-dump i2cdump i2cset i2cdetect i2cget ... wissen's scho ;)
Um mit den GPIO-Pins "spielen" zu koennen, ist zuerst einmal i2cdetect -l notwendig! Wird ein Bus ausgegeben, kannst Du Dich mit diesem beschaeftigen. Erwischst Du den internen, statt dem externen Bus, dann legst Du mal schnell die gesamte Kiste lahm!
Kenn ich vom ISA-Bus im alten Rechner ;) Hab ich da den SCSI-Treiber g_NCR5380 für den Controller mit dem flaschen[tm] I/O-Port geladen hing sich die Kiste _HART_ auf (IIRC ging einmal nichtmal mehr der Reset-Taster, nur Power-Taster bzw. "Strom weg" half noch ;) ==== /root/slarty/etc/modules.conf-2.4.37.10 [ein Backup] ==== # for DTC/DMX 3181(L)E ISA-SCSI card alias scsi_hostadapter g_NCR5380 options g_NCR5380 ncr_irq=255 ncr_addr=0x280 dtc_3181e=1 ==== /root/slarty/etc/modules.conf-2.2.14 [ein viel älteres] ==== # options g_NCR5380 ncr_irq=255 ncr_addr=0x300 ncr_5380=1 ==== ncr_addr=0x300 scheint auch gegangen zu sein (hab ich in älteren modules.conf's drin). Aber alles andere hat mir die Kiste nachvollziehbar lahmgelegt ... Äh, halt, nein, die 0x300 sind alle auskommentiert ...
Das habe ich durch mit '0x50' statt '0x27'. Dann geht nix mehr ausser Hardreset, wenn Du "gut" bist :-)
s.o. Sowas kenne ich ;)
Fuer GPIO-Pins sind: i2cdump i2cget i2cset eine nette Spielerei :-)
Mit diesem Kram quaehle ich mich seit 5 Monaten herum und habe es endlich geschafft! Ich kann Input-Events abfragen und LED's am Output schalten...
:)))
Ein Relais am GPIO-In-Port0 wird den 'shutdown' anschmeissen, bevor 1Min. spaeter der Strom weg ist! Den C-Kram haben aber zum Glueck andere Leutchen am Hals :-)
Guck, daß du ein bisserl perl lernst. Das kannst du prinzipiell für beides verweden ("Scripting" wie in der bash und "Programming" wie mit C, samt Bit-Banging auf nem /dev/bla als auch Rechnereien und Stringkrams auf z.B. stdin/stdout). Eben "Schweizer Taschenmesser" oder "Allzweckwaffe" bei so Krams. Das mit dem Bit-Geschubse (pack/unpack hab ich bisher nicht wirklich kapiert) ist allerdings nicht einfach, aber ansonsten ist perl eine Script-Sprache, mit der du eben auch Binärkrams machen kannst (k.a. wie das bei Python, Ruby oder z.B. Scheme aussieht). Der zusätzliche Vorteil von Perl ist: das hast du auf jedem Linux mit dabei (bei openSUSE schon um den Bootloader zu installieren), und auch sonst ist's auf Unices fast immer da. Bei Perl kannst du halt (wenn nötig) agieren wie als hättest du C, also z.B. Bytes nach /dev/bla schubsen oder davon lesen ;) Einfachen Kram bekomm ich auch noch in C hin, allerdings fehlt mir die Erfahrung z.B. bzgl. "Buffer-Overflows", "Off-by-1" usw. und generell ist die Fehlerbehandlung eher nervig zu implementieren, auch wenn ich da AFAIK meist alles richtig mache (z.B. snprintf zu verwenden ;) Grad wg. sowas mag ich perl: du kannst weitgehend den gleichen Low-Level-Krams machen, mußt dich aber nicht um den Kleinkram kümmern (ok, mit sysread/syswrite brauchst passende Puffer, aber das ist in perl simpel). Und bis auf 'system' hat perl das meiste schon schön gekapselt, für system hätt ich dir die passende sub ;) Ansonsten ist Fehlerbehandlung in perl meist nach dem Muster: bla() or die "$!\n"; oder einer weniger radikalen Variante davon, je nach Fehler ;) Ah, und ggfs. kann man in/mit Perl mit C programmieren (-> 'man perlxs', 'man Inline::C' u.a.m.). Kurzum: mit Perl gilt das Motto "du kannst". Du kannst - bei /bin/sh bleiben - z.B. /bin/bash fordern - das gleiche in perl machen ... - bis hin zu Assembler-Code im XS/Inline-C (AFAIK) Und v.a. das "..." eben öfter als du denkst ;) Bis hin zu init-Scripten (s.a. perlsh). KANN, nicht sollte! Theoretisch kann ich mir ein System vorstellen, das aus wenig mehr als dem Kernel und perl besteht (+dietlibc/busybox o.ä. für z.B. ein hdparm). -dnh -- Every feature is a bug, unless it can be turned off. -- Karl Heuer -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org