Leistungsfähiger Microcontroller gesucht

Hallo in die Runde,

ich habe vor ca. 9 Monaten begonnen, mich mit Microcontrollern und ihrer Programmierung zu beschäftigen. Nach anfänglichen Spielereien, die zum Lernen unabdingbar sind, habe ich mein erstes Projekt fertig gestellt. Ein Kamera Slider mit vier Betriebsarten: Slide, Step, Macro und Dolly-Zoom. Mein Anspruch dabei war professionell, jedoch ohne kommerzielle Interessen. Dazu musste ich C++ lernen, einen 3D-Drucker anschaffen, eine 3D Software (FreeCAD) erlernen, mein 40 Jahre altes Know-How über Schaltungstechnik auffrischen, eine Software für Leiterplattenlayout erlernen (KiCAD) – und durch ein tiefes Tal der Tränen schreiten. Dies hat am Ende super geklappt – nicht zuletzt wegen toller Unterstützung aus diesem Forum.

Bislang läuft alles auf einem Nano (Clone). Durch viele Komfortfunktionen, wie automatische Lageerkennung (im vertikalen Betrieb schalte ich den Motor nicht auf Standbye) und umfangreiche Menüs zur Parametrierung via Rotary Encoder habe ich alle Ports (bis auf 4 Analogports) verbraucht. Der Nema23 Stepper Motor wird im ¼ Microstepping Mode betrieben, und bei 4000 Steps/s pfeift der Controller aus dem letzten Loch. Gleiches gilt für den Speicher, der zu 85% belegt ist.

Danach habe ich - isoliert vom ersten Projekt - einen Lens-Controller gebastelt. Dieser steuert Fokus- und Zoom eines Objektivs (auch synchronisiert) über zwei Nema11 Stepper Motoren. Zur Bedienung nutze ich einen Wii-Controller (kompatibel). Vor der Fertigstellung bin ich auf die Bremse getreten, weil der Wunsch gewachsen ist, den Slider aus dem ersten Projekt zu einer 5-Achsen Lösung zu ergänzen, also:

Slider/Stepper (Nema23, geeignet bis 6 kg im senkrechten Modus)
Tilt- und Pan Kopf (2x Nema17)
Zoom- und Fokus (2x Nema11).

Dies alles frei programmierbar. Soll heißen: An jeder beliebigen Position des Sliders soll ein/mehrere Befehl(e) an Tilt-, Pan-, Zoom- und Fokus Motor gehen können, in einer einstellbaren Zeit eine bestimmte Position einzunehmen. Das Ergebnis wäre ein frei programmierbarer Kamera-Robot - am Markt erhältlich für den Preis eines Porsches.

Für die Umsetzung wird ein Nano nicht mehr reichen. Bereits beim ersten Versuch, eine weitere Task mitlaufen zu lassen, die an bestimmten Positionen per SPI einen weiteren Nano dazu animiert, etwas zu tun, kommt der Hauptmotor (bei höheren Geschwindigkeiten) ins Stocken. Ich brauche also etwas mit deutlich mehr „Mumpf“. Schnellerer Prozessor mit ca. 40 (digitalen) I/O – im Idealfall programmierbar über die Arduino IDE. WiFi und Bluetooth sind hierbei nicht von Nöten.

Vielleicht kann mir ja jemand einen Tipp geben, welcher Microcontroller hierfür geeignet sein könnte. Ich kenne bislang nur die Arduino Welt.

Danke für allen Input,

Demokrit

Natürlich lassen sich deine bisherigen Anstrengungen mit mehreren Mikrocontrollern qualitativ nicht überprüfen, vielleicht gab es da noch Optimierungspotential. Aber schnell, günstig, ganz neu und mit 40 IO-Pins wäre mir der Teensy 4.0 eingefallen, lässt sich auch mit der Arduino-IDE programmieren:

https://www.pjrc.com/store/teensy40.html

Es gibt schon einiges schnelleres in der Arduino Welt.

Als erstes ist sicher der DUE zu nennen, der pinkompatibel zum Mega ist.

Wenn's kleiner sein soll gibt es noch den Teensy in verschiedenen Ausprägungen. Die sind sehr leistungsfähig und sehr gut in die IDE integriert.

Mein persönlicher Favorit ist die STM32F1 Familie: auch in recht kleinen Bauformen zu haben, bei einem unschlagbaren Preis-Leistungsverhältnis. Die kleinsten kaum größer als ein Nano, aber auch bis zu ca 80 I/O's in etwa UNO-Größe. In der Arduinowelt allerdings leider etwas exotisch und bei deutschen Händlern nur eingeschränkt zu bekommen. Ich programmiere die aber komplett über die Arduino IDE.

