Make Munich

Dieses Wochenende fand die zweite Make Munich statt und da mussten Chris und ich natürlich dabei sein! Also auf in die Tonhalle und hinein ins nerdige Vergnügen. Natürlich gab es jede Menge Elektronik, 3D Drucker etc. zu sehen. Aber auch das Vortragsprogramm war durchaus interessant. Nur bitte liebe Veranstalter: das mit dem Mikrofon üben wir noch – so kann ja kein Mensch verstehen, was der Redner erzählt. Und ein bisschen mehr Platz für Publikum wäre auch gut gewesen.
Natürlich gab's neben den Ständen und vielen Gesprächen auch Club Mate, Lötkurse, Basteln zum Mitmachen, Kram zum kaufen und coole Konstruktionen der verschiedenen Teilnehmer.
Wir hatten jedenfalls viel Spaß, haben ein paar Euro für Kleinkram ausgegeben und freuen uns schon auf die hoffentlich stattfindende Make Munich 2015 – dann vielleicht noch größer?

Viel los in der Tonhalle

Mehrere Hackerspaces und Fablabs waren vertreten.

Hier glimmt es geheimnisvoll!

Ob der Bediener die Anzeige zu deuten weiß?

Zur Abwechslung mal was mechanisches: der MakerBeam!

Kinder lieben Oculus Rift!

Shields und Nützliches bei Watterott

Auch selbst Handanlegen war möglich – Kinder wie Erwachsene hatten Spaß an den diversen Lötständen

Maker-Urgestein: die Amateurfunker

Nein - Maker sind nicht alle männlich und pickelig.

Blaue Zähne für Arduino

3D drucken Du sollst!

DIY Quadcopter und andere schöne Sachen

Auch eine alte Strickmaschine kann coole Sachen machen, wenn Sie ein neues Gehirn bekommt.

Kinder die auf Drucker starren...

Das Gegenteil von hochintegrierten Bauteilen.

Stadt-Imker!

Auch Nadel und Faden sind den Makern nicht fremd.

Oder wie wäre es mit einer Runde DIY Siebdruck?

Oder selbstegebasteltem Schmuck?

PCE-174 Luxmeter/-logger

Ich habe mal wieder ein neues Spielzeug: ein Luxmeter. Konkret handelt es sich um das PCE-174, dass angeblich baugleich zum Extech HD450 sein soll. Es misst, soweit ich das in meinen ersten Tests sehen konnte, ganz stabil. Die Bedienung ist ein wenig träge, aber ich will ja auch nicht beruflich die Lichtstärke messen, sondern nur mal so. Das Ding hat auch gleich einen internen Speicher, so dass man manuell Messwerte speichern kann und, was viel interessanter ist, Daten automatisch loggen kann. Wie bei preiswerteren Messgeräten üblich wurde die beiliegende Windows Software wohl von Chinesen programmiert und ist nicht so das Gelbe vom Ei und von einer LINUX Software kann man eh nur träumen. Also gilt das übliche Motto: Selbst ist der Mann. Das Gerät wird am USB Port als USB2RS232 Adapter erkannt – das stimmt ja schonmal hoffnungsvoll. Nur wie redet man mit dem Gerät? Auf der Homepage ist natürlich nichts zu finden und so habe ich eine ganze Weile rumprobiert, bin aber auf keinen grünen Zweig gekommen.

Ich hatte mir schon vorgenommen, in einer ruhigen Minute mal ein kleines Fuzzing-Skript zu basteln, um dem Teil eine Reaktion zu entlocken und der Windows-Software mal bei der Kommunikation zuzuhören. Aber zuvor habe ich das getan, was kein klar denkender Hacker je tut: Ich habe an den Hersteller geschrieben und um Info gebeten. Ich weiß – hahaha, viel Glück und so. Doch manchmal passieren auch Wunder: Keine 24h später hatte ich eine, wenn auch in knappem Chinglish verfasste, Doku in der Hand! Das muss ich mal echt lobend hervorheben – danke PCE! Die Doku ist extrem knapp und, wie ich inzwischen weiß, auch nicht ganz vollständig/korrekt, aber allemal gut genug, um den Rest selber raus zu kriegen. Also Daumen nach oben.

Die größte Hürde bei meinen Versuchen, das Protokoll selber zu erraten bestand, wie ich nun weiß, darin, dass das kein Klartext-Protokoll ist, sondern im Wesentlichen Bytes/Binärdaten hin- und her geschubst werden. Nicht schwierig, wenn man's weiß, aber eben nicht so einfach mit Minicom zu machen.

