Vorstellung & Frage zu Raspberry PI 2 Model B

[HaWe]

nie und nimmer ist der Uno die beste Empfehlung für Einsteiger, denn selbst Arduino.cc setzt auf die ARM M0 Architektur als Einsteigerplattform,
und die Programmierumgebung ist für alle Arduinos die gleiche
- also auch für den ARM M3 = Due.

Wer also den Zero oder Tian oder M0 (oder sogar den mickrigen Uno) mit der Arduino IDE programmieren lernt, der schafft das mit denselben Befehlen auch mit einem Due.

Schließlich heißt digitalRead überall digitalRead, Wire.available heißt überall Wire.available und Serial.write heißt überall Serial.write.
Nur dass der Due 2x Hardware-Wire (i2c) und 3x Hardware-Serial (UART) hat, bei seinen vielen (70 statt 20) Pins keine komplizierten
Port-Muxer braucht und SPI Displays mit vollen 84 MHz Takt betreiben kann

(edit: Guck dir die Benchmarks an! Der Uno hat noch nichtmal genug Speicher, dass die Tests überhaupt laufen, der Mega hat aber den gleichen cpu-Takt und ist wenigstens von der Performance vergleichbar). http://www.mindstormsforum.de/viewto...&t=8095#p64772

Und schließt man SPI am Uno an (Display, SD Karte), gehen von seinen lächerlichen 2000 Bytes RAM davon gleich schon 500 Bytes für den Puffer wieder weg...

Der einzige Grund, den ich sehe, den Uno zu empfehlen, ist: wenn ich mein Lager voll habe mit alten Unos und die schnellstmöglich loswerden will

[Mxt]

Man kann mit 5V 20mA am Ausgang viel mehr schalten, als mit 3,3V 4 mA. Viele Leute, die in Multimedia-Anwendungen etwas schalten wollen, wollen gar keine komplizierte Elektronik machen. Das sind klassische Arduino Anwendungen, damit sind die groß geworden.

Eventuell reicht es dann, denn Uno einfach mit Firmata zu laden, dann braucht man ihn gar nicht programmieren. Das geht dann auch an allen Rechnern mit USB.

Wie gesagt, solange es da keine speziellen Anforderungen gibt ...

Wenn es die gibt, dann müsste man mal schauen. Eventuell dann auch etwas anderes als Arduino, insbesondere wenn die gewünschte Funktion da nur über Shields ginge (Ethernet, SD-Karte, USB-Host, WLAN, BLE usw.).

[HaWe]

warum reitest du so auf dem Uno rum?
Das alte Ding ist doch kompletter Quatsch!
Und dann "mit Firmata laden"? Denkst du, das ist das, was ein Anfänger macht?
Außerdem geht es nicht nur um schalten von Ausgängen, sondern auch um Lesen von Eingängen!

1 Encodermotor z.B. braucht 5 Pins, 4 Motoren = 20 Pins - das kann der noch nicht mal mit Bordmitteln - lächerlich!!
dann hat der nur 6 analog-Pins, davon gehen sofort 2 für I2C weg!
dann hat der Uno nur 14 digitale Pins, da gehen dann jeweils 2 für UART weg, und für SPI sogar 4.

Was soll das?

Fazit:
wenn schon, dann den Due.

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