Community-Firmware für den TXT

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 09 Nov 2016, 11:25

ski7777 hat geschrieben:Da kommt mir noch eine allgemeine Idee. Für den DAU ist es knifflig die Debug ausgaben zu sehen. Wir könnten vielleicht die Ausgaben in einer Datei speichern und diese dann per Webinterface abrufen.
Das wäre in der Tat ganz nett. Ich denke mal drüber nach, wie man das elegant löst.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
Peterholland
Beiträge: 324
Registriert: 01 Nov 2010, 22:28
Wohnort: Poederoyen NL

Re: Community-Firmware für den TXT

Beitrag von Peterholland » 09 Nov 2016, 17:11

Hallo MasterOfGizmo,

Hast du vor Sonntag 20 November 2016 zum fischertechnik Modellschau in Munster zu kommen ?

Gruss,

Peter Poederoyen NL
Peter Poederoyen NL

Andy42
Beiträge: 20
Registriert: 05 Apr 2014, 18:42

Re: Community-Firmware für den TXT, Zugang über SSH

Beitrag von Andy42 » 09 Nov 2016, 20:13

Hallo,

ich hatte zuletzt nochmal versucht über ssh auf den TXT mit community-Firmware 0.9.2 zuzugreifen. Die Verbindung besteht über USB-Kabel, über einen web-Browser kann kann der web-service des TXT gesehen werden. Ssh klappte bislang jedoch noch nie. Der TXT scheint die Kommunikation zu verweigern. Wie unter "https://github.com/ftCommunity/ftcommun ... ord-policy" beschrieben sollte eigentlich beim Verbindungsaufbau auf dem Display des TXT gefragt werden, ob die angefragte ssh Verbindung zugelassen werden soll. Diese Anfrage ist auf dem Display jedoch nicht zu sehen. Interessant dabei war, dass über die irgendwie gleichzeitige Erstellung eines screen shots über die web-browser Verbindung genau diese Anfrageseite gezeigt wurde. Somit vermute ich, dass deshalb der ssh Zugang nicht klappt, weil die Seite auf dem TXT zwar erzeugt wird, allerdings nicht angezeigt wird weil ein screen-refresh oder sowas fehlt ... oder so...

Gruß
Andy42

Hompi
Beiträge: 40
Registriert: 01 Nov 2014, 22:23

Re: Community-Firmware für den TXT

Beitrag von Hompi » 09 Nov 2016, 20:40

MasterOfGizmo hat geschrieben:
ski7777 hat geschrieben:Da kommt mir noch eine allgemeine Idee. Für den DAU ist es knifflig die Debug ausgaben zu sehen. Wir könnten vielleicht die Ausgaben in einer Datei speichern und diese dann per Webinterface abrufen.
Das wäre in der Tat ganz nett. Ich denke mal drüber nach, wie man das elegant löst.
Hallo Jungs,