Da ich aber nun die Doku in Händen halte, hab ich angefangen, ein Python Skript zu schreiben, um mit dem Instrument zu reden. Erste Versuche sind bereits erfolgreich verlaufen. D.h. ich kann inzwischen diverse Modi des Messgeräts aufrufen bzw. umschalten und ebenso Daten vom Gerät auslesen. Noch ist das Skript nicht fertig – ich muss noch alle Funktionen implementieren, einen Decoder für die Rohdaten schreiben, das Ganze ordentlich testen, eine brauchbare usage message einbauen etc. etc. Aber so wie ich das sehe, ist das nur noch Handwerk :-)

Aber hier schon mal ein paar Eindrücke. Die Unterhaltungen mit dem Instrument laufen immer nach dem gleichen Schema:

2 byte "Hello" senden: 0x87 0x83
1 byte Kommando senden - z.B. 0x7f (Range Umschaltung)

wenn es sich um ein Kommando zum Daten auslesen handelt kommt als Antwort ein binärer Blob zurück. Die Doku erklärt die Blobs so leidlich und diese können nun decodiert werden.

Hier mal ein Beispiel für so eine Antwort:

00000000  bb 88 00 07 06 08 26 15  36 23 01 00 00 02 01 00  |......&.6#......|
00000010  07 06 08 26 15 36 23 02  00 00 02 01 00 07 06 08  |...&.6#.........|
00000020  26 15 36 25 03 00 00 02  01 00 07 06 08 26 23 28  |&.6%.........&#(|
00000030  02 04 27 1d 01 01 00 07  06 08 26 23 28 04 05 27  |..'.......&#(..'|
00000040  1a 01 01 00 07 06 08 26  23 28 04 06 27 1c 01 01  |.......&#(..'...|
00000050  00 07 06 08 26 23 28 05  07 27 14 01 01 00 07 06  |....&#(..'......|
00000060  08 26 23 28 07 08 27 17  01 01 00 07 06 08 26 23  |.&#(..'.......&#|
00000070  28 10 09 01 37 01 01 00  07 06 08 26 23 28 12 0a  |(...7......&#(..|
00000080  27 02 01 01 00 07 06 08  26 23 28 14 0b 27 00 01  |'.......&#(..'..|
[...]

Schon mit bloßem Auge kann man sehen, dass sich hier regelhaft was zu wiederholen scheint – und so ist es auch: das sind die data records (je 12 byte). Zwischen den records kommt dann immer noch ein 0x01 als Trenner, auch  wenn die Doku dazu nichts zu sagen hatte. Das führende 0xbb 0x88 ist die ID des Datenblobs und bedeutet hier, dass es Daten aus dem Datenspeicher für manuelle Datenpunkte sind. Darin codiert sind Datum und Uhrzeit,  Messert und Statusinfo, um den Datenwert interpretieren zu können (z.B. Lux/FC, oder der Messbereich).

Sobald ich fertig bin, stelle ich das Skript mal hier rein. Ich bemühe mich es übersichtlich zu gestalten und gut zu dokumentieren, damit das Protokoll sich einfach erschließt.

Update: das Skript liegt nun auf Github.

Mehr Thinkpad Mysterien

Inzwischen habe ich den T440s nun schon eine ganze Weile. D.h ich habe mich gut eingewöhnt und er gefällt mir immer noch gut. Nur der Mangel an separaten Maustasten für den Trackpoint nervt gewaltig - ich bin einfach nicht der Touchpad-Typ. Und trotz der kleinen Software-Tricks, die ich beim letzten mal erwähnt hatte verrutscht der Maus-Cursor doch viel zu oft unbeabsichtigt beim Tippen, wenn man nicht höllisch aufpasst. Aber naja.

Die Tastatur ist trotz neuer Tastenform angenehm und ich habe mich leidlich an das neue Layout bezüglich der home/end/ins/del Tasten gewöhnt (auch nicht so gut wie früher). Einen Aspekt, der in diversen Foren bemäkelt wurde ist die neue Position der PrtSc-Taste, die nun zwischen AltGr und Ctrl. liegt.

Prt-was???? Ja diese Taste gibts wirklich. Traditionell liegt sie gemeinsam mit dem ebenso obskuren SysReq rechts neben F12 und oberhalb von Ins. Was die macht? Meist ist sie so belegt, dass man damit Screenshots machen kann. Waaaaahsinnig nützlich. Habe ich schon oft manchmal noch nie verwendet. Oh und einigermaßen dekorativ ist sie und trägt zum harmonischen Gesamtbild der Tastatur bei. Also völlig verständlich, dass die Netzgemeinde eine Revolution anzettelt, wenn Lenovo es wagt, eine so essentielle Taste willkürlich zu verlegen.

Unbill!

Aber was ist das? Wieso will der Compi meinen mühevoll geschriebenen Text nicht speichern? Was soll das heißen, die Datei könne nicht gespeichert werden und wieso read-only Filesystem?!? dmesg zeigt auch verdächtigen Kram an und erzählt was von r/o remount:

SysRq : Emergency Remount R/O
EXT4-fs (dm-1): re-mounted. Opts: (null)
EXT4-fs (dm-4): re-mounted. Opts: (null)
EXT4-fs (sdb1): re-mounted. Opts: (null)
Emergency Remount complete
EXT4-fs (dm-1): ext4_writepages: jbd2_start: 13312 pages, ino 657835; err -30
EXT4-fs (dm-1): ext4_writepages: jbd2_start: 13312 pages, ino 657835; err -30
EXT4-fs (dm-1): ext4_writepages: jbd2_start: 13312 pages, ino 657835; err -30
[...]

Geht da etwa die Platte über den Jordan? Soviel Pech kann man doch garnicht haben!?! Also erstmal ruhig Blut und neu starten. Mehrere Tage alles problemlos, doch dann passiert es wieder!

Als es dann zum dritten mal passiert ist eine merkwürdige Beobachtung: kurz zuvor ist noch ein Screenshot Window aufgegangen. Wieso das? Nach einigem Nachdenken, Googeln und Kopf gegen die Tischkante hauen die Erleuchtung:

Na klar! LINUX hat doch so praktische Tastenkombis für Notfälle – z.B. Alt+SysReq+s für ein Notfall-Sync oder Alt+SysReq+i für ein SigKill an alles außer init oder Alt+SysReq+u für ein Notfall RO-remount. Momentmal – was? 

Nun muß man wissen, dass ich in Sachen Computer etwas speziell bin und ein US-Layout bevorzuge. Und damit ich damit auch deutsche Umlaute hinkriege habe ich mir ein xmodmap File gebaut, in dem AltGr als Modeswitch Key belegt wird und ich also mit AltGr+u ein "ü" bekomme: 

! use Alt_R as Mode_switch key (AltGR)
keycode 108 = Mode_switch Mode_switch
[...]
keycode  30 = u U udiaeresis Udiaeresis
[...]

Sehr praktisch das! Außer man hat direkt neben der AltGr Taste eine PrtScr/SysReq Taste und löst mit seinen Wurstfingern versehentlich einen Alt+SysReq+u aus.

GRUMPF! Die Taste muss ich wohl lahmlegen.

Mal sehen, was für ein Mist mir als nächstes passiert ....

Thinkpad killing

In meinem letzten Post hatte ich ja voller Stolz von meinem neuen Thinkpad erzählt. Inzwischen haben sich ein paar Dinge ereignet, die meine Begeisterung etwas dämpfen. Kurz nach dem Post war das Ding tot – mausetot. Der freundliche Inder von der Lenovo Hotline konnte nicht helfen und so wurde das gute Stück eingeschickt und hat offenbar eine neues Motherboard bekommen. Heute war nun der große Tag, an dem ich das Gerät wieder entfenstert habe. Plattentausch ging wieder problemlos und die Debian-Installation war flugs erledigt. Doch als ich dann in das frische System booten wollte, kam die Ernüchterung: das Ding bleibt wieder beim Booten im Splashscreen stecken und ich komme nichtmal mehr ins BIOS Setup - genau wie beim letzen mal. Megagrumpf!

Das gibt's doch nicht! Wie kann das sein? Zweimal hintereinander?!? Ein wenig Web Recherche hat mir dann die Augen geöffnet - Lenovo hat offenbar das UEFI-boot Problem, das auch bei Samsung Laptops schon so manchen Brick verursacht hat in seinem BIOS noch nicht behoben! D.h. man kann sein Motherboard zerstören, indem man eine neue Platte einbaut, LINUX installiert oder wasweißichnoch. Wäre mir das bewusst gewesen, hätte ich offenbar durch geeignete BIOS-Settings (UEFI Boot komplett disabeln) vorbeugen können. Und irgendwann hätte man dann ein hoffentlich gepatchted BIOS flashen können ...

Im Nachhinein wird mir nun einiges klar: Beim ersten mal hatte ich im BIOS Setup UEFI und legacy boot zugelassen. LINUX lief einwandfrei und auch die getauschte Platte war kein Problem - bis zu dem Moment, als ich von einer externen Festplatte booten wollte und versehentlich den UEFI-Boot ausgewählt hatte. Diesmal hatte ich im BIOS noch gar keine Änderungen vorgenommen und so hat das Teil versucht, von der frisch installierten Platte im UEFI-Modus zu booten.

Also werde ich am Montag wieder mit dem freundlichen Inder telefonieren und UPS wieder neuen Umsatz bescheren...

Wo zum Geier ist der blöde Windows Product Key?

Nachdem mein Thinkpad T61p nun echt langsam sehr alt wird habe ich mir ein neues Notebook angeschafft: ein Thinkpad T440s.

• Intel Core i7-4600U CPU
• 12GB RAM
• 500GB Hard Disk
• 16GB NGFF SSD
• Intel/NVIDIA GeForce GT 730M Kombi; HDMI+VGA
• Full-HD non-glare TFT
• Ethernet, WLAN, WAN, Bluetooth
• 3xUSB3.0, SD-Card-Reader, Fingerprint-reader
• und natürlich mein geliebtes US-Tastaturlayout

Schöne Maschine, gefällt mir sehr - Ultrabook, aber mit Thinkpad-Tugenden. Zunächst habe ich erstmal die Platte getauscht: 500Gb raus 1.5 TB rein. Dann LINUX installiert (Debian Jessie). Auf dem Weg dahin hat es zwar ein paarmal gehakt, aber letztlich habe ich alles zum Laufen bekommen und mag die Kiste schon sehr gern. Eigentlich habe ich nur zwei Punkte die ich zu bemängeln habe:

• Wo sind die Maustasten für den Trackpoint geblieben???
  ohne die ist der TP fast nicht zu gebrauchen, denn wenn der Touchpad aktiv ist ist das Daumen-Tappen einfach zu unpräzise und der Mauszeiger rutscht einem weg. Das ist echt nicht toll gelöst!
• Es wurde im Netz schon viel über das neue Tastatur-Layout gemeckert. Insgesamt finde ich es nicht schlecht. z.b. hatte ich schon immer PageUp/Down auf die nutzlosen Forward/Back Tasten neben den Cursportasten gelegt und finde das total praktisch. Nur die Anordnung von Home/End/Insert/Delete ist echt nicht sehr ergonomisch. Da muss ich jedes mal innehalten und genau schauen, wo ich draufdrücken muss. Aber vielleicht schleift sich das ja bald ein...

Bezüglich des ersten Punkts  muss ich zugeben, dass das neue Riesen-Touchpad echt gut ist. Früher habe ich den Touchpad immer deaktiviert, weil ich ihn eh nicht brauchen konnte und er beim Tippen stört. Dieser ist aber echt nützlich und mittels synaptiks habe ich ihm beigebracht, inaktiv zu werden, sobald ich zu tippen anfange. So kann man ganz gut arbeiten.

Auf dem Rechner war ein Windows 8 64bit dabei. Nun will ich ja primär unter LINUX arbeiten. Das Windows kommt dann bei Gelegenheit in die Virtualbox. Damit habe ich es grade nicht eilig, aber ich wollte mir dafür schonmal den Product Key aufschreiben, damit ich ihn dann zur Hand habe. Nur wo ist der? Früher war der ja gewöhnlich in Form eines Aufklebers irgendwo auf dem Gehäuse zu finden. Offenbar hat sich das mit Win8 geändernt - jedenfalls konnte ich keinen finden. Etwas Suche im Netz bestätigte das und ich fand heraus, dass der Key nun im BIOS gespeichert sei. Toll - und wie finde ich den nun???

Zwar mangelt es nicht an guten Ratschlägen und kleinen Tools unklarer Herkunft wenn man aus einem laufenden Win8 System heraus den Key auslesen möchte, aber das hilft mir nun nicht wirklich weiter. Also weitersuchen - Microsoft dokumentiert das Verfahren im Dokument Microsoft Software Licensing Tables ausführlich. Bei der Gelegenheit habe ich gelernt, dass diese Methode schon seit Windows Vista unterstützt wird. In dem Dokument wird dargelegt, dass die entsprechende Information in speziellen ACPI-Tables namens SLIC und MSDM abgelegt wird. Der für uns hier relevante ist hier MSDM Table mit folgendem Aufbau:

  Offset  length    Description

  0       4         signature

  4       4         length

  8       1         revision

  9       1         checksum

  10      6         OEM ID

  16      8         OEM table ID

  24      4         OEM revision

  28      4         Creator ID

  32      4         Creator revision

  36      variable  Software licensing structure

Gut - aber wie komme ich da ran? Ich habe mal im Package manager gesucht:

> aptitude search "?description(ACPI tables)"
i A acpica-tools   - ACPICA tools for the development and debug of ACPI tables

Das klingt gut! Und diese Paket enthält unter anderem dies:

  acpidump - ACPI table dump utility

Das klingt perfekt! Und so fand ich dies:

    > sudo acpidump
  [...]
  MSDM @ 0x00000000BCE42000
  0000: 4D 53 44 4D 55 00 00 00 03 06 4C 45 4E 4F 56 4F  MSDMU.....LENOVO
  0010: 54 50 2D 47 4A 20 20 20 70 21 00 00 50 54 45 43  TP-GJ   p!..PTEC
  0020: 02 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00  ................
  0030: 00 00 00 00 1D 00 00 00 xx xx xx xx xx 2D xx xx  ........xxxxx-xx
  0040: xx xx xx 2D xx xx xx xx xx 2D xx xx xx xx xx 2D  xxx-xxxxx-xxxxx-
  0050: xx xx xx xx xx                                   xxxxx
  [...]

Voila - da ist er ja, der Key :-)

