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.
das leben ist hart, aber wir müssen da durch.
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.
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
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.
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...Zitat von HaWe
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.
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/viewtopi...p=22998#p22998
Linux ist eben das Gegenteil von Echtzeit-fähig.
Geändert von HaWe (18.01.2016 um 20:16 Uhr)
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...)
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.
Geändert von HaWe (20.01.2016 um 14:10 Uhr)
Berechtigungen
Zitieren
Lesezeichen