Ü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.
Ü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.
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).
Ne, aber die ICs, die man eigentlich daran anschliesst. Gute Encoder geben Impulse im Megahertzbereich von sich.Zitat von 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).
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.
falsch: KEIN Denkfehler!
Aber egal ob dafür gedacht oder nicht - der Raspi ist dazu eben schlichtweg nicht geeignet, selbst mit Erweiterungs-Krücken nicht!
Und daher ja auch mein Rat, für Anfänger:
wenn Raspi, dann für Multimedia,
und wenn für Raspi zum Programmieren: dann Python für einfache, kurze, nicht zeitkritische Programme.
wenn dagegen Steuer- Und Regelungszwecke das Ziel sind, die zeitkritische Pin-Zugriffe erfordern:
dann einen Arduino mit ARM Prozessor, je mehr Pins und je mehr RAM, desto besser, am ehesten einen Due, denn der liest >70 Pins im Megahertztempo mit eigenen Bordmitteln aus.
Der Uno ist überholte Uralt-Technolgie, viel zu leistungsschwach, nicht multitaskingfähig - aber alle anderen Arduinos sind ebenso einfach zu programmieren, auch die ARMs, samt Multitasking, mehr Speicher, höherem Takt (und u.U auch mehr Pins).
Jetzt klar geworden?
(ps, auch den Teensy und den Galileo sollte man dabei nicht unbedingt vergessen, neben dem Due.)
Geändert von HaWe (15.11.2015 um 16:27 Uhr)
Wenn viel Multimedia erstmal mit einem Raspi 2 abchecken, ob der das gewünschte schafft. Wenn nein, führt sowieso kein Weg an einen aufgeteilten System vorbei, weil leistungsstärkere PCs kaum noch GPIOs haben.
Programmiertechnisch bleibt in beiden Fällen die Entscheidung der Programmiersprache. Bis auf die GPIO-Sachen ist das über alle Linux PCs eigentlich einheitlich, man ist also in keinster Weise auf die Raspi Communitiy beschränkt, insbesondere bei Multimedia.
Wenn Raspi und nur einfache nicht zeitkritische IO, dann die IOs des Raspi verwenden. Bei einem anderen System ohne IOs einen Arduino oder Teensy.
Hat man sich sowieso für C++ entschieden und lernt das richtig, z.B. mit Buch, dann ist der Weg zu anderen ARM Controller, zum Einstieg z.B. mit mbed, vom Sprachcharacter näherliegender als Arduino, weil die Tools und der Aufbau der Programme sehr ähnlich sind.
Berechtigungen
Zitieren
Lesezeichen