Vorstellung & Frage zu Raspberry PI 2 Model B

[Mxt]

warum reitest du so auf dem Uno rum?

Unter dem Aspekt der Community ist er die erste Wahl von den Sachen, die ich als zusätzlicher Controller an einem Linux-PC empfehlen würde, wenn nicht sicher ist, dass der Raspi 2 alleine genügen würde.

Ja, ich denke die Anzahl der Pins ist für den ersten Controller eine gute Wahl.

Nach Encodermotoren hat der Fragesteller nicht gefragt. Vier Encoder mit entsprechenden I2C- oder SPI-Bausteinen überfordern einen Uno nicht, die könnten aber auch gleich an den Raspi.

Gute ARM-Boards, wie die oben genannten STM32, haben natürlich auch QEI (Quadrature Encoder Interface) ...

[HaWe]

Encodermotoren können absolut nicht an den Raspi, denn
- der Raspi hat nur 1x Hardware-pwm
- der Raspi ist nicht in der Lage, 4 Rotationsencoder simultan auszulesen (Linux user space zu langsam, nicht echtzeitfähig),
- selbst wenn man 4 Encodermotoren anschließen könnte, wären alls seine GPIOs dafür futsch und nichts mehr übrig für andere Zwecke (er hat ja nur 20).

Von "guten ARM-Boards" ist hier nicht die Rede, denn die haben keine simple Arduino-IDE.

Wenn selbst Arduino den Zero als neues Einsteiger-Board propagiert, wirst du doch kaum behaupten wollen, er sei nicht für Einsteiger geeignet, schon gar nicht, was die Zukunftssicherheit (edit: vom Uno) und dessen überholte 5V-Technologie und dessen mickriges RAM angeht?
Egal ob als Zusatzboard oder stand-allone?

Hör mir auf mit "Uno"!

[Mxt]

Über SPI oder I2C hat der Raspi keine Probleme damit.

Encoder werden über Zählerbausteine in Hardware ausgewertet. Nur Bastler versuchen das über normale IOs. So jemand nimmt dann auch sicher einen Due dafür, dass passt dann, ja.

[HaWe]

Anfänger machen das mit Raspis über Python oder als Fortgeschrittenere in C über wiringPi, und wenn sie noch fortgeschrittener sind, vielleicht sogar in pigpio.

Encodermotoren haben aber keinen i2c- oder SPI-Anschluss, und daher muss man die Pins per digitalRead etc, auswerten.

Auf Arduinos macht man das auch so, aber über Pinchange- oder Timer-Interrupts, das klappt wunderbar (AVR-IRQs oder über DueTimer, noch viel einfacher): beides absolut echtzeitfähig.

Nur dass es auf dem Raspi Hardware-Timer-Interrupts überhaupt nicht gibt (im user space), und Hardware Pinchange-Interrupts auch nicht (nur softwaremäßig über gelatchte IO pins via pthread), dann aber zu langsam (eben wieder wegen dem lahmen Linux user space).

[Mxt]

Encodermotoren haben aber keinen i2c- oder SPI-Anschluss,

Ne, aber die ICs, die man eigentlich daran anschliesst. Gute Encoder geben Impulse im Megahertzbereich von sich.

[HaWe]

das sage ich ja -
der Raspi an sich ist dafür (mit Bordmitteln) absolut ungeeignet.
Expansionboards dafür sind wieder nicht a-priori anfängertauglich.
Außerdem schaufeln sie die Encoderwerte auch nicht in Echtzeit zum Raspi in sein RAM rüber.

Der DUE schafft das mit Bordmitteln locker selber für 6 Encodermotoren
(und wenn es denn unbedingt ein 5V AVR sein muss: der Mega kann es wegen seiner 8 pwm Pins sogar mit 8 Encodermotoren on-board).

[Mxt]

Außerdem schaufeln sie die Encoderwerte auch nicht in Echtzeit zum Raspi in sein RAM rüber.

Genau das ist ja der Denkfehler. Ein System wie der Raspi ist dazu nicht gedacht. Der will höchstens ab und zu mal die aktuelle Position wissen. In moderner Elektronik machen sowas Subsysteme. Entweder verteilt in einzelnen Chips oder als "System on a Chip".

Genau in die Richtung ziehlt die Empfehlung für den Uno, oder ein entsprechendes 3,3 V Pendant. Damit man gleich lernt die Dinge aufzuteilen. Auf beschränkte Subsysteme. Der Due würde nur zu falschen Zentralismus anregen. Darin liegt die Zukunftssicherheit, die Dir ja auch wichtig ist. In Zukunft werden immer mehr Chips verschiedene Bestandteile integrieren, da ist das Ganze dann nicht mal mehr auf verschiedene Boards verteilt.