dann zähle ich erst einmal wohl zur DAU-Fraktion :( . Ich habe jetzt auf die Schnelle die gewünschten Debug Dateien nicht erzeugen können.
Ich habe allerdings noch den ein oder anderen Test in verschiedenen Beleuchtungsumgebungen gemacht. Es scheint so, dass keine konkrete Unterscheidung zwischen gelb und orange stattfindet. Auf den Calib. Screen des TXT kann man zwischen den beiden Farben kaum einen Unterschied erkennen.
Ich komme vor dem Wochenende nicht dazu die Debug Datenthematik nochmals zu versuchen.
Ich setzte den Speed Cube Ultimate (weiss) ein.....

https://www.cubikon.de/speedcubing/3x3x ... ss/a-1095/

Gruss Jürgen

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 09 Nov 2016, 22:29

Ich denke, dass ich das mit dem Debug-via-Browser recht elegant hinbekomme. Allerdings für die nicht-Hacker dann erst mit dem nächsten Update.

Das mit dem unsichtbaren Dialog ist merkwürdig. Ich habe ihn bisher aber auch noch nicht live gesehen. Ich kann mich als ftc-User ohne Passwort einfach per SSH anmelden. Aber meines Verständnisses nach sollte da der Dialog auch nicht kommen. Vielleicht mag da mal jemand das Wiki nach pflegen mit Anleitung und ein paar Screenshots.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 10 Nov 2016, 14:49

Peterholland hat geschrieben: Hast du vor Sonntag 20 November 2016 zum fischertechnik Modellschau in Munster zu kommen ?
Hi, nein, sorry.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 10 Nov 2016, 14:52

Hompi hat geschrieben:Ich habe jetzt auf die Schnelle die gewünschten Debug Dateien nicht erzeugen können.
Ich habe allerdings noch den ein oder anderen Test in verschiedenen Beleuchtungsumgebungen gemacht.
Ich habe zwar ein paar (ca. 10) Stunden in die Console-Debug-Sachen gesteckt, aber das wirst Du ja auch nicht eindach so auf Deinen TXT bekommen, ohne dass wir ein komplettes neues Release machen.

Ich denke es macht Sinn, wenn Du Dich an der SSH-Verbindung nochmal versuchst. Wenn wir wissen, wo Dein Problem dabei liegt hilft das sicher auch anderen.

Alternative: Du schickst mir genau so einen Würfel wie Du ihn benutzt und ich schaue, was sich machen lässt. Der sieht meinem allerdings recht ähnlich.

Auf dem Calibration-Bildschirm sollten die Farben gut zu unterscheiden sein. Dort sind nicht die Farben dargestellt, die die Kamera sieht, sondern die, die das Programm erkannt hat. Wenn es also meint orange erkannt zu haben, dann malt es die Pixel in seinem eigenen Orange. Orange gelb und rot sollten dabei eigentlich klar zu unterscheiden sein. Wenn die Erkennung knapp daneben liegt dann sieht man Pixel unterschiedlicher Farbe in einem Quadrat. Das heisst, dann, dass die Farbe des nicht eindeutlg erkannt wurde und man kann sehen, welche Pixel er in welcher Farbe erkannt hat. Ich mache ggf. nachher ein paar Fotos als Beispiel.

Dreh mal so, dass Du alle Farben auf einer Seite gleichzeitig hast und lass ihn das dann erkennen. Ich mache das auch mal und zeige dann hier ein Bild davon. Das Licht sollte recht weiss sein. Indirektes Sonnenlicht oder Halogenlicht sind am besten. Energiesparlampen sind problematisch. Und die Kamera darf natürlich keine Schatten auf den Würfel werfen (also kein Licht direkt von hinten) und es sollte sich auch die Lichtquelle nicht im Würfel spiegeln.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 10 Nov 2016, 21:10

Ich habe mal zwei Screenshots gemacht. So sieht es unter gutem weissen Licht aus:

Bild

und so unter einer warmweissen Energiesparlampe. Man sieht, dass er orange als rot erkennt und dass sich auch in die Erkennung der übrigen Farben hier und da ein paar Fehler einschleichen. Er nimmt dann am Ende die Farbe, die er für ein Feld am häufigsten erkannt hat, aber das ist bei so Grenzfällen ggf. auch mal falsch.

Bild
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 10 Nov 2016, 21:24

Auch diese Debug-Hilfe gibt es nun. Sie befindet sich aber erstmal nur im Repository und wird mit 0.9.3 für alle kommen.

So sieht das dann im Browser aus, wenn man z.B. die Rubiks-Cube-App startet. Was man sieht sind die ganz normalen Ausgaben, die die App per "print" macht. Also genau das, was man normalerweise als Linux-User irgendwo im Terminalfenster als Ausgabe hätte. Die eigentliche App läuft dabei auf dem TXT wie üblich. Man sieht dort keinen Unterschied. Man würde aber z.B. auch Python-Fehlermeldungen via Webbrowser sehen.

Bild
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
ski7777
Beiträge: 870
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Community-Firmware für den TXT

Beitrag von ski7777 » 10 Nov 2016, 22:16

STOP Nicht nachmachen
Kurz getestet und dann...
Der TXT fährt nicht mehr herunter :(
Fehlermeldung:

Code: Alles auswählen

Stopping DHCP server: OK
Stopping sshd: OK
Stopping lighttpd: OK
Stopping ntpd: OK
Stopping network: ifdown: interface eth0 not configured
FAIL
Stopping system message bus: done
Saving random seed... done.
Stopping thd: OK
Stopping logging: OK
umount: /dev/mmcblk0p1 busy - remounted read-only
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system poweroff
[   74.216273] reboot: Power down
[   77.397270]
[   77.399065] =====================================
[   77.404108] [ BUG: init/1188 still has locks held! ]
[   77.409416] 4.1.33 #5 Tainted: G        W
[   77.414215] -------------------------------------
[   77.419195] 1 lock held by init/1188:
[   77.423048]  #0:  (reboot_mutex){+.+.+.}, at: [<c0060084>] SyS_reboot+0x12c/0x1d8
[   77.431042]
[   77.431042] stack backtrace:
[   77.435661] CPU: 0 PID: 1188 Comm: init Tainted: G        W       4.1.33 #5
[   77.443008] Hardware name: Generic AM33XX (Flattened Device Tree)
[   77.449485] [<c00153c8>] (unwind_backtrace) from [<c0013108>] (show_stack+0x10/0x14)
[   77.457679] [<c0013108>] (show_stack) from [<c003fac0>] (do_exit+0x5e0/0xb30)
[   77.465226] [<c003fac0>] (do_exit) from [<c0060090>] (SyS_reboot+0x138/0x1d8)
[   77.472772] [<c0060090>] (SyS_reboot) from [<c000f520>] (ret_fast_syscall+0x0/0x54)
Jemand eine Idee? Habe ich vielleicht vergessen den Alerm zu quittieren?
Auch

Code: Alles auswählen

echo 0 > /sys/class/rtc/rtc1/wakealarm
hilft nicht mehr.
So muss ich jetzt immer das Netzteil ziehen oder gefühlt jahre auf den Knopf drücken.

@ft (@Markus Burkhardt): Rettungsidee?

Raphael
----------Normaler Teil----------
Ich habe mal etwas gespielt mit der RTC (RealTimeClock(Echtzeituhr)) des TXT und tada... :D :D :D
Er bootet von ganz alleine. :ugeek:

Hier mal mein Basis-Script (rtc.sh):

Code: Alles auswählen

#!/bin/sh
echo 0 > /sys/class/rtc/rtc1/wakealarm
echo Current: $(cat /sys/class/rtc/rtc1/since_epoch)
echo Waking at: $(expr $(cat /sys/class/rtc/rtc1/since_epoch) + $1)
echo $(expr $(cat /sys/class/rtc/rtc1/since_epoch) + $1)  > /sys/class/rtc/rtc1/wakealarm
echo Actual wake time: $(cat /sys/class/rtc/rtc1/wakealarm)
Aufruf dann so:

Code: Alles auswählen

sudo sh rtc.sh 50
Auf Deutsch: Der TXT wird in 50 Sekunden ganz von alleine booten.

Ich würde das ganze gerne in die Firmware einbauen. Damit könnte man z.B. einen Datenlogger bauen oder nach einem Update den TXT automatisch booten.

Raphael

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 11 Nov 2016, 07:58

Nimm mal die Puffer-Batterie des rtc raus während er aus ist und lass ihn entwerder einige Minuten ohne Batterie und aus liegen oder schliesse die beiden Batterieanschluesse am Batteriefach im tXT ein paar Sekunden kurz waehrend die Batterie draussen ist.

Zur Not misst du halt den Zustand der Wake-Leitung im TXT mal nach. Schalltplaene hast du ja.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
ski7777
Beiträge: 870
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Community-Firmware für den TXT

Beitrag von ski7777 » 11 Nov 2016, 08:01

Das werde ich später mal versuchen, aber das ist nicht mein langfristiger Plan.

Raphael

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 11 Nov 2016, 09:13

ski7777 hat geschrieben:Das werde ich später mal versuchen, aber das ist nicht mein langfristiger Plan.
Ich bin mir ja halbwegs sicher, dass Du nicht weisst, was Du da eigentlich tust. Dass der RTC ein Wakeup-Register hat hast Du bemerkt, ja. Aber ich nehme nicht an, dass Du Dir angeschaut hast, was da elektrisch im TXT passiert und ob das ggf. einen Grund hat, dass FT/Knobloch das in der Originalfirmware nicht nutzt. Von daher halte ich das Wort "Plan" an dieser Stelle zunächst für etwas hoch gegriffen. Und auch Deinen Anleitungen solltest Du generell mit dem Zusatz versehen, dass Du nicht weisst, was Deine Kommandos genau bewirken und dass die Leute generell etwas Vorsicht beim Nachmachen walten lassen sollten.

Ich habe gerade etwas im Schaltplan geschaut. Das Wake-up-Signal findest Du auf Pins 35 bzw 36 des Verbindungssteckers zwischen den beiden Platinen des TXT ("gespiegelte" Pins, weil der Stecker auf der einen Platine ja nach unten zeigt). Das Signal kommt vom PMIC (http://www.ti.com/product/TPS65910) und geht unter anderem an den Sitara und schaltet halt relativ direkt das Enable-Signal des Schaltwandlers für die 5V-Schiene (http://www.onsemi.com/pub_link/Collateral/NCP3170-D.PDF). Ich nehme nicht an, dass Du Dir davon irgendwas angeschaut hast, oder?

Aber wenn Du genau heraus gefunden hast, was da wann warum schaltet und dass das was Du da tust so ok ist, dann wäre es cool, wenn Du das im Wiki dokumentierst.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
ski7777
Beiträge: 870
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Community-Firmware für den TXT

Beitrag von ski7777 » 11 Nov 2016, 09:19

Erst durch das Angucken des Plans kam ich auf dir Idee nit dem Wake on RTC.

Mein Kenntnisstand:
Normaler Boot: Taster macht Stromversorgung an und gibt über den einen Pin dem Prozessor das Signal zum booten.

RTC Wake: Der PowerManagementChip macht den Strom an und bootet die CPU über INT1(siehe Datenblatt).

Oder liege ich da falsch??

Raphael

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 11 Nov 2016, 11:22

Nee, ganz so funktioniert das nicht. Such dir die Datenblätter im Internet. Da steht das alles drin.

Edit: Ausßerdem ist Dein Problem ja das Aus- und nicht das Einschalten, wenn ich Dich recht verstehe. Das ist alles auf Schaltplan Blatt 1/4 unten links. Vielleicht magst Du Dir den Teil mal von Deinem Physiklehrer erklären lassen. Man sieht dort, wie die diversen Komponenten die Ein- bzw.- Ausschaltsignale erzeugen.

Wie sicher bist Du Dir denn, dass Du gleichzeitig nicht noch irgendwas anderes verstellt hast? So ganz sehe ich den Zusammenhang nämlich noch nicht. Wenn der RTC dauerhaft das On-Signal erzeugen würde, dann könnte nämlich meines Verständnisses nach auch einer langer Druck auf den Power-Knopf nicht abschalten. Aber wie gesagt, geh' den Schaltplan doch mal mit deinem Physiklehrer durch. Ist bestimmt ganz interressant.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
ski7777
Beiträge: 870
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Community-Firmware für den TXT

Beitrag von ski7777 » 11 Nov 2016, 12:11

Nein, leider nicht.

Da musst du ganz lieb bei den richtigen Leuten Fragen.

Raphael

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 11 Nov 2016, 16:05

ski7777 hat geschrieben: Da musst du ganz lieb bei den richtigen Leuten Fragen.
Wenn sie die offiziell verteilen würden hätten sie wohl eine ganze Menge solcher Support-Fälle. Das kann ich durchaus verstehen, dass sie das lieber vermeiden wollen.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Community-Firmware für den TXT

Beitrag von richard.kunze » 11 Nov 2016, 23:18

ski7777 hat geschrieben: Fehlermeldung:

Code: Alles auswählen

Requesting system poweroff
[   74.216273] reboot: Power down
[   77.397270]
[   77.399065] =====================================
[   77.404108] [ BUG: init/1188 still has locks held! ]
[   77.409416] 4.1.33 #5 Tainted: G        W
[   77.414215] -------------------------------------
[   77.419195] 1 lock held by init/1188:
[   77.423048]  #0:  (reboot_mutex){+.+.+.}, at: [<c0060084>] SyS_reboot+0x12c/0x1d8
[   77.431042]
[   77.431042] stack backtrace:
[   77.435661] CPU: 0 PID: 1188 Comm: init Tainted: G        W       4.1.33 #5
[   77.443008] Hardware name: Generic AM33XX (Flattened Device Tree)
[   77.449485] [<c00153c8>] (unwind_backtrace) from [<c0013108>] (show_stack+0x10/0x14)
[   77.457679] [<c0013108>] (show_stack) from [<c003fac0>] (do_exit+0x5e0/0xb30)
[   77.465226] [<c003fac0>] (do_exit) from [<c0060090>] (SyS_reboot+0x138/0x1d8)
[   77.472772] [<c0060090>] (SyS_reboot) from [<c000f520>] (ret_fast_syscall+0x0/0x54)
Jemand eine Idee?
Der Kernel mag nicht stoppen, weil etwas (genauer: der Prozess mit ID 1188) einen Mutex (d.h. eine Sperre, das Wort ist abgeleitet von "mutual exclusive [lock]") hält der dafür sorgt, dass jeweils nur genau ein Prozess/Thread gleichzeitig das System stoppt/neu startet (deshalb heißt der auch "reboot_mutex").

Schritt Nummer eins ist daher, herauszufinden welcher Prozess das ist. Was die Sache etwas komplizierter macht ist, dass man das im Nachhinein (nachdem alle Prozesse gestoppt wurden und der Kernel eigentlich den Strom abschalten will) natürlich schlecht kann.

Was Du machst ist also Folgendes:
  1. Du loggst Dich per SSH auf dem TXT ein und rufst das Kommando "ps" auf. Die Ausgabe hebst Du auf.
  2. Du fährst den TXT herunter und schaust nach, welche PID den reboot_mutex hält (die PID findest Du in der Fehlermeldung)
  3. Du suchst diese PID in der Ausgabe von "ps" und postest die zugehörige Zeile hier (nebenbei versuchst Du natürlich, selbst herauszufinden warum genau dieser Prozess wohl den Reboot-Mutex anfordert und nicht mehr hergibt).
Danach sehen wir dann weiter.

Wenn Du das gemachst hast, dann probierst Du mal ob MoG's Idee funktioniert, den RTC-Chip stromlos zu schalten um was-auch-immer du an der RTC verstellt hast wieder rückgängig zu machen. Und teilst uns das Ergebnis hier ebenfalls mit.

Wenn das funktioniert, dann mache ich das Experiment hier auch mal (das dürfte das Debugging beschleunigen). Wenn nicht, dann lasse ich da die Finger davon (zumindest so lange, bis ich weiß, was genau der RTC-Wakeup mit dem System anstellt).

Ansonsten: Prinzipiell eine gute Idee. Wenn das mal sorgfältig getestet ist (und klar ist, was genau dabei passiert, und dass das alles wirklich harmlos ist) dann kann man das auch in die Firmware übernehmen.

Edit: Nach etwas Schaltpläne, Sourceode und Datenblättern wälzen denke ich, ich weiß was da los ist. Wenn ich damit richtig liege, dann sollte zum einen MoG's Rat mit dem stromlos schalten des PMIC funktionieren, und zum anderen ein ganz bestimmter Prozess (welcher verrate ich jetzt mal nicht 0:-)) den reboot_mutex halten. Mal sehen ob Du auch selbst draufkommst was da passiert, und wie man das dann lösen könnte - ist eine gute Übung im Debugging.

TiniTech
Beiträge: 77
Registriert: 07 Jan 2016, 10:30
Wohnort: Hamburg

Re: Community-Firmware für den TXT

Beitrag von TiniTech » 12 Nov 2016, 13:19

An dieser Stelle erst mal (wieder): Vielen Dank an MoG und Richard, mit welcher Ruhe und welch großem Engagement ihr hier auf wirklich alles eingeht und jeden bei jedem (Um-)Weg unterstützt.

Mittlerweile ist dieser Thread doch recht lang geworden und es mischen sich zahlreiche Themen (ftc-Firmware-DIskussion; Rubiks-Cube-Solver, RTC-gesteuerter Reboot, App-Ideen, etc.).
Ich sehe die Gefahr, dass da viele gute Hinweise untergehen, weil sie nicht recht gefunden werden bzw. die passende Antwort erst nach einigen Posts zu anderen Themen kommt.

Wäre es da nicht besser, ein weiteres Forum "fischertechnik > Computing / TXT-Community-Firmware" anzulegen, in dem dann einzelne Themen/Threads aufgemacht werden könnten? (neben dem Forum "fischertechnik > Robo Pro / Computing / Software", das ich dann umbenennen würde in "fischertechnik > Computing / RoboPro / Software")?

Was meint ihr?

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 12 Nov 2016, 13:32

Wenns pressiert könnte man ja auch erstmal einfach hier mehrere Threads starten. Für ein eigenes subforum reicht es m.E. noch nicht.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Antworten