Nachtrag

Inzwischen habe ich noch einen zweiten, noch einfacheren, Weg entdeckt:

  > sudo hexdump -C /sys/firmware/acpi/tables/MSDM

Und wer weniger Wert auf Hexdump-Ästhetik legt, kann stattdessen auch einfach cat verwenden - weniger hübsch, aber in Sachen Product Key genauso geeignet.

FabLab Regensburg

Eigentlich wollte ich nur einen Dienstleister für einen kleinen Lasercutter-Auftrag finden (Sick of Beige Case Variante für meinen Bus Pirate) bin dann aber bei der Suche auf etwas viel Spannenderes gestoßen: Es gibt in Regensburg neuerdings ein FabLab! Und um den Zufall perfekt zu machen, war dort heute Tag der offenen Tür. Also habe ich spontan beschlossen mal hinzufahren und mir das anzusehen.

Trotz trübem Wetter waren eine Menge Leute gekommen und die Bude war entsprechend voll. An allen Stationen wurde gefachsimpelt, diverse Objekte bestaunt und einfach Erfahrungen ausgetauscht – ein recht buntes Völkchen hatte sich versammelt.

3D Printer

Das FabLab hat zwei 3D-Drucker: einen von Fabbster und (zu meiner großen Freude) einen Ultimaker 2. Letzteren habe ich nämlich schon eine Weile auf meiner persönlichen Wunschliste.