Diese schnelleren Bausteine haben alle eine 32-Bit ARM-CPU als Kern. Deshalb ist zu beachten, dass die dementsprechend auch alle mit 3,3V arbeiten. Da musst Du gegebenenfalls bei deiner HW drumherum drauf achten

Ich hätte den Teensy 3.5 vorgeschlagen, weil alle digitalen Pins 5V-tolerant sind.

Bitte informiere Dich vorab, welche Features der Hardware auch von der Software, also Bibliotheken, unterstützt werden. Du kannst Dir Teensyduino vorab installieren und einfach mal so tun als ob.

Ich nutze einen Teensy 3.2, um APA102-LEDs zu bespaßen, das geht erfreulich einfach mit der IDE. Man muß nur daran denken, daß Datentypen relativ zum UNO (ATmega328) mehr Bits haben. Daher habe ich mir die Schreibweise "uiint32_t" und dergleichen angewöhnt.

3D Drucker haben oft einen Arduino MEGA 2560 als Steuerung der Schrittmotore. Dieser steuert 3 bis 4 Schrittmotore gleichzeitig (x,y, Kunststoffzufuhr bzw beim Delta 3 Motore und die Zufuhr) synchron. Ich nehme mal an, daß Dein Problem nicht eine zu schwache Hardware ist sondern eine nicht optimierte Programmierung.

Grüße Uwe

ESP32 fällt mir noch ein

Mach doch mal ne Liste von dem was du an die 40 IOs anschließen willst

Von Klipper wirste wohl schon was gehört haben.
Genauso von SKR 1.3

ESP8266 oder ESP32 gäbe es, kennste aber wahrscheinlich schon .

4000 Steps/s ist aber ein bischen arg wenig, IMO.

WOW - ich bin begeistert. 1000 Dank für die vielen Anregungen und Tipps. Ich werde mich heute in die vorgeschlagenen Controller einlesen. Tatsächlich hätte ich die Bibliotheken benennen sollen, mit denen ich arbeite. Diese sind:

  1. TaskMacro von combie (fast unabdingbar, für mich der heilige Gral)
  2. AccelStepper/MultiStepper (unabdingbar wg. acceleration/deceleration und synchronem Ansteuern mehrerer Motoren)
  3. LCDMenuLib2 von Jomelo (äußerst komfortabel, geeignet für contextabhängige Menüs)
  4. Wire
  5. LiquidCrystal_I2C (ggf. ersetzbar durch andere LCD Lib)
  6. EEPROM
  7. WiiController von Andrew Mascolo (ließe sich durch eigenen Code ersetzen - nicht für den Slider relevant, aber für die angepeilte Gesamtlösung)

Die benötigten Ports, unsortiert, D=digital, A= analog, Nummer nur zur Auflistung:

D1: Rotary Encoder (Interrupt)
D2: Rotary Encoder (Interrupt)
D3: TB6600 Driver, Nema23 Motor Linearachse
D4: TB6600 Driver, Nema23 Motor Linearachse
D5: TB6600 Driver, Nema23 Motor Linearachse
D6: Limit Switch A Linearachse
D7: Limit Switch B Linearachse
D8: Camera Trigger
D9: AUX Trigger (nicht zwingend erforderlich)
D10: Tilt-Sensor
D11: DRV8825 Driver, Nema17 Motor Tilt
D12: DRV8825 Driver, Nema17 Motor Tilt
D13: DRV8825 Driver, Nema17 Motor Tilt
D14: DRV8825 Driver, Nema17 Motor Pan
D15: DRV8825 Driver, Nema17 Motor Pan
D16: DRV8825 Driver, Nema17 Motor Pan
D17: DRV8825 Driver, Nema11 Motor Focus
D18: DRV8825 Driver, Nema11 Motor Focus
D19: DRV8825 Driver, Nema11 Motor Focus
D20: DRV8825 Driver, Nema11 Motor Zoom
D21: DRV8825 Driver, Nema11 Motor Zoom
D22: DRV8825 Driver, Nema11 Motor Zoom
D23: Wii Controller
D24: Status LED1 (nicht zwingend erforderlich)
D24: Status LED2 (nicht zwingend erforderlich)
D25: Status LED3 (nicht zwingend erforderlich)

