Arduino Uno R4: Besonderheiten und Abhilfen

Rudolph R. schrieb:

So Handbremsen sind da bestimmt noch haufenweise in der Software drin.

Beim reinen Rechnen ist der RA4M1 ganz sicher viel schneller als der AVR, erst recht mit 32 Bit Werten, aber in den Klassen Richtung Peripherie verpufft das alles, wenn sich da noch niemand drum gekümmert hat.

So etwas schlimmes sehe ich leider auch bei anderen Projekten. Da wird lieber der dreihundertste exotische µC neu eingeführt, anstatt die bestehenden richtig zu unterstützen. Schlimmer wird's dann noch, wenn man sauber geschriebene Verbesserungsvorschläge samt diff/patch UND Erweiterung der Doku einreicht, diese jedoch aus nicht nachvollziehbaren Gründen abgelehnt werden. Bei Dingen welche auf anderen Controllern durchaus schon vorhanden und implementiert sind. Das macht man drei- vier mal, danach lässt man's und führt einfach seinen privaten Fork weiter.

Moin,

Ich kann mich nicht wirklich für den R4 begeistern. Das Datenblatt hat 3000 etwas unverdauliche Seiten - Brr. Da kaufe ich mir lieber eine STM32L496 Bord von ST und arbeite mit CubeMX und GDB Debugger. Diese Wahl lässt eigentlich wenig Wünsche offen. Die Nucleo Bord kann alles was der R4 kann und mehr.

Für einfachere Projekte reicht für mich immer noch die 8-Bit Welt der AVRs oder PIC. Auch der MSP430 ist für mich immer noch interessant.

Der ESP32 füllt dann noch gewisse drahtlose Interessengebiete aus. Damit komme ich aus.

Gerhard

Gerhard O. schrieb:

Ich kann mich nicht wirklich für den R4 begeistern.

Nachvollziehbar. Das Ding hat 32KiB RAM. Erinnert mich ein wenig an den AT90S1200, da dachten sie auch RAM ist unnützes Teufelszeug. Andererseits reichen dann auch die 4 DMA Kanäle.

Der ADC mit 25 Kanälen scheint so ziemlich das einzig Erwähnenswerte. Aber nur falls er es schafft die Kanäle in weniger als einer Viertel Stunde einzulesen.

Rudolph R. schrieb:

aber in den Klassen Richtung Peripherie verpufft das alles, wenn sich da noch niemand drum gekümmert hat.

Ja, aber das liegt dann eben an der schlampigen Software und nicht an der Hardware. Die diversen Bibliotheken der Hersteller für den Peripheriezugriff sind ja sowieso nur als "Beispiel" zu sehen, die freundlicherweise zur Verfügung gestellt werden. Die haben aber keinen Anspruch an Korrektheit oder Geschwindigkeit. Für produktiven Einsatz soll man sich natürlich komplett eigene Bibliotheken/Treiber zur Hardware-Ansteuerung implementieren. Dass Arduino diese Komponenten "einfach so" integriert und den Nutzern serviert ist halt nicht so gedacht, das fällt unter die Kategorie "selber schuld".

Dass es für die AVRs brauchbare Bibliotheken gibt liegt auch nur daran dass OpenSource-Bastler sich da bemüht haben...

Gerhard O. schrieb:

Ich kann mich nicht wirklich für den R4 begeistern. Das Datenblatt hat 3000 etwas unverdauliche Seiten - Brr

Naja, das erreichen sie Datenblätter der STM32 auch...

Niklas G. schrieb:

Rudolph R. schrieb:

aber in den Klassen Richtung Peripherie verpufft das alles, wenn sich da noch niemand drum gekümmert hat.

Ja, aber das liegt dann eben an der schlampigen Software und nicht an der Hardware. Die diversen Bibliotheken der Hersteller für den Peripheriezugriff sind ja sowieso nur als "Beispiel" zu sehen, die freundlicherweise zur Verfügung gestellt werden. Die haben aber keinen Anspruch an Korrektheit oder Geschwindigkeit. Für produktiven Einsatz soll man sich natürlich komplett eigene Bibliotheken/Treiber zur Hardware-Ansteuerung implementieren. Dass Arduino diese Komponenten "einfach so" integriert und den Nutzern serviert ist halt nicht so gedacht, das fällt unter die Kategorie "selber schuld".