i

 

3D Scanner

Und damit die Drucker auch was zu tun haben gab es zwei 3D-Scanner. Einen für kleine Gegenstände:

Und einen größeren, basierend auf einer Kinect, mit dem heute Personen in 3D-Modelle verwandelt und anschließend ausgedruckt wurden:

Lasercutter

In der Ecke fand ich dann den Lasercutter, der gerade damit beschäftigt war, kleine Teile für Spielwürfel-Bausätze aus Sperrholz zu schneiden. Letztere fanden v.a. bei den zahlreich erschienenen Kindern großen Anklang.

Und da ich ein File für mein SickofBeige Gehäuse in der Hosentasche hatte habe ich mal diesen netten Herrn davon überzeugt, zwischendurch mal  was mit Acryl zu machen ;-)

Hier ist die Vorlage schon mal geladen:

Und hier ist der Cutter fleißig dabei, mein Gehäuse zu schneiden:

Fazit

Der kleine Ausflug hat sich gelohnt. Ich glaub, da geh ich öfter mal hin, wenn ich als Ergänzung zu einem Elektronikprojekt mal was geschnittenes oder gedrucktes brauche.

ISP-Adapter Wettrennen

Inzwischen haben sich in meiner Bastelkiste diverse AVR ISP-Adapter angesammelt und so bin ich auf den Gedanken gekommen, mal ein Wettrennen zwischen den Geräten zu veranstalten.

