Board für komplexes (?) Projekt gesucht

[HaWe]

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]

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!!!!

[HaWe]

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]

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?

[HaWe]

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]

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 ??) 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...

[HaWe]

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/viewto...&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/viewto...tart=15#p67401

[HaWe]

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.

[morob]

das normale linux ist nicht echtzeitfähig, richtig, es gibt aber diverse realtime kernel update für linux. man muß sich da allerdings auskennen.

[HaWe]

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...)