Arduino Uno R4: Besonderheiten und Abhilfen

[Norbert (der_norbert)]

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.

[Gerhard O. (gerhard_)]

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

[Norbert (der_norbert)]

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.

[Niklas G. (erlkoenig)]

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

[Gerhard O. (gerhard_)]

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;-)

...

[Kai (ksb)]

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