Mailinglist Archive: opensuse-programming-de (55 mails)
| < Previous | Next > |
Re: [opensuse-programming-de] hex2bin im string aufloesen
- From: David Haller <dnh@xxxxxxxxxxxx>
- Date: Mon, 11 Apr 2011 01:14:45 +0200
- Message-id: <20110410231445.GA19502@grusum.endjinn.de>
Hallo,
Am Sun, 10 Apr 2011, Thomas Moritz schrieb:
Jo ;)
$ i2c<TAB><TAB>
i2c-stub-from-dump i2cdump i2cset
i2cdetect i2cget
... wissen's scho ;)
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 ...
s.o. Sowas kenne ich ;)
:)))
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-programming-de+help@xxxxxxxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-programming-de+help@xxxxxxxxxxxx
| < Previous | Next > |