Re: hex2bin im string aufloesen

Hallo,

Am Sun, 10 Apr 2011, Thomas Moritz schrieb:
>Am Sonntag, 10. April 2011 17:08:29 schrieb David Haller:
>> bin=3D$(
>>     { echo "ibase=3D16; obase=3D2;";
>>       i2cget -y 0 0x27 0 | cut -d 'x' -f2 | tr '[a-f]' '[A-F]'
>>     } | bc)
>>=20
>> 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             =20
i2cdetect           i2cget

=2E.. 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=20
>beschaeftigen. Erwischst Du den internen, statt dem externen Bus, dann=20
>legst Du mal schnell die gesamte Kiste lahm!=20

Kenn ich vom ISA-Bus im alten Rechner ;) Hab ich da den SCSI-Treiber
g_NCR5380 f=FCr 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 ;)

=3D=3D=3D=3D /root/slarty/etc/modules.conf-2.4.37.10 [ein Backup] =3D=3D=3D=
=3D
# for DTC/DMX 3181(L)E ISA-SCSI card
alias scsi_hostadapter g_NCR5380
options g_NCR5380 ncr_irq=3D255 ncr_addr=3D0x280 dtc_3181e=3D1
=3D=3D=3D=3D /root/slarty/etc/modules.conf-2.2.14 [ein viel =E4lteres] =3D=
=3D=3D=3D
# options g_NCR5380 ncr_irq=3D255 ncr_addr=3D0x300 ncr_5380=3D1
=3D=3D=3D=3D

ncr_addr=3D0x300 scheint auch gegangen zu sein (hab ich in =E4lteren
modules.conf's drin). Aber alles andere hat mir die Kiste
nachvollziehbar lahmgelegt ... =C4h, 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=20
>endlich geschafft! Ich kann Input-Events abfragen und LED's am Output=20
>schalten...

:)))

>Ein Relais am GPIO-In-Port0 wird den 'shutdown' anschmeissen, bevor=20
>1Min. spaeter der Strom weg ist!=20
>Den C-Kram haben aber zum Glueck andere Leutchen am Hals :-)=20

Guck, da=DF du ein bisserl perl lernst. Das kannst du prinzipiell f=FCr
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=E4rkrams machen kannst (k.a. wie das bei Python, Ruby oder
z.B. Scheme aussieht). Der zus=E4tzliche 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=F6tig) agieren wie als h=E4ttest 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=DFt dich aber nicht um den Kleinkram k=FCmmern
(ok, mit sysread/syswrite brauchst passende Puffer, aber das ist in
perl simpel). Und bis auf 'system' hat perl das meiste schon sch=F6n
gekapselt, f=FCr system h=E4tt 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 =F6fter 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.=E4. f=FCr z.B. ein
hdparm).

-dnh

--=20
Every feature is a bug, unless it can be turned off.  -- Karl Heuer