Dass es für die AVRs brauchbare Bibliotheken gibt liegt auch nur daran dass OpenSource-Bastler sich da bemüht haben...

Gerhard O. schrieb:

Ich kann mich nicht wirklich für den R4 begeistern. Das Datenblatt hat 3000 etwas unverdauliche Seiten - Brr

Naja, das erreichen sie Datenblätter der STM32 auch...

Aber da lohnt es sich;-)

...

Hallo Zusammen,

vielen Dank für die vielen Antworten.

Hallo Rudolph,

Rudolph R. schrieb:

Ob Dein Programm davon wirklich betroffen ist kann ich natürlich nicht sagen, kommt eben darauf, was es wirklich macht.

Es ist ein grösseres Hobbyprojekt, welches im Wesentlichen als eine multifunktionale über eine Fernbedienung gesteuerte Uhr bezeichnet werden kann. Zusätzliche Funktionen sind beispielsweise verschiedene Anzeigeoptionen (LCD groß/klein und/oder Zeitanzeige in Laufschrift auf einer LED-Matrix), Kalenderfunktionen mit Schaltuhr sowie das Starten von Melodien und Animationen.

Da mittlerweile eine größere Datenmenge (zurzeit 32kB) eine einem externen EEPROM steckt, ist weiterhin eine Datenübertragung über Bluetooth (HC05) mittels einer Visual-Studio-App integriert.

Alle Funktionen sind nicht blockierend, arbeiten also im Zyklus nur einen bestimmten Teil ab. Ausnahme sind Noten- und Pausenlänge der Melodiewiedergabe sowie die Datenübertragung.

Peripheriezugriffe beschränken sich im Normalbetrieb auf das Aktualisieren des LCD, der LED-Matrix, das Schalten von Ausgängen und das Faden von LED.

Die normalen Programmfunktionen sollten aus meiner Sicht mit voller Geschwindigkeit laufen.

Mittlerweile habe ich noch weitere Besonderheiten des Uno R4 gefunden:

11. EEPROM-Emulation:

Auch hier habe ich festgestellt, dass es Abweichungen im Verhalten zwischen Uno R3 und R4 gibt: eine Schleife, welche einfach nur 600 Werte vom externen in das interne EEPROM kopiert, funktioniert im Uno R4 erst fehlerfrei, wenn nach einer bestimmten Anzahl von Schreibzugriffev auf das interne EEPROM eine Wartezeit eingebaut wird. Andernfalls wiederholt sich der Inhalt des internen EEPROMS ca. alle 255 Bytes.

12: analogWrite / digitalWrite:

Nach einem Analogwrite auf einem Ausgang verhält sich der Uno R4 anders als bei Uno R3 und Mega: nach einem Analogwrite muss die Datenrichtung neu gesetzt werden, ansonsten funktioniert ein Digitalwrite nicht mehr.

Viele Grüße Kai

Niklas G. schrieb:

Rudolph R. schrieb:

aber in den Klassen Richtung Peripherie verpufft das alles, wenn sich da noch niemand drum gekümmert hat.

Ja, aber das liegt dann eben an der schlampigen Software und nicht an der Hardware.

Ach, nein, echt? Vielleicht hättest Du irgendwas von dem restlichen Text lesen sollen den ich gepostet habe.

Kai schrieb:

Rudolph R. schrieb:

Ob Dein Programm davon wirklich betroffen ist kann ich natürlich nicht sagen, kommt eben darauf, was es wirklich macht.

Es ist ein grösseres Hobbyprojekt, welches im Wesentlichen

Das war jetzt nicht als Frage gemeint und in der Diskussion hier bekommen wir das auch nicht raus wie stark Dein Programm gebremst sein könnte. :-) Ich empfehle die Verwendung eines Logic-Analyzers für die Details.