A1: Wii Controller
A2: Wii Controller
A3: LCD
A4: LCD
A5: Power Monitor (nicht zwingend erforderlich)

Dies wäre der Portbedarf, wenn ich es mit nur einem Microcontroller lösen kann. Wenn es mehrere (z.B. 3x Nano) würden, so kämen natürlich Ports zur Kommunikation dazu. Weiterer Portbedarf könnte während des Projekts entstehen.

Zu euren Anmerkungen:

  1. Natürlich gäbe es viel Optimierungspotential in meiner bisherigen Software - schließlich bin ich immer noch Anfänger. Ich habe aber stringent auf eine (bzw. mehrere) State Machine(s) gesetzt, nutze nur ein einziges "delay" (im unkritischen Setup). Die 4000 Steps/s als Grenzwert (ab dem beim Nano Schrittverluste auftreten) habe ich per Minimalanwendung (also unabhängig von der mächtigeren Gesamtlösung) ermittelt. Wesentlich war dabei, dass ich noch mindestens 1 Task parallel laufen lassen muß, welche die aktuelle Position überwacht, und zwischendurch Ausgaben auf dem Display vornimmt, mit anderen Programmteilen spricht, oder die Stepper Task beendet). Schneller als 4000 Steps/s brauche ich's nicht, und dieser Wert wird auch in der Google Group zum AccelStepper als Grenzwert genannt (habe ich aber erst nach meinen Tests gelesen).

  2. AccelStepper bildet sicherlich ein Bottleneck, ich benötige ihn aber, da ich mehrere Motoren synchronisiert zum Ziel laufen lassen muß. Wenn ein Objektiv zoomt, bleibt der Fokus i.d.R. nicht erhalten. Dies ist während der Zoomfahrt egal, muss aber am Zielpunkt synchron eintreffen.

  3. Der Controller muß nicht in DE verfügbar oder verbreitet sein - auch wenn es schändlich ist, ich kaufe durchaus viel in Asien.

  4. Ich verfüge über mehrere Nanos, einen Uno, einen Mega - und kenne tatsächlich noch keinen alternativen Prozessor.

Jetzt werde ich mich erst mal in die genannten alternativen Controller einlesen. Vielen Dank nochmals für eure Unterstützung.

Beste Grüße,

Thomas

Für was benutzt Du den Encoder?

Die Motore für TILT, PAN, FOKUS, ZOOM haben keinen Endschalter?
Wieso brauchst Du 2 Limit Switch?

Hast Du eine Canon-Kamera? Da gibt es eine PTP interface für Arduino mit der Du bei bestimmten Objektiven Scharfstellen und die Kammera auslösen bzw steuern kannst.

Grüße Uwe

Hallo Uwe,

der Encoder dient der Menüeingabe (Betriebsart, Kameratyp, Anzahl der Steps, Startpunkt links/rechts, Auslösungen pro Position, Geschwindigkeit, Macro-Schrittweite, Offset von Startposition, Offset von Endposition, Quick-Init usw.)

ein Limit Switch an beiden Enden der Linearachse erlaubt eine automatische Kalibrierung der Länge der Achse. Findet die Firmware keine Limits im Eeprom, so ermittelt sie Länge der Linearführung automatisch. So kann jemand, der nur den Macro Modus braucht (z.B. für Focus-Stacking) eine 20 cm Linearachse nutzen, ohne die SW zu verändern. Pure Komfortfunktion.

Pan-, Tilt-, Zoom- und Focusmotor benötigen nicht zwingend Endschalter, da nach Power-on Limitpositionen einmalig per Joystick angefahren und "gesetzt" werden. Dies ist besser als Endschalter, da die Kameraposition auf dem Schlitten variabel ist.

Der Robot soll unabhängig vom Kameratyp auslösen, also geeignet für Panasonic, Sony, Canon und Nikon. Da die Auslösestrategie der Hersteller abweicht, lässt sich das jeweilige Modell per Jumper parametrieren. Shutter Lag ist per Menü einstellbar. Kameras die per 2.4 GHz bedienbar sind, ließen sich mit einem Spezial-Nano (aus Asien) auslösen, der mir (unevaluiert) vorliegt.

Grüße,
Thomas

Hast du die DRV8825 schon?

Wenn nein, dann nimm TMC Controller, die sind flüsterleise

lässt sich das jeweilige Modell per Jumper parametrieren.

Da brauchst Du ja noch mehr Eingänge als Du geschrieben hast.
Grüße Uwe

themanfrommoon:
Hast du die DRV8825 schon?

