Archiv der Kategorie: Embedded

Flashing Bootloader on CR-10S

Ups… there I did it. Unfortunately I tried to install the wrong hex file on the CR-10S board and it was gone. Empty LCD. No answer on boot.

To help others in fixing it faster, here the result of my research: The best hints I’ve found on https://www.instructables.com/id/Flashing-a-Bootloader-to-the-CR-10/

This is for the CR-10 and the CR-10S mainboard is a different beast: It has a different processor and the ICSP connector is at a different position.

CR-10S Mainboard with ICSP pins

I tried to follow Donovans walk through, but hat no success with his first method mentioned, but full success with the alternative method:

Her is the very fast howto:

  1. Pick up your Arduino One
  2. Get Nick Gammon’s sketches from https://github.com/nickgammon/arduino_sketches/archive/master.zip
  3. Flash the Atmega_Board_Programmer sketch on the Arduino One
  4. Connect the Arduino ICSP pins (except Reset) to the CR-10S boards (V2.1) ICSP pins. Reset on Arduino site is digital pin 10.
  5. At least you should see the CR-10S board power on. If not, you did something wrong.
  6. Go into Arduino->Tools->Serial Monitor
  7. Set Baudrate to 115200 and Communication to “Both NL and CR”
  8. If you see the menu of the Board Programmer, type G in the text box to program the bootloader. You should get a positive result in the programmer.
  9. Ready to continue business as usual with uploading firmwares.

Supasimple Picture Frame Raspberry Pi

Der plan ist für eine – ja genau eine bestimmte – Anwendung einen Pi aufzusetzen, der innerhalb eines Ordners Bilder als Slideshow zeigt und beim Anstecken eines USB Sticks mit Bildern diese lokal kopiert und dann diese als neue Slideshow nimmt. Was braucht man:
  • Raspberry Pi mit Raspian und folgenden paketen:
  • feh, nodm, xutils (xset)
Das ganze läuft unter dem User “pictures” also legen wir diesen an, ob mit oder ohne Passwort, alles egal. Auf jeden Fall wird der in nodm (/etc/default/nodm) als startuser eingetragen (das sind nur die geänderten Zeilen):
NODM_ENABLED=true
NODM_USER=picture
Dann bekommt der user picture ein .xession:
xset s off
xset -dpms
xset s noblank
feh --quiet --fullscreen --borderless \\
--hide-pointer --slideshow-delay 30 \\
/home/picture/Pictures
Dass die entsprechenden Directories existieren müssen ist klar, oder? So, jetzt fehlt nur noch ein Script um beim Anstecken eines Dongles, den Inhalt auf die SD Karte zu kopieren: /etc/udev/rules.d/usbstick.rules enthält:
ACTION=="add", KERNEL=="sd[a-z][0-9]", TAG+="systemd", ENV{SYSTEMD_WANTS}="usbstick-handler@%k"
Der usbstick handler ist in /lib/systemd/system/usbstick-handler@.service:
[Unit]
Description=Mount USB sticks
BindsTo=dev-%i.device
After=dev-%i.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/automount %I
ExecStop=/usr/bin/pumount /dev/%I
Es gibt ein /usr/local/bin/automount:
#!/bin/bash

