Archiv verlassen und diese Seite im Standarddesign anzeigen : Board für komplexes (?) Projekt gesucht
FlyRider
17.01.2016, 17:04
Hallo,
ich bin totaler Anfänger und habe aber dummerweise die fixe Idee, folgendes realisieren zu wollen: Ich such ein Board, an dem ich
a) einen Joystick als Eingabegerät betreiben kann
b) eine halbwegs präzise IMU (Messung Drehen, Nicken) anschließen kann
c) 2 Drehzahl - Sensoren auswerten
d) 3 Stellmotoren (z.B. Modellbau Servos o.ä.) anschließen kann
Das Ganze soll programmierbar sein (wie ist egal, Programmieren ist als gelernter Informatiker das einzige, was ich kann ;) ), Debuggen soll natürlich gehen und eine Speicherkarte und/oder USB Speicher für Messdaten sollte auch noch drauf passen bzw anschließbar sein. Halbwegs Rechenleistung wäre nicht schlecht. Connectivity a la WIFI, NFC, Bluetooth usw. ist nicht unbedingt notwendig, wäre aber nicht schlecht.
Sorry für diese vielleicht etwas naive Frage, aber wenn ich Google seh ich den Wald vor lauter Bäumen nicht!!!! Wusste gar nicht, dass es SOOOO viele Boards gibt ... :(
Danke vorab
Stefan
hallo,
klarer Fall:
Als Anfänger braucht du eine einfache Programmier-Umgebung, aber schon "richtiges" C und mit vielen Pins und mit ziemlich ausreichendem Speicher:
Den Arduino Mega!
Den gibt's als China-Klon bei Ebay für unter 10 EUR, original irgendwas um die 20.
Achte bei Klonen auf einen kompatiblen ATmega16U2 USB-Bootlader-Chip.
z.B. den hier:
http://www.ebay.de/itm/SainSmart-Mega-2560-R3-ATmega2560-16AU-ATMEGA16U2-USB-Cabe-For-Arduino-DE-/221993823561?hash=item33afdced49:g:5z0AAOSwyQtV1pa J
Aber frage 3 Leute und du kriegst 4 Antworten ;)
Rabenauge
17.01.2016, 21:14
Hier sollte es schon ein Uno tun.
FlyRider
17.01.2016, 21:39
Hier sollte es schon ein Uno tun.
Uno steht vermutlich für "Ardurio Uno", oder? Wobei ich sofort das hochwertigere Board nehmen würde, weil es bei dem Projekt auf 10 Euro mehr oder weniger nicht ankommt.
Übrigens: was Programmierung angeht hab ich kein Problem, ich programmier schon seit 25 Jahren C,C++,C#, Java, usw. Dass es sowas schon für unter 10 Euro gibt, hätte ich nicht gedacht.
Gibt es eine Empfehlung für eine dazu passende IMU?
Merci
Stefan
redround
17.01.2016, 22:49
Alternativ lohnt auch ein Blick auf den Raspberry Pi. Der läuft mit Linux und ist schon nahe dran an einem PC. Oder wenn Du für die Zukunft extra viele Pins brauchst, dann vielleicht auch ein DigiX ... dar hat 99 I/O Pins und z. B. Wlan schon mit an Bord. Programmiert wird er auch mit der Arduino IDE und damit einfach zu erlernen. Alternativ kann er aber auch über JTAG programmiert /debuggt werden.
rpi lohnt sich meiner meinung nach nicht,
uno oder micro wäre wahrscheinlich das beste.
Rabenauge
18.01.2016, 12:06
Ja, ich meine den Arduino Uno.
Der hat mehr als genug Pins für das Vorhaben, du kannst also durchaus noch einiges hinzufügen.
Aber wenns nicht drauf ankommt-nimm ruhig den Mega 2560, der bewältigt noch ganz andere Aufgaben.
Ansonsten verhält er sich im wesentlichen Identisch zum UNO, hat aber eben viel mehr rausgeführe Pins (<50), und auch bedeutend mehr Speicher.
IMU's gibts mehrere- schau mal bei Ebay nach MPU 6050, das ist ein dreiachsiges Gyroskop mit dreiachsigem Beschleunigungsmesser.
Davon gibts auch eine "9DoF"-Version, die hat dann noch nen dreiachiges Magnetometer drauf.
Kosten beide nicht viel..meine 6050 kam sicherlich weniger als 10€.
Die Dinger lassen sich auch problemlos anschliessen, meist per I2C, und es gibt sogar einige fertige Bibliotheken für Arduino dafür.
FlyRider
18.01.2016, 16:16
Danke mal an alle soweit für die Hilfe! Wie gesagt - ich tappe als Laie etwas im Dunkel.
Momentan schwanke ich noch zwischen der Raspberry und Arduino Schiene. Dabei würde ich auf "bigger ist better" setzen, ob das Board nun 30 oder 50 Euro kostet, ist für das Projekt echt egal (nicht weil ich im Geld schwimme, sondern weil das gemessen an den Geamtkosten nicht sooo in's Gewicht fällt).
Nachdem ich nicht viel Ahnung habe, wäre mir eine "out of the box Kombi" ganz recht, ich hatte z.B. an
Raspberry Pi + "raspberry sense hat" + Pi face + display für das Raspberry Pi
gedacht, falls das in der Kombination überhaupt geht und das "raspberry sense hat" zur 3 Achs Kontrolle taugt .
Alternative wäre z.B. die von Rabenauge vorgeschlagene Kombi.
wenn du schon mit einem Raspi liebäugelst (ARM quadcore, 900MHz, 1GB RAM), dann ist ein Uno (AVR, 16MHz, 2kB RAM) keine gleichwertige Alternative.
Eigentlich noch nicht mal ein Mega (AVR, 16MHz, 8kB RAM).
Der Due ist dann schon eher eine Alternative (ARM Cortex, 84MHz, 96kB RAM).
Bezüglich des Unos würde ich definitiv abraten, denn 2kB ist mehr als mager, und wenn du dabei ein Hardware-SPI-Displays einsetzt, brauchst du für das SPI allein 1/4 davon (512 bytes) als Puffer - da kommst du schnell an die Arbeitsspeichergrenzen für dein Programm.
Also:
wenn schon, dann minimal (!) einen Mega, dann hast du wenigstens noch ein bisschen Reserven im Rücken.
Wenn du dich aber mit Linux gut auskennst, spricht ntl auch nichts gegen den Raspi + Sense Hat etc.
FlyRider
18.01.2016, 18:21
wenn schon, dann minimal (!) einen Mega, dann hast du wenigstens noch ein bisschen Reserven im Rücken.
Wenn du dich aber mit Linux gut auskennst, spricht ntl auch nichts gegen den Raspi + Sense Hat etc.
Wie gesagt: lieber zu groß als zu klein. Mit Linux bin ich vor 20 Jahre so zu sagen groß geworden - mal sehen, was davon noch übrig ist...
Ich bin mir halt nicht sicher, wie ein Board mit OS bzgl. Echtzeitverarbeitung abschneidet, ob da nicht ein "reiner Controller" ohne OS besser wäre. Gibt es denn echtzeitfähige OS Varianten für den Raspi?
Hat hier jemand Erfahrung mit der Sense Hat? Ist das eine vollwertige IMU?
DANKE für eure Hilfe!!!!
ich habe schon etwas an Erfahrung mit schnellen Pin-Abfragen, und was das angeht: lass die Finger vom Raspi.
Der hat nur 2x Hardware-PWM (allerdings etwas holpriges Software-pwm auf allen Pins), dennoch sind Echtzeit-Encoder-Abfragen direkt nicht möglich (>1000 Flanken pro sec.) - langsame Encoder klappen.
Auch die Kommunikation vom HAT oder Sensor-Shield zum Raspi hin und her ist begrenzt.
Dann also lieber keinen Raspi, sondern eher einen Due, der kann immerhin auch Multitasking.
FlyRider
18.01.2016, 19:10
ich habe schon etwas an Erfahrung mit schnellen Pin-Abfragen, und was das angeht: lass die Finger vom Raspi.
Der hat nur 2x Hardware-PWM (allerdings etwas holpriges Software-pwm auf allen Pins), dennoch sind Echtzeit-Encoder-Abfragen direkt nicht möglich (>1000 Flanken pro sec.) - langsame Encoder klappen.
Auch die Kommunikation vom HAT oder Sensor-Shield zum Raspi hin und her ist begrenzt.
Dann also lieber keinen Raspi, sondern eher einen Due, der kann immerhin auch Multitasking.
Fällte der Raspi damit für "kritische" Steuerungen aus? Immerhin gibt es ja einige Quadcopter Implementierungen usw.
Oder gleicht der das durch pure Rechenpower wieder aus?
die Frage ist lediglich, wo "kritisch" anfängt. Vieles kann man outsourcen auf Shields, die komplexe Arbeiten (den "Dreck" halt ;) ) autonom erledigen, die nächste Frage ist aber dann, wie schnell die (Zwischen-) Ergebnisse wieder auf dem Raspi sein müssen. Wenn also "sehr" zeitkritisch, dann geht es zumindest mit Linux im Userspace nicht mehr absolut sicher. Ein Kenner der Materie sagte mal sinngemäß im englischen Raspi-Forum:
wenn man was im 200µs-Takt braucht, kann das klappen, vielleicht auch schneller, vielleicht aber auch erst nach 400µs.
Auch ist es mit dem Auslesen der Pins ja vllt noch nicht getan (das geht per pigpio angeblich im 5µs-Takt) - wenn sie dann auch noch im 100µs-Takt weiterverarbeitet werden müssen (wie Quadratur-Encoder), dann geht das eben NICHT mehr in "Echtzeit". Linux hat viel zu viele Parallel-Tasks und Demons und Event-Watcher laufen, auf die du keinen Einfluss hast.
Das Propeller-HAT z.B. ist schon ne gute und schnelle Sache, hat Treiber für Python, aber nicht für C - und Python ist auch nicht gerade für Schnelligkeit und Echtzeitfähigkeit bekannt.
Echtzeitfähigkeit erfordert entweder ein RTOS (wie OSEK) oder ARM-bare-metal-Programmierung: beides geht auf Raspi (oder Arduino), aber eben nicht mit Linux.
(nach meinigem jetzigen Kenntnisstand, aber ohne Gewehr^^)
ps,
ich habe 4 Encoder auf einem B+ getestet, da ging es nicht.
Die Tests auf meinem neuen 2B stehen noch kurz bevor.
FlyRider
18.01.2016, 19:36
Hallo HaWe,
erstmal Merci für die Mühe die du / ihr euch hier gebt!!!
Mein Problem ist (glaub ich), dass man als reiner PC Jünger erstmal bei 84 MHz und ein paar Kilobyte Speicher das Muffensausen bekommt. Sowas kennt man ja gar nicht mehr (gibt es auch Programmlogik mit weniger als 10 Megabyte RAM :confused: ??) Ich möchte abhängig von einem Joystick und einer Lagekontrolle (IMU) zwei Verbrennungsmotoren regeln. Die sind natürlich sehr träge und müssen via PID Regler o.ä. angesprochen werden. Dabei wäre es auch noch schön, wenn mir ein Display ein paar Daten (z.B Drehzahl) anzeigen würde. Ich muss auch die Drehzahl der beiden Motoren kennen, damit ich richtig reagieren kann. Schön wäre auch noch eine Warnung, falls die EGT (Exhaust Gas Temperature) eines Motors einen kritischen Wert überschreitet - das kann einen Zweitakter schlagartig killen....
Nun ist die kritische Frage, ob ich das mit dem Arduino Due z.B. hinbekomme, oder ob mal dazu die Power des Raspi braucht - bei dem wiederum frag ich mich, wie von dir schon angedeutet, ob ein OS mit den tausend Prozessen drauf das Richtige ist...
der Raspi hat nicht mehr Power, wenn es um Pins geht - und was die nackte Rechnerei angeht, bist du mit einem Due bereits äußerst komfortabel aufgestellt!
Hier habe ich einen Benchmarktest für verschiedene Boards, auch da erkennst du, dass ein Due recht schnell ist.
http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095#p64772
Und an die RAM-Grenzen bin ich mit dem Due erst gekommen, als ich autonome mehrschichtige rekurrente Neuronale Netze damit programmiert habe ;)
Was die 9DOF IMUs angeht:
nimm lieber den hier, der macht alles onboard, inkl. Kalman:
http://www.mindstormsforum.de/viewtopic.php?f=78&t=8491&start=15#p67401
FlyRider
18.01.2016, 19:56
Hi HaWe,
ich bin eh schon geplättet :)
Ne, ernsthaft: Ich denke, ich werd mir mal so ein Board bestellen und mich in die Basics einarbeiten. Zuvor aber noch mal eine (wahrscheinlich?) triviale Frage: wie bekomme ich einen Joystick an den Arduino, geht das komfortabel via USB o.ä oder muss man da basteln??
es gibt kleine analoge Widerstands-Joysticks.
Ansonsten können externe Joysticks über die entspr. Schnittstelle abgefragt werden (UART, i2c...), aber das hängt von der speziellen Art ab - eine universelle Lösung gibts da nicht.
USB als Input ist eher schwierig beim Due.
http://www.ebay.de/sch/i.html?_from=R40&_trksid=p2060353.m570.l1313.TR1.TRC0.A0.H0.XArduin o+Joystick.TRS0&_nkw=Arduino+Joystick&_sacat=0
redround
18.01.2016, 20:05
Was mich wieder zum DigiX bringt. Gleiche Basis wie der DUE, dafür mehr Pins und WLAN bereits onboard. Gut die zusätzlichen Pins fallen jetzt in dem Fall nicht ins Gewicht - aber alleine schon die WLAN Integration reduziert die Komplexität, wenn sie einem schon abgenommen wird. Ein Shield weniger, um das man sich Gedanken machen muss. Aber Vorsicht: sowohl der DUE als auch der pin- und softwarekompatible DigiX laufen auf 3,3Volt. Das muss man bei der Shield- / Peripherie-Auswahl auf alle Fälle berücksichtigen
stimmt, eindeutig. Wenn man den mit der Arduino-IDE und den Myriaden an fertigen Arduino-libs verwenden kann: ein absolutes GO!
Im Zweifel aber sonst vlt doch lieber die Arduino-Hardware für die Arduino-IDE (für ARM-Programmier-Anfänger).
FlyRider
18.01.2016, 20:19
Die "original Arduino Welt" scheint halt schon recht umfangreich zu sein: IDE, viele Bauteile / Erweiterungen, Tutorials usw. - was für mich sehr wichtig ist!
Mit den kleinen 2-Achs Joysticks kann ich auch prima leben, passt also!!! WLAN wäre nett, brauche ich aber nicht unbedingt.
ein ähnliches Problem wie dein beschriebenes wird auch für die Fischertechnik-Controller TX und TXT berichtet:
Der alte TX (200 MHz ARM9: langsamerer Takt, aber OHNE Linux)
ist bei timer-getriggerten Tests schneller als der
neue TXT (600MHz ARM Cortex A8 + Cortex M3: höherer cpu-Takt, sogar mit ARM Coprozessor, aber MIT Linux) !
Exakt wie ich es auch für Arduino vs. Raspi beschrieben habe!
http://forum.ftcommunity.de/viewtopic.php?f=8&t=3312&p=22998#p22998
Linux ist eben das Gegenteil von Echtzeit-fähig.
das normale linux ist nicht echtzeitfähig, richtig, es gibt aber diverse realtime kernel update für linux. man muß sich da allerdings auskennen.
kennst du sowas für Raspbian Jessie (Raspi) ?
Oder das TI DaVinci Linux (ft TXT) ?
Gerade für den Raspi 2B mit Jessie würde mich das sehr interessieren!
(Allerdings hat hierzu bisher auf ähnliche Anfragen noch nicht mal im Raspi-org-Forum jemand so etwas als Option angeboten...)
http://www.emlid.com/raspberry-pi-real-time-kernel/
ich muß mal zu hause gucken, ich habe noch ein link.
Rabenauge
19.01.2016, 11:18
Display muss kein SPI sein- es gibt auch welche für den I2C-Bus. Fängt bei ganz kleinen, aber grafikfähigen OLED-Displays an und geht über diverse LCD (16x2, 20x4) weiter.
Die IMU die ich habe, läuft ebenfalls über I2C, somit braucht man schon mal gar keine extra Pins.
Nen Arduino Mega 2560 steuert bei mir z.B. nen Modell-Segway:
-zweiRC-Kanäle einlesen (gibts ne tolle Bibliothek für)
-IMU auslesen, und die Werte mittels Kalman-Filter aufbereiten (gibts ne Bibliothek für)
- zwei Motoren mittels PID-Reglern ansteuern (gibts auch ne Bibliothek)
-I2C-Display ansteuern (ist so nen kleines OLED)
-Akku überwachen, Beleuchtung schalten
Da du mehr Zeit hast (soo extrem schnell brauchen Verbrennungsmotoren nicht angesteuert werden, dazu sind sie eh zu träge), reicht das also dicke.
Den Mega hab ich deshalb genommen, weil er einfach deutlich mehr Speicher hat, den die umfangreichen Berechnungen wohl auch brauchen. Von den Pins her könnt das auch nen Uno- auch mit denen wurden schon Balancierer gebaut.
Ausserdem hab ich immer gern nach oben etwas Luft- und nennenswert mehr kostet der Mega einfach auch nicht.
also, i2c ist echt ne lahme Krücke für Displays. Die haben max. 400kHz Takt (eher sogar nur 100kHz), und SPI geht bis 16 oder sogar bis 84 MHz Takt. Wenn dann noch andere Geräte am I2C hängen - vergiss es. Mit LCD1602 oder 2004 würde ich auch gar nicht erst anfangen.
Aber wenn du dich für eine Variante entschieden hast - Mega oder Due - sag Bescheid, ich kann dir ein paar Tipps zu Displays geben.
Hier schon mal ein kleiner Überblick:
http://www.mindstormsforum.de/viewtopic.php?f=78&t=8491
dieses ist momentan mein Favorit:
http://www.mindstormsforum.de/viewtopic.php?f=78&t=8491#p66189
geeignet u.a. für Arduino DUE und ebenfalls UNO und MEGA etc.
Vorteil: volle Ausnutzung des Hardware-SPI-Busses mit schneller Taktung!
Testergebnis mit DUE: Text 15x so schnell wie UTFT, Graphics 13x so schnell wie UTFT !
FlyRider
19.01.2016, 13:44
Aber wenn du dich für eine Variante entschieden hast - Mega oder Due - sag Bescheid, ich kann dir ein paar Tipps zu Displays geben.
Hi Leute,
was ist denn das für ein Forum??? Da kommt man kaum mit dem Lesen mit. .... :cheesy:
Also prinzipiell geht die Reise wohl Richtung Arduino, Raspi wäre wohl nur interessant, wenn ich vom "Luxus des OS" auch was hätte. Ich brauch es aber prinzipiell nicht unbedingt, das es sich grundsätzlich um nicht mehr als eine Steuerung handelt, und so ist es eher eine Belastung bzgl. Echtzeit. Und nun selbst mit irgendwelchen echtzeitfähigen Alternativsystemen zu experimentieren steht mMn nicht dafür. Ob nun Arduino Mega oder Due... tja??? Wenn es letztlich bzgl. Anbindung der Komponenten (IMU, Diaplay, Motoren, usw...) egal ist, dann würd ich natürlich das schnellere System nehmen - etwas Luft nach oben schadet ja nie und Parameter wie Stromverbrauch spielen für mich keine Rolle.
Ob nun Arduino Mega oder Due... tja???
Wobei sich der Due nur lohnt, wenn man wie HaWe ausschliesslich die original Arduino-IDE akzeptiert. Ansonsten gibt es für die Cortex-M auch noch mbed, die Einsteigersoftware von ARM selbst.
Version 2 (https://developer.mbed.org/)
Preview Version 3 (https://www.mbed.com/en/)
die Auswahl an Boards ist da ziemlich groß
https://developer.mbed.org/platforms/
Insbesondere wenn man mit Ethernet oder SD-Karte arbeitet, merkt man den Unterschied zwischen Controllern mit nativem Interface dafür und den über Arduino Shield angestoppelten Varianten. Mbed 3 kann außerdem UART, I2C und SPI asynchron über DMA abwickeln, da kann der Prozessor währenddessen anderes tun.
Boards wie der Teensy lassen sich sowohl mit Arduino als auch mit mbed benutzen
https://www.pjrc.com/teensy/
https://developer.mbed.org/platforms/Teensy-3-1/
Rabenauge
19.01.2016, 15:02
HaWe: mal wieder nicht übern Tellerrand gesehen, richtig? :)
Grade die kleinen OLED's schaffen abartige Geschwindigkeiten, weil die über nen eigenen Grafikspeicher verfügen. Da kommste mit angucken lange nicht nach, das schwör ich dir. Flüssiges scrollen ist damit überhaupt kein Problem.
Kann man wunderschöne Animatinen mit machen- mein Segway z.B. hat nen grafischen Tacho im Masstab 1:4.:cool:
Aufgrund des Gewichts werden die Teile (sind ja nur briefmarkengross und auch nich nennenswert schwerer) meist bei den Multicoptern als Displays benutzt- und obendrein sind sie weit robuster als nen LCD (kein Glas). Verschiedene Schriftgrössen gehn auch, und dimmen ebenfalls. Inzwischen gibts die sogar mehrfarbig, hab ich auch noch keins, fällt mir grad ein....
Das klappt mit den lahmen TFT's (die SPI benutzen) nich mal annähernd...auch wenn da natürlich insgesamt einiges mehr rauf passt.
Im übrigen würde _ich_ nem Einsteiger vom DUE immer abraten, da er völlig anders aufgebaut ist, ist er lange nicht so easy zu handlen, grade du, HaWe hast darüber ja schon etliche Liedchen gesungen. Auch deshalb ist er in der Community recht selten vorhanden, und man findet eben dann auch weniger Unterstützung.
geb ich zu - OLEDs mit Grafikspeicher, das wusste ich nicht. Punkt für dich!
Außerdem sind sie wohl auch s/w, also weniger bits pro Pixel, auch weniger Pixel insgesamt, also auch weniger Bytes zu transportieren. Noch ein Punkt für dich.
Könnte also gehen.
Andererseits haben sowohl Mega als auch Due einen SPI-Header - warum also nicht was schnelles nehmen, was man kostenlos mitgeliefert bekommt? :)
A-Bär:
Der Due ist per Arduino-IDE absolut nicht anders zu händeln als der Mega, bietet aber viel mehr zusätzlich (Multitasking plus >10x schnellerer cpu-Takt und SPI plus >10x soviel Speicher plus 2x I2C...plus..plus...)
(Wäre dann also Endstand 2:2 :D )
ps,
die Due-Probleme sind, wenn überhaupt, Probleme bei Dingen, die es beim Mega noch nicht mal gibt, weil er die Features gar nicht besitzt und man gar nicht so weit kommt (USB-Keyboard z.B. - was anderes fällt mir momentan gar nicht ein)....
ok, 5V Shields passen nicht drauf, die nicht 3.3V kompatibel sind, aber bei vielen Geräten ist es genau andersrum (Displays, BT HC-05) , da ist der Due wieder im Vorteil.
pps,
und wer mit einem Raspi klarkommt, für den ist sowieso ein Due keine besondere Anfänger-Hürde mehr...
FlyRider
19.01.2016, 16:55
HaWe: mal wieder nicht übern Tellerrand gesehen, richtig? :)
Im übrigen würde _ich_ nem Einsteiger vom DUE immer abraten, da er völlig anders aufgebaut ist, ist er lange nicht so easy zu handlen, grade du, HaWe hast darüber ja schon etliche Liedchen gesungen. Auch deshalb ist er in der Community recht selten vorhanden, und man findet eben dann auch weniger Unterstützung.
Der Due ist per Arduino-IDE absolut nicht anders zu händeln als der Mega, bietet aber viel mehr zusätzlich (Multitasking plus >10x schnellerer cpu-Takt und SPI plus >10x soviel Speicher plus 2x I2C...plus..plus...)
(Wäre dann also Endstand 2:2 :D )
ps,
die Due-Probleme sind, wenn überhaupt, Probleme bei Dingen, die es beim Mega noch nicht mal gibt, weil er die Features gar nicht besitzt und man gar nicht so weit kommt (USB-Keyboard z.B. - was anderes fällt mir momentan gar nicht ein)....
ok, 5V Shields passen nicht drauf, die nicht 3.3V kompatibel sind, aber bei vielen Geräten ist es genau andersrum (Displays, BT HC-05) , da ist der Due wieder im Vorteil.
Tja.... ich kann ja zur Entscheidungsfindung nichts beitragen. Deshalb als abschließenden Bitte folgende Fragen:
1) Spricht irgendwas gegen die Arduino IDE?
2) Ich nehme mal an, dass die Anbindung einer IMU und der Joysticks auch bei 3,3 V Versorgungsspannung möglich ist bzw davon unabhängig ist
3) Welches Shield würde ich vtl. benötigen / praktischischerweise einsetzen können, das es nur mit 5 V gibt?
4) kann man die angesprochenen Biliotheken für den Mega auch für den DUE einsetzen ?
meine Meinung und Erfahrung (ich habe 2 Megas und 2 Dues):
1) nein, kein Nachteil: zumindest keinesfalls für Einsteiger
2) ja: höchstens die 100% Bezugsgröße für analoge Sensoren oder Potis ist halt verschieden und wird dann nach Dreisatz anders berechnet.
3) Original Arduino Motorshield hat nur 5V, soweit ich weiß - aber es gibt andere Platinen, die funktionieren mit beiden Signal-Levels (habe ich selber)
4) die meisten ja (z.B. PID_v1 oder UTFT u.a.m.), ansonsten gibt es alternative (z.B. Timer-Lib für Mega und DueTimer-lib für Due u.a.m.)
FlyRider
19.01.2016, 17:31
@ HaWe, es ist natürlich für mich ein Glückstreffer, dass du Erfahrung mit beiden Systemen hast. Ich interpretier deine Aussage mal so, dass es prinzipiell keinen großen Unterschied machen sollte, welches Board man nimmt.
Nachdem ich schon gern etwas Rechenpower hätte, würde ich mich nun mal für den DUE entscheiden und mir überlegen, welche Komponenten ich dazu benötige.
Ich werd die ganzen Links und Empfehlungen noch mal durchgehen und mal eine angedachte Teileliste zusammenstellen. Dann hoffe ich hatürlich, dass der ein oder andere da vielleich noch mal drüberschauen könnte, ehe ich unnötig Geld verbrenne...
Vielen Dank an der Stelle für Eure umfangreiche Hilfe.
1) Spricht irgendwas gegen die Arduino IDE?
Grundsätzlich nichts. Außerdem kann man ja mit den gleichen Boards auch Alternativen nutzen.
Allerdings steht in Deinem Ausgangspost
Debuggen soll natürlich gehen
Kein Arduino außer dem Zero hat eine Hardware-Debuggerschnittstelle. Die Arduino IDE hat sowieso keinen Debugger, man kann die Boards aber z.B. mit Visual Micro seriell debuggen.
Das ist auch ein Merkmal des Due. Kein anderes Board in der Preisklasse des Original Due kommt ohne Debuggerschittstelle.
4) kann man die angesprochenen Biliotheken für den Mega auch für den DUE einsetzen ?
Der Due hat einen Prozessor mit einer ganz anderen Architektur. Alles was direkt auf Prozessorregister zugreift muss angepasst werden. Falls das jemand für die entsprechene Library gemacht hat, dann läuft sie. Sonst nicht.
Der Due hat einen Prozessor mit einer ganz anderen Architektur. Alles was direkt auf Prozessorregister zugreift muss angepasst werden. Falls das jemand für die entsprechene Library gemacht hat, dann läuft sie. Sonst nicht.
genau das macht doch die Arduino-IDE, unter Verwendung von gpp, den avr und arm libs, board specs und der Java-Shell, die all das verwaltet. Alle libs, die auf ANSI C bzw. C++ benutzen, werden von gpp auf die entsprechende Zielplattform kompiliert: das ist ja gerade der Vorteil von C/C++ code mit den dazu passenden Compilern, die ja vorhanden (installiert) sind.
In den meisten Fällen, die ich kenne, sind die gpp libs für avrs beschnitten (z.B. stdio.h), um Speicher zu sparen (z.B. sprintf() für floats, oder auch generell vsscanf(), das für avr überhaupt nicht zur Verfügung steht), für den Due sind diese Beschränkungen aufgehoben.
Das gleiche gilt für Variablentypen: bei avr sind max. 32 bit Variablen möglich (auch double wird auf 32-bit float herunterskaliert), der Due hat 64 bit double und 64 bit long long (int64_t).
Ich kenne keine einzige Einschränkung, die für den Due gülte, aber nicht für avrs. Ausgenommen sind ntl Hardware-Register-Zugriffe, aber ich kenne auch hier keinen Fall, in dem dann nicht entsprechende Alternativen für den arm gäbe.
Selbstverständlich kenne ich nicht alle libs, die es geben mag.
Halt, gerade im Moment fällt mir 1 ein:
tone() funktioniert noch nicht beim Due. Allerdings hat er 2 DAC on-board, um wav von SD wiederzugeben, habe aber beides noch nicht wirklich gebraucht.
In der Liste des TOs lese ich aber nichts, was solche Einschränkungen erwarten ließe (CMIIW).
als Ersatz für einen richtigen Debugger muss man bei Arduinos die serielle Konsole am PC verwenden. Hier kann man immerhin während der Laufzeit Variablen mit ihren Werten tabellarisch ausgeben, und man kann manuelle Brakepoints setzen, wo man auf einen Btn-press wartet.
Etwas hölzern und steinzeitlich, ok, aber man kann sich damit behelfen.
Allerdings mache ich das lieber als gdb auf anderen Plattformen zu benutzen - dieser Debugger ist für mich WIRKLICH die Hölle...! ;)
Also erst mal vorweg: Ich will dem Fragesteller den Due nicht ausreden, er soll seine eigenen Erfahrungen machen. Vielleicht ist der Due ja ganz richtig für ihn.
Der Due war auch mein erstes Board mit 32-Bit Mikrocontroller. Allerdings bin ich kurz danach auch an ein anderes geraten (mbed LPC1768 ).
Im Vergleich (mittlerweile mit 5 verschiedenen mbed Boards) fallen mir dann doch einige Sachen ein, die mir am Due missfallen. Hier nur die wichtigsten:
Performance: Das Problem mit dem Linux auf den Cortex-A Boards hast Du gut beschrieben. Allerdings besteht das in ähnlicher Form auch beim Due. Die Arduino Software bildet halt eine Abstraktionsebene, damit sich der Due wie jeder andere Arduino anfühlt. Allerdings ist die Verpackung ziemlich dick. Das erste was einem beim Vergleich mit einem mbed auffällt, ist der Geschwindigkeitsunterschied. Manchmal nur 20-30%, bei anderen Sachen gerne mal Faktor 5.
Einschränkungen in der Software: Die Beschränkungen beim g++ für die 8-Bitter stammen von den Compilerbauern, mehr gibt die kleine Hardware halt nicht her. Beim Due ist das anders. Wir hatten hier kürzlich eine Frage zu C++11 auf dem Due, ich bin gerade zu faul den Thread zu suchen. Da musste ich auf eine alternative Buildumgebung verweisen, weil in der Arduino IDE Teile der C++ Standardbibliothek des Compilers gelöscht sind, die bei der Stand-Alone Installation dabei sind. Dadurch sind diverse C++ Features (z.B. string, vector, usw.) künstlich deaktiviert. Technische Gründe dafür gibt es nicht, wenn man die Sketches außerhalb der IDE baut funktioniert es und die Programme sind teilweise kleiner und schneller als mit der Arduino IDE.
Also noch mal zusammengefasst meine Erfahrungen zum Due:
Ein großes Board mit vielen Pins, besonders hervorzuheben zwei analoge Ausgänge, sonst gibt es meist nur einen.
Die fehlende 5V Toleranz finde ich für ein Bastelboard als Mangel, bei allen meinen anderen sind mindestens die digitalen Pins tolerant. Das ist auch ein Problem mit dem CAN-Bus am Due, weil ich meine MCP2551 von den anderen Boards nicht nehmen kann, die arbeiten mit 5V.
Das Preis/Leistungsverhältnis ist etwas dürftig. Ein 13 Euro ST Nucleo mit auch 84 MHz hat fast genauso viele Pins und ist mit mbed deutlich schneller. Und den Nucleo gibt es auch mit 100 und 180 MHz. In der Preisklasse des original Due gibt es z.B. das FRDM-K64F in Uno Größe mit 120 MHz Cortex M4F, 256 kB RAM, 1 MB Flash, Ethernet, SD-Slot und 16-Bit Analogeingängen (2 davon differentiell).
Wenn man viele Libraries braucht, ist man bei Arduino besser aufgehoben. Standardsachen wie SPI usw. bedient mbed ausführlicher. Die Arduino Software erscheint doch etwas als Black Box. Bei mbed kann man viel einfacher in den Quellcode eintauchen.
auch wenn ich nicht mit deinen Erfahrungen bezgl. mbed-Boards aufwarten kann - bzgl deiner Beobachtungen von Code-Kompaktheit der Due-Arduino-IDE-Executables gegenüber nativen ARM Compilern hast du sicher Recht, das ist aber nichts was Due-typisch ist, das trifft auch auf Arduino-AVR-Kompilate zu.
In 1 Satz: ja, es geht auch sogar noch schneller, wenn man mbed verwendet.
Aber nicht einfacher, wenn man schnell Ergebnisse braucht, nicht alle libs selber schreiben will, und sich nicht mit low level-Compilerproblemen und make file herumschlagen will.
Auch das gilt für alle Arduino-Boards, egal ob avr oder arm - kein Thema ntl für erfahrene embedded-C-Programmierer, oder die, die es werden wollen.
Auch ich will dem TO nichts ein- oder ausreden, ich wollte nur mit Vorurteilen und Berührungsängsten aufräumen, die den Vergleich der Arduino-ARM-Plattformen (Due, Zero, Tian, 101) mit Arduino-AVR-Plattformen (Uno, Mega, Nano, Micro) angeht:
Zum Thema Geschwindigkeit: hier hat man trotz allem beim Due eine über 10x größere Leistung gegenüber dem Mega (cpu clock, Speicher, runtime-Ausführungsgeschwindigkeit).
Und wegen der hohen Abstraktionsebene, auf der man mit der Arduino-IDE arbeitet, ist es eben kein nennenswerter Unterschied mehr, ob man für AVR oder ARM damit kompiliert.
Und wenigen technischen Nachteilen bei einigen älteren externen Zusatz-Komponenten (die z.B. keine 3.3V Kompatibilität besitzen) stehen jede Menge großer Vorteile gegenüber (Speicher, Geschwindigkeit, Multitasking zusätzlich neben Hardware-Timern und ARM- Hardware-IRQs, und eben 3.3V Kompatibilität für neuere Zusatzkomponenten, die keine 5V-Komp. mehr besitzen), und von den libs, die der TO wohl beabsichtigt zu nutzen, sehe ich keine einzige, die ausschließlich für die AVRs zugänglich wären.
ps,
Anm.:
Immerhin ist 5V ein recht alter Standard, 3.3V ist eher der modernere und IMO eher zukunftträchtigere Standard (alle ARM Boards haben den, auch Raspi und BBB), einige Komponenten nutzen bereits heute sogar nur 1.8V - und für alles andere gibt es notfalls Levelshifter.
FlyRider
20.01.2016, 18:07
Hallo an alle,
diskutiert ruhig weiter - ich lerne ja jedesmal dazu .... :)
Aber um die Diskussion nicht in's Uferlose abdriften zu lassen: Es gibt wohl Argumente pro / contra DUE / Mega, womöglich gibt es auch noch weitere Alternativen anderer Hersteller. Hilft alles nix. Irgedwann muss man mal einen Schritt machen: Ich werde (nicht sofort, aber bald) mir ein Arduino Due holen.
Dazu würde ich noch benötigen :
1 Display - dabei wäre es wichtig, dass das Display mit einigem Abstand zum Board betrieben werden kann
1 kleinen und billigen Analog- Joystick (Link wurde ja schon gepostet, Danke)
1 Möglichkeit, zwei Stellmotoren (können auch MOdellbau Servois sein) ansteuern zu können
1 genaue IMU, die ich anbinden kann
Es wurde ja schon diverse Vorschläge gemacht - falls jemand noch Tipps hat - DANKE!!!
MERCI überhaupt noch mal an alle!
Display: wieviel Pixel? s/w oder farbig?
wieviele Zeichen sollen dargestellt werden?
(ich persönlich habe nur farbige verwendet, min. 176x220, ca.12 Text Zeilen lesbar in Querformat).
SPI: nicht weiter als 20cm, sonst Geschwindigkeits-Einbruch!
Joystick s. Link
Servos: kenne ich mich nicht mit aus, geht über pwm => in Arduino Playground suchen
IMU: habe ich schon gepostet http://www.mindstormsforum.de/viewtopic.php?f=78&t=8491&start=15#p67401
FlyRider
21.01.2016, 17:31
Display: wieviel Pixel? s/w oder farbig?
wieviele Zeichen sollen dargestellt werden?
(ich persönlich habe nur farbige verwendet, min. 176x220, ca.12 Text Zeilen lesbar in Querformat).
SPI: nicht weiter als 20cm, sonst Geschwindigkeits-Einbruch!
Danke für den Hinweis bzgl SPI, muss ich mir den Einbau noch mal genau überlegen, das sollte ich aber hinbekommen.
Farbig wäre schon gut, 176x220 ist sicher OK.
MPU6050 (http://www.amazon.de/GY-521-MPU-6050-3-Achsen-Gyroskop-Accelerometre-Arduino/dp/B00X1SIVXG/ref=sr_1_1?ie=UTF8&qid=1453488182&sr=8-1&keywords=6050+mpu). Code gibts auf Github.
In 1 Satz: ja, es geht auch sogar noch schneller, wenn man mbed verwendet.
Aber nicht einfacher, wenn man schnell Ergebnisse braucht, nicht alle libs selber schreiben will, und sich nicht mit low level-Compilerproblemen und make file herumschlagen will.
Mbed ist prinzipiell das gleiche wie Arduino IDE. Kein low-level Kram.
Dadurch sind diverse C++ Features (z.B. string, vector, usw.) künstlich deaktiviert. Technische Gründe dafür gibt es nicht, wenn man die Sketches außerhalb der IDE baut funktioniert es und die Programme sind teilweise kleiner und schneller als mit der Arduino IDE.
Doch, gibt es. Wenn du dynamisch auf einem wenige KB großen RAM speicher allokierst ohne vernünftige Speicherverwaltung, dann überschreibst du ganz schnell wichtige Bereiche wie Stack. Genau deshalb ist es auch deaktiviert.
mfg
mbed mag ich nicht weil es im netz läuft, nicht lokal.
FlyRider
23.01.2016, 09:08
MPU6050 (http://www.amazon.de/GY-521-MPU-6050-3-Achsen-Gyroskop-Accelerometre-Arduino/dp/B00X1SIVXG/ref=sr_1_1?ie=UTF8&qid=1453488182&sr=8-1&keywords=6050+mpu). Code gibts auf Github.
ich hab inzwischen Arduino Due + Display bestellt.
Bzgl. IMU bin uch noch unsicher - es gibt wohl welche, die direkt "Richtungskoordinaten" liefern (wie auch immer das fachlich rorrekt heißt, ich meine Werte für die Winkel pitch, roll, yaw) und solche, die nur Rohdaten liefern und bei denen man selbst rechnen muss. Einfacher und "schöner" / sicherer (?) würde ich natürlich Variante 1 finden. Viele scheinen auch neben Beschleunigung und Drehwinkel das Erdmagnetfeld mit einzuberechnen - nachdem ich bei dem Gerät zwei große Motoren mit Zündung und Lichtmaschinen in der Umgebung habe (einer ist ca. 80 cm weit weg), frage ich mich, ob das Einbeziehen des Erdmagnetfeldes in dem Fall Sinn macht.
Die CMPS11 schien eine der "Komplettlösungen" zu sein, allerdings unter Berücksichtigung des Magnetfeldes (wobei ich keine Ahnung habe, in wie fern evtl. Verbrennungsmotoren darauf Einfluss haben), die MPU6050 ist wohl eher die "rechne mal selber" Variante. Gibt es vielleicht noch Empfehlungen für "Komplettlösungen", evtl. sogar mit Barometer??
Mbed ist prinzipiell das gleiche wie Arduino IDE. Kein low-level Kram.
Sag ich ja. Nur halt eben effizienter gemacht.
Doch, gibt es. Wenn du dynamisch auf einem wenige KB großen RAM speicher allokierst ohne vernünftige Speicherverwaltung, dann überschreibst du ganz schnell wichtige Bereiche wie Stack. Genau deshalb ist es auch deaktiviert.
Das stimmt nicht. Es ist ja auch nicht deaktiviert. Es sind einfach Dateien gelöscht. Der normale gcc-arm-none-eabi sowohl unter Linux als auch Windows hat diese Dinge und die funktionieren auch auf den 32 Bit Arduinos. Auch hat das offenbar nichts mit dynamischer Speicherverwaltung zu tun, es fehlen auch <array> oder <functional>.
Ich verwende normalerweise auf dem Notepad++ und platformio.org anstatt der Arduino IDE, damit ist das kein Problem.
mbed mag ich nicht weil es im netz läuft, nicht lokal.
Auch das stimmt nicht (mehr). Mbed 3 ist lokal.
Mbed 2 kann mittlerweile als zip Datei exportieren und die Projekte lassen sich unter Linux (auch auf Raspi oder Beaglebone) einfach durch Aufruf von "make" übersetzen, die entstandene Datei muss man nur noch auf den mbed kopieren.
Es gibt aber auch 2 oder 3 Projekte, wie das genannte Platformio, die mbed, Arduino, Teensy, TI offline auf der Kommadozeile bauen können. Sie lassen sich auch in diverse IDEs einbinden.
http://docs.platformio.org/en/latest/ide.html
- - - Aktualisiert - - -
Da muss ich nochmal antworten, weil sich das so schön selbst widerspricht
Mbed ist prinzipiell das gleiche wie Arduino IDE.
Ja beide verwenden offline den gleichen Compiler.
Doch, gibt es.
Eben noch gleich, jetzt nicht. In mbed geht std::string und std::vector und in Arduino nicht, weil ?
@all:
der TO hat doch jetzt den Arduino Due bestellt, dann bietet sich doch auch die Arduino-IDE an, gerade für Anfänger. Das war ja auch sein Entscheidungskriterium gegenüber anderen ARM (mbed) Boards. Wenn er mag, kann er später ja immer noch wechseln.
@FlyRider,
zum Thema IMU:
ok, an Magnet-Störfelder durch die Verbrennungsmotoren hatte ich als Alu- und Plastik-Nutzer nicht gedacht - stimmt aber!
Immerhin kannst du beim CMPS11 auch alle Einzel-Sensor-Raw-Werte ebenso einfach aus den Registern auslesen - allerdings nicht fusioniert.... damit geht sein größter Vorteil (onboard-cpu mit Kalman) natürlich "flöten".
Vom MPU6050 würde ich aber definitiv abraten, das ist ein unglaublich mistig zu handhabendes Monster, ich habe es mal damit probiert... ist zwar saubillig, aber jetzt liegt er ungenutzt in der Ecke. Die Libs dafür sind eine einzige Zumutung! (Vllt findest du aber hier jemanden, der dir das anfängertauglich erklären kann, ICH habe es aufgegeben...)
Rabenauge
23.01.2016, 11:36
Was an der MPU 6050 ist denn nun wieder kompliziert?
Man schliesse das Ding an, besorge sich die Kalman-Filter-Bibliothek für Ardunino und lese die gewünschten Werte....
Das Einzige, was man u.U. tun muss, ist, die Achsen an die _wirkliche_ Einbaulage anpassen.
Noch unkompolizierter kann ich es mir nicht vorstellen- zumal das Beispielprogramm der genannten Bibliothek auch Rohwerte (wenn man mal selber versuchen möchte, so _richtig_ zu programmieren) und auch komplementärGefilterte Werte ausgibt.
Hier kann man sehr schön vergleichen...
Und das funktioniert auch, einwandfrei.
Besser kann es irgendeine alles-in-Wunderlösung auch nicht machen, die hätte allenfalls nen Geschwindigkeitsvorteil, wenn die Filtereien direkt im Sensorbord erledigt werden, mehr nich...aber selbst auf nem, mit nur 16MHz getakteten, Arduino reicht das allemal zum balancieren.
Kompass wirst du wirklich knicken können. Abstand zu Eisen mindestens 20cm, bei weniger muss das Ding sehr gründlich kalibriert werden, und die Fehler, die die Zündanlagen erzeugen, wirste niemals raus gerechnet bekommen, fürchte ich.
FlyRider
23.01.2016, 12:18
Ich kann mir ja die MPU 6050 einfach mal ansehe, das Ding kostet ja wirklich nicht die Welt. Und mann kann ja relativ problemlos auch später noch eine andere IMU einbauen, wenn es die doch nicht bringen sollte. Bei Lösungen mit Magnetfeld habe ich eben bedenken, ob die noch problemlos funktionieren, wenn das Magentfeld gestört wird (ob man die Werte quasi ignorieren kann und nur auf Beschleunigung und Drehwinkel geht - aber dann bringt die "teure" Lösung hat eh nix).
Jetzt wart ich mal, ob noch jemand Efahrung mit alternativen IMUs hat, ansonsten probier ich einfach mal die MPU 6050 ...
gut zu wissen das mbed3 lokal ist
kompass ist echt kompliziert, nicht nur eisen, sondern auch motoren machen probleme.
den fehlerhaften Kompass-Anteil kannst du keinesfalls einfach ignorieren, wenn er in den IMU mit eingeht, aber durch Metallteile verfälscht wird. Dann wird auch dein heading total verfälscht sein. Daher brauchst du tatsächlich einen IMU OHNE Kompass-Anteil.
Das stimmt nicht. Es ist ja auch nicht deaktiviert. Es sind einfach Dateien gelöscht. Der normale gcc-arm-none-eabi sowohl unter Linux als auch Windows hat diese Dinge und die funktionieren auch auf den 32 Bit Arduinos. Auch hat das offenbar nichts mit dynamischer Speicherverwaltung zu tun, es fehlen auch <array> oder <functional>.
Gelöscht oder deaktiviert. Was ist da jetzt der Unterschied? Standardmäßig ist es nicht verwendbar, und auf das kommt es an.
Und es geht hier hauptsächlich um die Container, hier wird sehr viel mit dyn. Speicher gemacht. Bei unseren kleinen Hobby-Projekten, wo keine 10% des Controllers genutzt werden, funktioniert das natürlich gut. Aber es gibt ja schließlich Leute, die jedes Byte ausnutzen und dabei zu 100% garantieren müssen, dass nichts abstürzt. Sonst wird es seeehr teuer.
Aber in den nächsten Jahren wird sich hier noch viel ändern.
mfg
ey Leute, das mit dem embed ist doch längst vom Tisch! Der TO nimmt den Arduino DUE mit der Arduino-IDE!
bleibt doch bitte mal bei den tatsächlich noch offenen Problemen!
(z.B. einer IMU-Alternative zum MPU6050 und dem CMPS11, aber ohne Kompass, am besten aber auch (wie der CMPS11) mit eigenem Signal-Prozessor und Kalman-Filter on-board)
ps,
fällt mir gerade ein:
da soll's was neues von Bosch geben...
...weiß jetzt aber auch nicht mehr, ob mit oder ohne Kompass...
ey Leute, das mit dem embed ist doch längst vom Tisch! Der TO nimmt den Arduino DUE mit der Arduino-IDE!
bleibt doch bitte mal bei den tatsächlich noch offenen Problemen!
(z.B. einer IMU-Alternative zum MPU6050 und dem CMPS11, aber ohne Kompass, am besten aber auch (wie der CMPS11) mit eigenem Signal-Prozessor und Kalman-Filter on-board)
ps,
fällt mir gerade ein:
da soll's was neues von Bosch geben...
...weiß jetzt aber auch nicht mehr, ob mit oder ohne Kompass...
Problem ist doch schon gelöst mit dem 6050.
Hat KEIN Magnetometer, ist genau (16 bit) und der Due hat mehr als ausreichend Leistung um die paar Berechnungen durchzuführen.
mfg
ich kann mich dunkel erinnern, dass zumindest nicht alle MPU6050 libs voll ARM (Due) kompatibel sind, denn (zumindest manche) greifen wohl für I2C Befehle auf AVR Interrupts zu. Es gab zumindest Probleme, als ich es mal selber probiert habe.
Daher würde ich dann eher die CMPS11-Rohwerte verwenden, die sind leichter zu pollen - oder zumindest einen anderen als den MPU verwenden.
ich kann mich dunkel erinnern, dass zumindest nicht alle MPU6050 libs voll ARM (Due) kompatibel sind, denn (zumindest manche) greifen wohl für I2C Befehle auf AVR Interrupts zu. Es gab zumindest Probleme, als ich es mal selber probiert habe.
Daher würde ich dann eher die CMPS11-Rohwerte verwenden, die sind leichter zu pollen - oder zumindest einen anderen als den MPU verwenden.
(Beschränken wir uns bitte auf Bemerkungen zur Sache und sparen die Bemerkungen zum Gesprächspartner aus) Anmerkung von Manf
Selbst auf der Arduino-Seite gibt es Beispielcode für den Due (http://playground.arduino.cc/Main/MPU-6050).
mfg
eine neue pwm-Lib für den Due, speziell auch für Servos:
https://github.com/antodom/pwm_lib
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.