Wenn nein, dann nimm TMC Controller, die sind flüsterleise

Ja, ich hab Berge an DRV8825 und A4988 - kostenlos aus dem Fundus eines Ex-DIY Bastlers. Der DRV8825 im Zusammenhang mit dem Nema11 Motor ist so gut wie unhörbar. Mit Lärm möchte ich es sicher nicht übertreiben, aber on-Camera Sound strebe ich mit dem Cam-Robot nicht wirklich an. Auch kommerzielle Produkte bauen auf separat aufgenommenen Ton (aus der Distanz)

uwefed:
Da brauchst Du ja noch mehr Eingänge als Du geschrieben hast.
Grüße Uwe

Nein, die Jumperung findet hinter dem Cam-Trigger Ausgang mit Optokoppler statt, und ist eigentlich nur für Panasonic erforderlich. Durch 2 Jumper aktiviere ich ein Widerstandsarray, welches die erforderliche Spannung erzeugt.

Demokrit:
4) Ich verfüge über mehrere Nanos, einen Uno, einen Mega - und kenne tatsächlich noch keinen alternativen Prozessor.

Die Liste der verwendeten Bibliotheken ist schon recht lang, weshalb ein Test, ob die alle auf einer anderen Hardware zuverlässig laufen, unbedingt notwendig ist. Wenn Du schon mehrere Nanos hast, kannst Du auch jeder Achse einen eigenen Nano spendieren, ein modularer Aufbau sozusagen. Daten austauschen können die dann bei kurzen Entfernungen mittels I2C oder sonst mit CanBus. Es wäre abzuwägen, welcher Weg der für Dich bessere wäre.

Demokrit:
Nein, die Jumperung findet hinter dem Cam-Trigger Ausgang mit Optokoppler statt, und ist eigentlich nur für Panasonic erforderlich. Durch 2 Jumper aktiviere ich ein Widerstandsarray, welches die erforderliche Spannung erzeugt.

Aha, dann hatte ich das falsch verstanden.
Bei genügend Pins kannst Du das auch Softwaremäßig durch das Menu machen. Einfach Kammeramodel einstellen und dann wird bereits alles richtig angesteuert ohne noch jumper irgendwo herumfummeln.
Grüße Uwe

Hallo agmue,

ich hatte eine ähnliche Idee bzgl. mehrerer Nanos. Mir erscheint bei hohen Step-Raten die parallel statt findende LCD Ausgabe als Bottleneck. Gebe ich viel aus, stockt der Motor hörbar, gebe ich wenig aus, klappt alles. Zudem nagen die String-Ausgaben natürlich kräftig am Speicher. Meine Idee war, den gesamten Setup inkl. Wii-Steuerung und LCD Ausgabe auf einen Nano auszulagern, und per SPI 2-3 andere Nanos (via Interrupt) zur tatsächlichen Ansteuerung zu nutzen. Hätte den Vorteil einer modularen Erweiterbarkeit, die ich eigentlich auch anstrebe. Ob das über SPI flott genug ginge, bliebe zu eruieren. Mit SPI habe ich noch keine tiefere Erfahrung.

Die Nutzbarkeit der Bibliotheken auf anderer HW ist tatsächlich kritisch. Die LCDMenuLib2 z.B. klappt wohl auch auf ESP32, bei anderen Bibliotheken finde ich oft keine Angaben über Kompatibilität. Da bleibt nur der Test.

Grüße,

Thomas

uwefed:
Aha, dann hatte ich das falsch verstanden.
Bei genügend Pins kannst Du das auch Softwaremäßig durch das Menu machen. Einfach Kammeramodel einstellen und dann wird bereits alles richtig angesteuert ohne noch jumper irgendwo herumfummeln.
Grüße Uwe

Eigentlich nutze ich schon beides parallel. Der AUX-Port ist nichts anderes als ein 2. Trigger Port, und im Menü kann ich den Haupt-Trigger auf diesen umleiten. Die Jumper waren eher eine Schnapsidee, denn das Gehäuse ist komplex in die Linearführung integriert, und ein Öffnen ist ein 20 Minuten Akt. Besser wäre hier ein von außen erreichbarer DIP-Schalter gewesen.

Zur Referenz anbei der Schaltplan (zeigt fast den letzten Stand)

Demokrit:
Mit SPI habe ich noch keine tiefere Erfahrung.

SPI zum Verbinden mehrer µCs habe ich hier noch nicht gesehen, dazu kann ich nichst sagen. Wie wäre es mit I2C oder CanBus?