PART=$1
rm -r /home/picture/Pictures/*
/usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/usb
cp -r /media/usb/* /home/picture/Pictures/
/usr/bin/pumount /dev/${PART}
killall -HUP feh
So, was könnte man da nicht noch alles machen: ne Taste anschliessen, eine Script, das das alles steuert auch mit vom USB Stick laden, ein Fallback bildchen… aber mei. S’geht ja schon… “Wie, und das war jetzt supasimple????”

GSM Gateway mit Asterisk und FreePBX auf Raspberry Pi

Nachdem ich erst versucht habe, das ganze zu Fuß auf Raspian zu bauen, hab ich nach gefühlten zwei Tagen aufgegeben und http://www.raspberry-asterisk.org genommen. Das hat den Riesenvorteil, dass man auch einen einigermaßen aktuellen Asterisk bekommt, auf dem der chan_dongle trotzdem geht.

Bei der Konfiguration hat vor allem:

Installing a FreePBX with FritzBox as trunk on a Raspberry Pi

geholfen. Es hat trotzdem alles nicht auf Anhieb geklappt. Irgendwann bin ich dann dazu übergegangen, alles, was nach ID und Passwort klang, gleich zu nennen, jetzt gehts 🙂 Ob das jetzt sicherheitstechnisch schlimm ist, kann ich schwer sagen (ok, stimmt nicht :-), ist alles im Intranet, da können mich die Leute auch schädigen, wenn sie einfach das Telefon in die Hand nehmen.

Vorher habe ich den UMTS Stick (Huawei E160) direkt an der Fritte betrieben, aber seit 6.83 ging das plötzlich nicht mehr. Aber da man dort eh die ausgehende Rufnummer nicht unterdrücken kann, ist mir das so eh viel lieber. Der RPi braucht übrigens mit dem Dongle ca. 3 Watt.

Im Prinzip sollte das auch immer noch mit dem UMTS Dongle an der Fritte gehen. Aber AVM gibt leider keine Liste mit unterstützten Sticks heraus und Rufnummernunterdrückung geht mit dieser Methode auch nicht… meine Handynummer soll ja nicht unbedingt bei einem Anruf von zuhause angezeigt werden.

Debian Repository per ssh auf ein chroot

Für eigene Zwecke will man immer mal ein Repository haben, auf das andere nicht zugreifen können, aber das man auch an Bekannte oder Testgruppen oder wen auch immer weitergeben kann. ftp mit Passwort und http mit Passwort sind so ne Sache, ein wenig sicherer könnte das schon sein.

Debian Repositories können auch via ssh eingebunden werden, eine entsprechende Zeile in der sources list sieht dann so aus:

deb ssh://repouser@example.com/packages/ jessie main

Auf dem Server muss man einen entsprechenden Nutzer einrichten und die packages enthalten eben das Debian Repository. Authentisierung erfolg per ssh key, d.h. auf Clientseite wird ein ssh-Key erzeugt, der auf Serverseite im ~/.ssh/authorized_keys des repouser liegt. Soweit so straightforward.

Der Nachteil dieser Variante ist, dass der repouser nun einen ssh login auf dem Server hat, was ihn natürlich auch lesenden Zugriff auf andere Ressourcen gibt, was man eher nicht unbedingt will. Kann sein, dass man dies auch noch besser absichern kann, die beste Absicherung ist auf jeden Fall, diesen Benutzer in ein chroot environment zu sperren.

Dieses fahre ich über die sftp chroot variante des sshd, in der sshd_config steht dazu:

Subsystem sftp internal-sftp

Match Group sftp
ChrootDirectory %h
AllowTcpForwarding no

Nun muss der repouser noch zur Gruppe sftp dazu und jetzt kommt das eigentliche Problem: die chroot Umgebung mit den richtigen Dateien und Rechten auszustatten, d.h. alles dort einzurichten, was nötig ist, um auf Clientseite apt-get … aufzurufen. Und da war das Problem: Was braucht apt-get via ssh auf der Serverseite? Letzendlich hab ich es nur raus bekommen, in dem ich mir die Sourcen von apt-get angeschaut habe. Und da waren vor allem find und dd die Hänger… die drauf und es ging. Wie man herausbekommt, welche libs nötig sind, sagt ldd find und ldd dd und gut ist.

Das ganze ist hier in einem schmutzigen Script, das so unter Ubuntu 14.04 läuft, Achtung: die Libs werden so für andere Distris nicht passen, aber ldd ist dein Freund, der Rest stimmt.

<br />
#!/bin/bash<br />
echo &quot;This script should be started as root on the machine, which hosts the repo&quot;<br />
REPOUSER=&quot;repouser&quot;<br />
REPOHOME=&quot;ssdhome/$REPOUSER&quot;<br />
echo &quot;Generating chroot environment for $REPOUSER in $REPOHOME&quot;&lt;/code&gt;</p>
<p>adduser --disabled-password --ingroup sftp --home /$REPOHOME $REPOUSER<br />
mkdir -p /$REPOHOME<br />
chown root:root /$REPOHOME<br />
cd /$REPOHOME<br />
mkdir -p bin dev etc home lib usr var tmp usr/bin vat/tmplib/x86_64-linux-gnu usr/lib/x86_64-linux-gnu $REPOHOME lib/x86_64-linux-gnu lib64<br />
cp /bin/ls bin/<br />
cp /bin/dash bin/sh<br />
cp /bin/bash bin/<br />
cp /usr/bin/scp usr/bin/<br />
cp /bin/dd bin/<br />
cp /usr/bin/find usr/bin/<br />
cp /usr/bin/whoami usr/bin/<br />
cp /lib/x86_64-linux-gnu/libtinfo.so.5 lib/x86_64-linux-gnu/<br />
cp /lib/x86_64-linux-gnu/libdl.so.2 lib/x86_64-linux-gnu/<br />
cp /lib/x86_64-linux-gnu/libc.so.6 lib/x86_64-linux-gnu/<br />
cp /lib64/ld-linux-x86-64.so.2 lib64/<br />
cp /lib/x86_64-linux-gnu/libselinux.so.1 lib/x86_64-linux-gnu/<br />
cp /lib/x86_64-linux-gnu/libacl.so.1 lib/x86_64-linux-gnu/<br />
cp /lib/x86_64-linux-gnu/libpcre.so.3 lib/x86_64-linux-gnu/<br />
cp /lib/x86_64-linux-gnu/libattr.so.1 lib/x86_64-linux-gnu/<br />
cp /lib/x86_64-linux-gnu/libnss_compat* lib/x86_64-linux-gnu/<br />
cp /lib/x86_64-linux-gnu/libm.so.6 lib/x86_64-linux-gnu/<br />
mknod dev/null c 1 3<br />
mknod dev/zero c 1 5<br />
chmod 666 dev/*<br />
chmod 1777 tmp<br />
grep $REPOUSER /etc/passwd &amp;gt;&amp;gt; etc/passwd<br />
echo &quot;now, cp the repository beginning with the packages dir to ssdhome/$REPOUSER&quot;<br />
echo &quot;do not forget to add the public key to ssdhome/$REPOUSER/.ssh/authorized_keys&quot;<br />
echo &quot;and add a line like: deb ssh://$REPOUSER@example.com/packages/ jessie main&quot;<br />

 

MAMEKiosk – Update

Ein Nachtrag zum MAMEKIOSK:

Jetzt geht es darum das ganze auf RPI2 umzurüsten. Und ne USB Audio Karte reinzubauen. Zweiteres ganz einfach mit nem billig-USB-Dongle und dieser Anleitung.

Das aktuelle Image von piplay ist flugs gezogen, aber: pikeyd geht wohl nicht auf dem RPI2… also geschaut und da gibt es Retrogame was das gleiche machen sollte… sieht auch alles gut aus… aber irgendwas klappt da doch noch nicht ganz. Auf jeden Fall muss die obige Verdrahtung in retrogame.c so hardgecodet sein:

</p>
<p>ioStandard[] = {<br />
 { 7, KEY_LEFT }, // Joystick (4 pins)<br />
 { 9, KEY_RIGHT },<br />
 { 10, KEY_DOWN },<br />
 { 11, KEY_UP },<br />
 { 17, KEY_LEFTCTRL }, // A/Fire/jump/primary<br />
 { 22, KEY_LEFTALT }, // B/Bomb/secondary<br />
 { 4, KEY_SPACE }, // C<br />
 { 8, KEY_5 }, // Credit<br />
 { 15, KEY_1 }, // Start 1P<br />
 { 14, KEY_2 }, // Start 2P<br />
 { -1, -1 } }; // END OF LIST, DO NOT CHANGE </p>
<p>

Ob das nun funktioniert hat, kann man z.B. mit input-events 1 nachprüfen (aus dem input-utils paket).

Was ich noch nicht rausbekommen habe: welches das input mapping für die Bestätigung von safequit ist, also hab ich misc_safequit no in advmame.rc gesetzt. Ah, habs: [ui_select] isses… also doch safequit an.

BTW: ich hab doch das alte advmenu vom alten pimame genommen, das gefällt mir wesentlich besser als die ganzen vielen Emulatoren, ich will eh nur advmame.

Ergebnis vom Ganzen? Einiges gelernt, einiges gebastelt und: alles ist viel flüssiger und der Ton eiert nicht mehr rum, wenn die CPU unter Last kommt! Hat sich also gelohnt!

MAMEkiosk

Ein Projekt, das schon länger im Bau ist. Aber auch schon immer wieder mal fröhlich gespielt wird. In meiner beruflichen Historie hab ich am Telekiosk mit gebaut und wollte immer mal so ein Teil als Andenken haben, was auch irgendwann geklappt hat. (Dank an den Spender an dieser Stelle 🙂 ) Dieser ist von der Bildschirmkonstruktion und von der Gehäusestabilität hervorragend dazu geeignet, eine Spielekonsole nach alter Provinienz abzugeben. Also flugs das ganze alte Gerümpel raus – alleine schon wegen Lautstärke und Stromverbrauch – und ein Raspberry Pi rein. Fertig. … oh, moment. Der eingebaute TFT hat nur LVDS Input…

Die – elektrisch – einfachste Variante: TFT raus, billigen 17″ TFT abgreifen, einbauen – der Touch kann ja weiter verwendet werden.

Die Distribution, die drauf läuft ist ein PiMAME (jetzt PiPlay genannt),  mit kleinen Anpassungen. Für die Joysticks hab ich GPIO Pins benutzt (da ich nur einen Joystick und ein paar Knöppe gemacht hab, hat das gereicht), getrieben wird das über pikeyd, die Buttons hab ich mit Widerständen (siehe hier) an die GPIOs gemacht.

/etc/rc.local:

<br />
amixer cset numid=3 1<br />
alsactl restore<br />
/sbin/pikeyd -d<br />
exit 0<br />

/etc/pikeyd.conf:

<br />
KEY_LEFTCTRL    17<br />
KEY_LEFTALT     22<br />
KEY_SPACE       4<br />
KEY_RIGHT       9<br />
KEY_DOWN        10<br />
KEY_UP          11<br />
KEY_LEFT        7<br />
KEY_5           8<br />
KEY_1           15<br />
KEY_2           14<br />