Die Kontrahenden

1. Atmel STK500
   Der Klassiker unter den AVR Evaluation boards. Auch als ISP zu gebrauchen.
   
2. Diamex/Stange ISP-PROG
   stk500v2 kompatibel und bisher mein Standard-Programmer. Mit 2 DIP-Switches kann man die Versorgungsspannung ein bzw. ausschalten und von 5V auf 3.3V umstellen.
   
3. Diamex ERFOS-PROG-S
   Ebenfalls stk500v2 kompatibel. Keine Spannungsversogung des Hosts. Signalpegel 3.3V. Er kann neben AVR auch STM32 und NXP/LCP µC programmieren und als USB2UART Adapter verwendet werden.
   
4. USBasp Chinaböller (mit modifizierter USBasp Firmware)
   Wie im letzten Post beschrieben: super kleiner und recht solider USBasp-clone mit kleinen Hardware-Differenzen. 5V Versorgungsspannung.
   
5. USBasp Chinaböller (mit stk500 firmware)
   gleiche Hardware wie 3. aber mit der stk500 Firmware des usb-avr-lab
6. Bus Pirate v3.6
   Das Schweizer Taschenmesser der digitalen Kommunikation. Eigentlich kein ISP Adapter, aber avrdude unterstützt ihn trotzdem – vermutlich in einer Art bitbanging mode.
   

