Zitierendas normale linux ist nicht echtzeitfähig, richtig, es gibt aber diverse realtime kernel update für linux. man muß sich da allerdings auskennen.
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)
das normale linux ist nicht echtzeitfähig, richtig, es gibt aber diverse realtime kernel update für linux. man muß sich da allerdings auskennen.
das leben ist hart, aber wir müssen da durch.
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.
das leben ist hart, aber wir müssen da durch.
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.
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
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/viewto...&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 !
Hi Leute,Zitat von HaWe
was ist denn das für ein Forum??? Da kommt man kaum mit dem Lesen mit. ....
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.
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
Preview Version 3
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/
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.
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.
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
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)
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...
Geändert von HaWe (19.01.2016 um 15:11 Uhr)
Berechtigungen
Lesezeichen