Azurit auf Adafruit Grand Central M4 Express oder Teensy4.1
- Ersteller Fürst Ruprecht
- Erstellt am
Starsurfer78
Active member
Starsurfer78
Active member
Sieht auch interessant aus: Teensy 4.0 Expansion Board
Fürst Ruprecht
Well-known member
Ich nutze zur Zeit den Due. Die loops/sec gehen bei Aktivierung aller Funktionen auf 70 runter. Eine Berechnung der Radgeschwindigkeiten beim 4WD unter Verwendung von mathematischen Funktion schafft er nicht, da fällt er außer Tritt.
warum Teensy4.1: (muß aber 4.1 sein)
- Rechenleistung ist viel höher als bei allen Arduino-Boards, selbst eine Größenordnung über dem esp32. Ausstattung des boards, gleicher Preis, kleine Baugröße, moderne cpu
- die Programmierung ist jedoch anspruchsvoller
- Verwendbarkeit der Arduino-Umgebung und vieler libs.
Ich habe jetzt die ersten Programmierschritte gemacht und der Unterschied ist enorm. Ich habe die Ultraschallsensoren an einen Portexpander angeschlossen und frage sie über Interrupts ab. Die Ergebnisse sind bezüglich der Genauigkeit wirklich toll.
Grand-Central: ist Pin-compatible (bis auf Pullup-Widerstände) hat aber einen anderen AD-Wandler der völlig anders programmiert wird als der DUE. Außerdem hat der AD-Wandler einen Fehler und löst nicht mit der angegebenen Genauigkeit auf. Sicherlich auf Azurit anpassbar. Ich denke nur, warum die Arbeit in den Grand-Central reinstecken und nicht gleich den Teensy nehmen.
und vom PCB möchte ich eigentlich weg, weil die Summe aller boards und Platinchen bei meiner Umsetzung zu groß und zu viel sind.
Das 4.0 Expansion board kannte ich jetzt noch nicht. Es gibt aber auch ein 3d-drucker-board für den teensy4.1. Grundsätzlich stellt sich mir die Frage, ob man nicht auf ein 3d-Drucker-Board zurückgreifen sollte und das dann gemäß den eigenen Anforderungen erweitert. Das ist aber nur so eine Idee.
warum Teensy4.1: (muß aber 4.1 sein)
- Rechenleistung ist viel höher als bei allen Arduino-Boards, selbst eine Größenordnung über dem esp32. Ausstattung des boards, gleicher Preis, kleine Baugröße, moderne cpu
- die Programmierung ist jedoch anspruchsvoller
- Verwendbarkeit der Arduino-Umgebung und vieler libs.
Ich habe jetzt die ersten Programmierschritte gemacht und der Unterschied ist enorm. Ich habe die Ultraschallsensoren an einen Portexpander angeschlossen und frage sie über Interrupts ab. Die Ergebnisse sind bezüglich der Genauigkeit wirklich toll.
Grand-Central: ist Pin-compatible (bis auf Pullup-Widerstände) hat aber einen anderen AD-Wandler der völlig anders programmiert wird als der DUE. Außerdem hat der AD-Wandler einen Fehler und löst nicht mit der angegebenen Genauigkeit auf. Sicherlich auf Azurit anpassbar. Ich denke nur, warum die Arbeit in den Grand-Central reinstecken und nicht gleich den Teensy nehmen.
und vom PCB möchte ich eigentlich weg, weil die Summe aller boards und Platinchen bei meiner Umsetzung zu groß und zu viel sind.
Das 4.0 Expansion board kannte ich jetzt noch nicht. Es gibt aber auch ein 3d-drucker-board für den teensy4.1. Grundsätzlich stellt sich mir die Frage, ob man nicht auf ein 3d-Drucker-Board zurückgreifen sollte und das dann gemäß den eigenen Anforderungen erweitert. Das ist aber nur so eine Idee.
Fürst Ruprecht
Well-known member
Starsurfer78
Active member
Wäre es dann nicht sinnvoller für dich, die Motorsteuerung auf einen ESP32 auszulagern?
Wenn ich das richtig mitbekommen habe, wird dieser ja jetzt auch als Standard mitverkauft.
Bei der Platine gebe ich dir recht, deshalb versuche ich ja auch da was Kleineres und einfacheres hinzubekommen.
Mit Teensy kenne ich mich leider gar nicht aus, ich bin froh, wenn ich meine Arduino Sachen umgesetzt bekomme. Und bis vor ein paar Wochen kannte ich mich auch nicht mit Schaltplänen und Platinen Entwerfen aus, aber wenn man nicht das passende bekommt, muss man halt selber ran.
Auf Facebook hat jemand ein Board mit STM7 entwickelt, ist aber auch nichts zum selber löten und Schaltpläne sind auch nicht zugänglich.
Wenn ich das richtig mitbekommen habe, wird dieser ja jetzt auch als Standard mitverkauft.
Bei der Platine gebe ich dir recht, deshalb versuche ich ja auch da was Kleineres und einfacheres hinzubekommen.
Mit Teensy kenne ich mich leider gar nicht aus, ich bin froh, wenn ich meine Arduino Sachen umgesetzt bekomme. Und bis vor ein paar Wochen kannte ich mich auch nicht mit Schaltplänen und Platinen Entwerfen aus, aber wenn man nicht das passende bekommt, muss man halt selber ran.
Auf Facebook hat jemand ein Board mit STM7 entwickelt, ist aber auch nichts zum selber löten und Schaltpläne sind auch nicht zugänglich.
Fürst Ruprecht
Well-known member
meinst Du mit RTOS = Real-time operating system ?
Ja? , das war mein Studienschwerpunkt.
Ich habe gerade den ESP32 für die Servolenkung programmiert. Wenn man Taskprogrammierung macht treten ganz tolle Effekte auf, die man nur beherrschen kann, wenn man mit dem micro-controller verheiratet ist oder wie ich stundenlang im Internet nach Hinweisen sucht. Am Ende funktioniert es dann hoffentlich aber das Warum bleibt im Dunkeln. Es ist ein riesiger Unterschied, ob man ein völlig überperformantes System mit ein paar Aufgaben beaufschlagt oder ob man einen microcontroller realtime programmiert und an seine Taktgrenzen stößt.
Bei meinem Beispiel, bei dem ich die beiden cores des ESP separat anspreche, taktet die Steppertask mit 30 microsekunden. Das funktioniert auch nur, wenn man -für mich unerklärlich- den Watchdog manuell zurücksetzt (wieso läuft da überhaupt ein Watchdog?). Lösung im Netz gefunden, aber Erklärung offen:
Ja, ich bin auch ein Fan von Taskprogrammierung, aber offensichtlich geht es mit einfachem polling leichter.
Ja? , das war mein Studienschwerpunkt.
Ich habe gerade den ESP32 für die Servolenkung programmiert. Wenn man Taskprogrammierung macht treten ganz tolle Effekte auf, die man nur beherrschen kann, wenn man mit dem micro-controller verheiratet ist oder wie ich stundenlang im Internet nach Hinweisen sucht. Am Ende funktioniert es dann hoffentlich aber das Warum bleibt im Dunkeln. Es ist ein riesiger Unterschied, ob man ein völlig überperformantes System mit ein paar Aufgaben beaufschlagt oder ob man einen microcontroller realtime programmiert und an seine Taktgrenzen stößt.
Bei meinem Beispiel, bei dem ich die beiden cores des ESP separat anspreche, taktet die Steppertask mit 30 microsekunden. Das funktioniert auch nur, wenn man -für mich unerklärlich- den Watchdog manuell zurücksetzt (wieso läuft da überhaupt ein Watchdog?). Lösung im Netz gefunden, aber Erklärung offen:
Ja, ich bin auch ein Fan von Taskprogrammierung, aber offensichtlich geht es mit einfachem polling leichter.
Ja, mit RTOS meinte ich ein Betriebssystem.
Ich selbst bin beruflich Embedded SW-Ingenieur. Wir verwenden fast ausschließlich STM32 (C++, freeRTOS). Ich habe noch keinen Ardumower, lese aber seit 2 Monaten mit. Ich habe aber vor die Software selber zu schreiben, einfach als Hobby-Projekt. Mein Elektronikverständnis ist leider nicht so ausgereift, sodass ich wahrscheinlich auf bereits vorhandene PCBAs zurückgreifen werde.
Ich habe erst gestern nur den M4 bestellt um die ersten Gehversuche auf einer anderen Microcontrollerfamilie zu machen. Jetzt bin ich gerade am überlegen ob ich mich eher mit dem Teensy beschäftige. Aber ist dieser denn Pinkompatibel - von den Steckern definitiv aber auch sonst von der Belegung?
Ich selbst bin beruflich Embedded SW-Ingenieur. Wir verwenden fast ausschließlich STM32 (C++, freeRTOS). Ich habe noch keinen Ardumower, lese aber seit 2 Monaten mit. Ich habe aber vor die Software selber zu schreiben, einfach als Hobby-Projekt. Mein Elektronikverständnis ist leider nicht so ausgereift, sodass ich wahrscheinlich auf bereits vorhandene PCBAs zurückgreifen werde.
Ich habe erst gestern nur den M4 bestellt um die ersten Gehversuche auf einer anderen Microcontrollerfamilie zu machen. Jetzt bin ich gerade am überlegen ob ich mich eher mit dem Teensy beschäftige. Aber ist dieser denn Pinkompatibel - von den Steckern definitiv aber auch sonst von der Belegung?
Fürst Ruprecht
Well-known member
der Teensy ist pin-compatible zu nix, aber soweit ich das bisher sehe, für den Preis von der Performance und Ausstattung nicht zu schlagen.
Fürst Ruprecht
Well-known member
die Kompatibilität ist auf „Arduino Uno Rev3.0 shields“ beschränkt. Das sind zwei kurze Pin-Reihen, besser als nichts.
Aber das paßt leider nicht zu einem PCB1.3/1.4. Die Abweichung zur Due/Mega-Pinbelegung ist schon sehr deutlich.
Aus meiner Sicht ist der ganz große Vorteil des Due/Mega/Grand Central die Menge der analogen und digitalen IO-Pins. Mit jeder anderen Lösung braucht man zusätzliche Bausteine um so viele Signale zu bedienen und die belegen dann auch wieder vorhandene Pins.
Trotzdem sind die Boards interessant und es werden auch immer mehr angeboten.
Aber das paßt leider nicht zu einem PCB1.3/1.4. Die Abweichung zur Due/Mega-Pinbelegung ist schon sehr deutlich.
Aus meiner Sicht ist der ganz große Vorteil des Due/Mega/Grand Central die Menge der analogen und digitalen IO-Pins. Mit jeder anderen Lösung braucht man zusätzliche Bausteine um so viele Signale zu bedienen und die belegen dann auch wieder vorhandene Pins.
Trotzdem sind die Boards interessant und es werden auch immer mehr angeboten.
Starsurfer78
Active member
Ich würde bei einer neuen Version eher zu einem ESP32 neben Raspi 3/4 und Raspbian+wiringPi tendieren.
Mit einem i2c multiplexer und adc multiplexer, sollte man genug Pins haben.
Wobei die meisten Sensoren ja mittlerweile über I2C angesprochen werden, es gibt z.b. jetzt auch Ultraschallsensoren für I2C.
Das Raspi Sense HAT, hat schon alleine 6 Sensoren auf einer Platine.
Mit einem i2c multiplexer und adc multiplexer, sollte man genug Pins haben.
Wobei die meisten Sensoren ja mittlerweile über I2C angesprochen werden, es gibt z.b. jetzt auch Ultraschallsensoren für I2C.
Das Raspi Sense HAT, hat schon alleine 6 Sensoren auf einer Platine.
Starsurfer78
Active member
Moin,
der Lolin ESP32 scheint doch eigentlich perfekt geeignet zu sein:
www.mischianti.org
der Lolin ESP32 scheint doch eigentlich perfekt geeignet zu sein:
ESP32 WeMos LOLIN32 high resolution pinout and specs
ESP32 WeMos LOLIN32 high resolution draw of pinout and specs
www.mischianti.org
rweickelt
New member
Ich wage mal zu behaupten dass die Rechenleistung des M4F für die Belange des Ardumowers weit mehr als ausreichend ist. Aber mit einer großen Superloop, ohne Priorisierung und ohne präemptive Abarbeitung sind Echtzeitanforderungen nur schwer zu erfüllen. Es ist schon erstaunlich wie weit man in diesem Projekt mit der Arduinoumgebung gekommen ist und ich bin beeindruckt wie leicht man zu einem lauffähigen System kommt und Code hier und da ändern kann ohne ein tieferes Verständnis von Softwareentwicklung haben zu müssen. Die Zugangshürde für dieses Projekt liegt enorm tief. Das ist wahrscheinlich höher zu bewerten als alles mit irgendeinem RTOS neu aufzusetzen.
Aber wenn man anfängt zu überlegen, einzelne Aufgaben auf noch mehr Mikrocontroller zu verteilen nur um für Echtzeitsteuerung erforderlichen Konzepte zu umgehen, stellt sich mir die Frage ob nicht genau der Zeitpunkt gekommen ist, da was grundsätzlich an der Softwarearchitektur zu ändern. Kann man natürlich auch anders herum sehen: auslagern von zeitkritischen Aufgaben senkt die Komplexität in der Hauptanwendung, d.h. dort kann man dann bei Arduino bleiben.
Aber wenn man anfängt zu überlegen, einzelne Aufgaben auf noch mehr Mikrocontroller zu verteilen nur um für Echtzeitsteuerung erforderlichen Konzepte zu umgehen, stellt sich mir die Frage ob nicht genau der Zeitpunkt gekommen ist, da was grundsätzlich an der Softwarearchitektur zu ändern. Kann man natürlich auch anders herum sehen: auslagern von zeitkritischen Aufgaben senkt die Komplexität in der Hauptanwendung, d.h. dort kann man dann bei Arduino bleiben.
Roboterschaf
Member
Die Sache wird dann halt schwierig sofern die Dinge und Ansprüche umfangreicher werden, wann es darüber hinausgeht.
Es tauchen dann irgendwann Problemstellen auf, welche an irgendeinem Punkt früher lagen und die Fehlersuche wird schwierig.
Bei öffentlich zugänglichen Projekten macht es das mit unterschiedlichen Zielsetzungen schwierig.
Ich vermute der Erfolg des Teensy beginnt erst noch, CAN und Echtzeituhr sind ja auch schon an Bord.
Mit den CAN lassen sich evtl. die brushless treiber und evtl. zukünftige Radarsensoren abdecken, die sind preislich im Sinkflug.
Fürst Ruprecht
Well-known member
Hallo rweickelt,
leider kann ich zum M4F nichts sagen, weil ich bisher die Arbeit gescheut habe, die erforderlichen Anpassungen beim AD-Wandler zu machen. Mal abgesehen davon, daß der nicht mit der versprochenen Auflösung funktioniert.
Ich kann nur sagen, daß der Due mit 4-Radantrieb an die Grenze stößt. Da ist eine Drehzahlberechnung der einzelnen Räder noch auf einfache, angenäherte Form möglich, aber nicht mehr (zB. Schlupfkontrolle). Es kommt dann zu Abstürzen, die vermutlich von fehlerhaftem timing (Interrupt+Polling) kommen.
Ich gebe Dir Recht, daß die Arduino-IDE hier eine sehr einfache und leistungsfähige Möglichkeit darstellt, so ein Projekt abzuwickeln und so vielen Usern mit beschränkten Programmierkenntnissen (so wie ich) die Möglichkeit für solche Projekte gibt. Allerdings kommt man mit den neueren Controllern M4F, Teensy und auch esp32 schnell an die Grenzen der Arduino-IDE.
Wo ich Dir nicht zustimme, ist Deine Aussage zu Echtzeitsystemen.
Polling, also das Arbeiten mit Zeitschleifen und das Abfragen von Zuständen ist die klassische Art der Echtzeitverarbeitung.
Als (Wir) damals mit Multitasking anfingen, war das im Grunde nichts anderes als Polling, nur das eben der Taskmanager das Polling übernommen und die Zeitscheiben zugewiesen hat. Heute ist das auch nicht anders. Einzig die Komplexität der Controller ist dramatisch gestiegen und so blickt kaum noch einer durch, wie die Zeitabhängigkeiten sind.
Durch Erhöhung der Taktfrequenz gewinnt man wie Du schon sagst Rechenzeit, die man dann mit weiteren Inhalten füllen kann und kann bei der bisherigen Lösung aus Software und IDE bleiben. Durch Multitasking gewinnt man aus meiner Sicht bei gleichem Controller kaum etwas - hängt natürlich von der vorhandenen Qualität des Programms ab. Dafür verliert man wahrscheinlich viele user, die nicht mehr mithalten können.
Da wir ja aber in einem Forum diskutieren, kann/sollte/darf es unterschiedliche Lösungen geben und jeder kann etwas dazu beitragen und sich das für ihn passende raussuchen.
Ich bin im Moment froh, daß mein 4WD seit wenigen Tagen störungsfrei funktioniert und ich meine hunderttausend Programmierfehler, die ich selbst verursacht habe, auch wieder bereinigen konnte.
Meine Controller: Due für Azurit, 1 x esp32 für Webinterface, 1 x esp32 für Stepperlenkung (Dekodierung PWM-Signal von RC-Steuerung, Stepping)
Meine möglichen Ziele: Reduzierung der Baugröße durch einfaches PCB, Teensy statt Due, mehr Task-Programmierung für besseres Verständnis/Struktur der Software.
Gruß Fürst Ruprecht
leider kann ich zum M4F nichts sagen, weil ich bisher die Arbeit gescheut habe, die erforderlichen Anpassungen beim AD-Wandler zu machen. Mal abgesehen davon, daß der nicht mit der versprochenen Auflösung funktioniert.
Ich kann nur sagen, daß der Due mit 4-Radantrieb an die Grenze stößt. Da ist eine Drehzahlberechnung der einzelnen Räder noch auf einfache, angenäherte Form möglich, aber nicht mehr (zB. Schlupfkontrolle). Es kommt dann zu Abstürzen, die vermutlich von fehlerhaftem timing (Interrupt+Polling) kommen.
Ich gebe Dir Recht, daß die Arduino-IDE hier eine sehr einfache und leistungsfähige Möglichkeit darstellt, so ein Projekt abzuwickeln und so vielen Usern mit beschränkten Programmierkenntnissen (so wie ich) die Möglichkeit für solche Projekte gibt. Allerdings kommt man mit den neueren Controllern M4F, Teensy und auch esp32 schnell an die Grenzen der Arduino-IDE.
Wo ich Dir nicht zustimme, ist Deine Aussage zu Echtzeitsystemen.
Polling, also das Arbeiten mit Zeitschleifen und das Abfragen von Zuständen ist die klassische Art der Echtzeitverarbeitung.
Als (Wir) damals mit Multitasking anfingen, war das im Grunde nichts anderes als Polling, nur das eben der Taskmanager das Polling übernommen und die Zeitscheiben zugewiesen hat. Heute ist das auch nicht anders. Einzig die Komplexität der Controller ist dramatisch gestiegen und so blickt kaum noch einer durch, wie die Zeitabhängigkeiten sind.
Durch Erhöhung der Taktfrequenz gewinnt man wie Du schon sagst Rechenzeit, die man dann mit weiteren Inhalten füllen kann und kann bei der bisherigen Lösung aus Software und IDE bleiben. Durch Multitasking gewinnt man aus meiner Sicht bei gleichem Controller kaum etwas - hängt natürlich von der vorhandenen Qualität des Programms ab. Dafür verliert man wahrscheinlich viele user, die nicht mehr mithalten können.
Da wir ja aber in einem Forum diskutieren, kann/sollte/darf es unterschiedliche Lösungen geben und jeder kann etwas dazu beitragen und sich das für ihn passende raussuchen.
Ich bin im Moment froh, daß mein 4WD seit wenigen Tagen störungsfrei funktioniert und ich meine hunderttausend Programmierfehler, die ich selbst verursacht habe, auch wieder bereinigen konnte.
Meine Controller: Due für Azurit, 1 x esp32 für Webinterface, 1 x esp32 für Stepperlenkung (Dekodierung PWM-Signal von RC-Steuerung, Stepping)
Meine möglichen Ziele: Reduzierung der Baugröße durch einfaches PCB, Teensy statt Due, mehr Task-Programmierung für besseres Verständnis/Struktur der Software.
Gruß Fürst Ruprecht
Hallo,
ich bin embedded Softwareentwickler und kann dir doch aus heutiger Erfahrung sagen, dass richtiges Multitasking nicht nur "Polling vom Betriebssystem" sind. Der Performanceunterschied ist schon enorm.
Stell dir mal vor du würdest Daten über z.B. UART schicken.
Im Polling Mode musst du Byte für Byte übertragen. Nach jeder angestoßer Übertragung musst du aktiv das Register auslesen und überprüfen ob das Byte übertragen wurde bevor du das nächste senden kannst. Das ist alles CPU Zeit. Alles andere muss warten.
Nutzt man aber Interrupts+DMA+ ein RTOS macht der Kontroller alles für dich ohne die CPU zu belasten: Die gibts dem DMA Controller den Speicherbereich der Bytes die du übertragen willst. Dann übernimmt der Controller das übertragen ohne CPU-Last. Wenn alle Bytes übertragen sind, wird ein Interrupt ausgelöst, der z.B. dann einen Task per Semaphore weckt.
ich bin embedded Softwareentwickler und kann dir doch aus heutiger Erfahrung sagen, dass richtiges Multitasking nicht nur "Polling vom Betriebssystem" sind. Der Performanceunterschied ist schon enorm.
Stell dir mal vor du würdest Daten über z.B. UART schicken.
Im Polling Mode musst du Byte für Byte übertragen. Nach jeder angestoßer Übertragung musst du aktiv das Register auslesen und überprüfen ob das Byte übertragen wurde bevor du das nächste senden kannst. Das ist alles CPU Zeit. Alles andere muss warten.
Nutzt man aber Interrupts+DMA+ ein RTOS macht der Kontroller alles für dich ohne die CPU zu belasten: Die gibts dem DMA Controller den Speicherbereich der Bytes die du übertragen willst. Dann übernimmt der Controller das übertragen ohne CPU-Last. Wenn alle Bytes übertragen sind, wird ein Interrupt ausgelöst, der z.B. dann einen Task per Semaphore weckt.
rweickelt
New member
Echtzeit heißt nicht, dass es besonders schnell gehen muss. Echtzeit heißt, dass die anfallenden Aufgaben innerhalb eines garantierten Zeitraums abgearbeitet werden (harte Echtzeit), oder zumindest vorhersagbar häufig/gut/schlecht (weiche Echtzeit). Ob man nun pollt oder das über Interrupts löst, ist völlig unerheblich, die Ergebnisse müssen pünktlich da sein. Verschiedene Aufgaben im Ardumower haben verschiedene Zeitanforderungen. Die Herausforderung ist, sie so abzuarbeiten, dass alle Echtzeitanfordungen erfüllt werden. Bei einer großen Superloop und Polling werden die Reaktionszeiten durch die am längsten dauernde Aufgabe und die Reihenfolge der Abarbeitung bestimmt. Man kann dem einfach mit mehr Rechenkraft begegnen und hoffen, dass alles dann schnell genug geht. Besser ist es aber, das durch priorisierte und präemptive Abarbeitung (hoch priorisierte Aufgaben können niedrig priorisierte unterbrechen) zu lösen. Ob man dann ein threadbasiertes oder ereignisgetriebenes System baut, ist letztlich ein Implementierungsdetail.