Methode

Wir werden mit avdude den Flash Speicher eines Arduino Duemillanove auslesen, gegen das erhaltene File verifizieren und schließlich das Hexfile wieder in den µC flashen. Praktischerweise gibt avrdude auch gleich an, wie lang eine Operation gedauert hat. Für den ISP-PROG sieht das entsprechenede Kommando (read flash) dann so aus:

$ avrdude -p m328p -c stk500 \\
  -P /dev/ttyACM0 -U flash:r:foo.hex:r
avrdude: AVR device initialized and ready to accept instructions
Reading |###################################| 100% 0.02s

avrdude: Device signature = 0x1e950f
avrdude: reading flash memory:
Reading |###################################| 100% 6.34s

avrdude: writing output file "foo.hex"
avrdude: safemode: Fuses OK
avrdude done.  Thank you.

Ich habe jede Operation (r/v/w) mit jedem Programmer 3x ausgeführt und die Zeiten haben maximal in der letzten signifikanten Stelle um ± 1 differiert.

Die aktuell auf dem ATmege328p des Arduinos befindliche Firmware liefert ein raw-Hex File von 2280 Byte. Beim Lesen des Flash Speichers werden aber offenbar die kompletten 32kB des Controllers gelesen – daher die große Abweichung zwischen den verschiedenen Operationen.

Siegerehrung

Hier die Ergebnisse in absteigender Geschwindigkeit:

1. Diamex ERFOS-PROG-S
   read      2.9s  (11.3 kB/s)
   verify    0.2s
   write     0.28s  (8.14 kB/s)
2. Chinaböller (USBasp)
   read      5.25s  (6.24 kB/s)
   verify    0.37s
   write     0.46s  (4.95 kB/s)
3. Diamex/Stange ISP-PROG
   read      6.3s  (5.2 kB/s)
   verify    0.45s
   write     0.55s  (4.15 kB/s)
4. Chinaböller (stk500v2)
   read    17.7s  (1.85 kB/s)
   verify    1.24s
   write     3.56s  (0.64 kB/s)
5. Atmel STK500
   read      41.6s  (0.79 kB/s)
   verify     2.90s
   write      3.17s  (0.72 kB/s)
6. Bus Pirate
   read     126s  (0.26 kB/s)
   verify    8.5s
   write     9.0s  (0.25 kB/s)

Fazit

Das STK500 ist überraschend lahm in vergleich zu den diversen billig-Programmern. Als USBasp schlägt sich der Chinaböller ganz gut gegen den ISP-PROG, der ERFOS-PROG-S steckt beide in die Tasche. Sehr überraschend fand ich den enormen Geschwindigkeitsabfall den der Chinaböller erlebt, wenn man die stk500 Firmware des USB-AVRlab verwendet. Und über die Geschindigkeit beim Bus Pirate schweige ich lieber ;-)

Für den Hobbybereich ist die Geschwindigkeit natürlich komplett wurscht, aber interessant finde ich es dennoch. Der Chinaböller landet auf alle Fälle in meinem Bastelkit für unterwegs!