Nach einer längeren “Vaporware”- bzw. Vorankündigungsphase steht die vierte Generation des Arduino-Evergreens Arduino R4 in gleich zwei Varianten im Arduino Store zur Verfügung. Was Arduino Uno R4 Minima und Uno R4 WiFi von den Vorgängern unterscheidet, klärt dieser Artikel.
Auf Prerelease-Fotos waren sowohl der Formfaktor als auch die genaue Seriennummer des am Uno R4 verwendeten Prozessors durch ein gelbes Post-It kaschiert – im Rahmen der Freischaltung der Store Listings findet sich die in der Abbildung gezeigte Detailbeschreibung.
Bildquelle: Arduino
Arduino entschied sich für den RA4M1 – eine auf einem Cortex M4-Kern samt FPU basierende MCU, die Renesas wie in der Abbildung beschreibt.
Neben der wesentlich höheren Rechenleistung erfuhr auch der Rest des GPIO-Komplements eine Erweiterung: wie viel davon in praktischen Arduino-Platinen zur Verfügung steht, ist naturgemäß vom PCB-Layout des jeweiligen Boards abhängig.
Durch die Bank steht nun allerdings eine Maximaltaktrate von 48 MHz zur Verfügung, der Flashspeicher ist nun 256KB groß. Das RAM ist 32KB groß.
Arduino Uno R4 Minima – preiswert, mit ISCP-Connector
Beim unter https://store.arduino.cc/products/uno-r4-minima um 18 EUR erhältlichen Arduino Uno R4 Minima setzt Arduino im Allgemeinen auf bekannte Kost: neu ist erstens ein erweiterter Versorgungsspannungsbereich von bis zu 24V und zweitens ein ISCP-Connector, der das direkte Debugging des am Rechners laufenden Codes erlaubt.
Bildquelle: Arduino
Wohl aufgrund dem Druck aus Richtung des DeviceScript-Ökosystems betont Arduino außerdem die HID-Fähigkeiten des neuen Boards:
Unter https://store.arduino.cc/products/uno-r4-wifi wechselt die größere Variante um 25 EUR den Besitzer. Neben einem auf einem ESP32-S3 basierenden Funkmodul bringt sie eine LED-Matrix (12x8 rote LEDs) mit.
Bildquelle: Arduino
Bei sorgfältiger Betrachtung fällt ein QWIIC-Interface auf, das einen weiteren I2C-Bus in einem im Makerbereich populären Format exponiert.
Insbesondere für Quereinsteiger dürfte der WiFI-Fehleranzeiger hilfreich sein, der nach folgendem Schema beschrieben wird:
Obwohl der verwendete Controller 5V-fähig ist, gilt, dass er naturgemäß mit AVR-Assembly nichts anzufangen weiss. In den Storeseiten warnen die Arduinoentwickler davor explizit:
Naja, ganz nett, aber irgendwie nicht so ganz der große Wurf. Es gibt
seit langer Zeit schon Arduinos basierend auf anderen CPUs, die kleiner
und leistungsfähiger sind. Die vermurksten Pinabstände sind immer noch
da. Ein 24V Eingang mit Schaltregler ist gut, aber für den Einsatz an
echten 24V Systemen im industriellen Umfeld zu wenig, da braucht es
schon wenigsten 30V maximale Eingangsspannung. Und zu guter Letzt ist
das Konzept der Buchsenleisten auch nicht so dolle. Denn damit kann man
zwar leicht ein paar Widerstände, LEDs oder auch Testkabel dort
reinstecken, aber auf einer Anwenderplatine kann man das Ding nur eher
schlecht aufstecken, bestenfalls kopfüber. Ein Formfaktor wie der
Arduino Nano ist da deutlich besser, sei es für Lochraster, Steckbrett
oder geätzte Platine.
Tam H. schrieb:> Arduino entschied sich für den RA4M1 – eine auf einem Cortex M4-Kern> samt FPU basierende MCU, die Renesas wie in der Abbildung beschreibt.
Wenn es denn von Renesas eine vernünftige kostenlose IDE gäbe
(gibt es die?) dann konnte man mit diesem Arduino abseits der
von mir nicht gerade geliebten IDE und deren APIs mal mit einem
ARM-Prozessor arbeiten der nicht von STM und Atmel ist. Und
in der Praxis sehen welche Vorteile und/oder Nachteile es gibt.
Wastl schrieb:> ARM-Prozessor arbeiten der nicht von STM und Atmel ist
Gibt es da überhaupt signifikante Unterschiede? Der Kern ist ja
lizenziert. Nur die Peripherie ist anders.
Hurra, eine RTC.....deren "VBATT"-Pin (4) (laut deren 3D-Viewer)
unter(!) dem IC fest mit VCC verdrahtet ist, damit man es bloß nicht mit
einer Knopfzelle als echte RTC nutzen kann. Hätte nicht gedacht, dass
Lötjumper so teuer sind.
Martin S. schrieb:> Wastl schrieb:>> ARM-Prozessor arbeiten der nicht von STM und Atmel ist>> Gibt es da überhaupt signifikante Unterschiede? Der Kern ist ja> lizenziert. Nur die Peripherie ist anders.
Das Ecosystem drumherum ist aber ein anderes, STMicro bietet eine eigene
IDE mit Startup-Konfigurator, viel Doku und Beispiele und eine
brauchbare HAL an, bei anderen Herstellern ist es da schon düsterer, hab
vor einiger Zeit mit einem Cortex M0 eines anderen Herstellers
gearbeitet, Doku nahezu nicht vorhanden und als IDE wird nur Keil
unterstützt und das auch nur mit Templates für die V4, alleine für die
letzten Keil V5 releases musste man ein V4 Legacy Pack und eine ältere
Version des ARM Compilers installieren.
Harry R. schrieb:> Hurra, eine RTC.....deren "VBATT"-Pin
Zu deren Ehrenrettung bzw. Umsatzförderung sei gesagt, dass dies nur bei
der "billigen" Version so ist. R4 Wifi hat einen Pin für VBatt.
Joachim B. schrieb:> was stimmt denn nun Platinendruck oder Beschreibung?
Vermutlich beides falsch!
Die 6 Polige Stiftleiste ist sicherlich SPI (ohne /CS), wie es z.B. vom
Ethernet Shield und manchen LCDs erwartet wird.
Hallo,
was bei solchen potenten Controllern immer wieder Schade ist, dass
Arduino auf den alten Formfaktor beharrt. In der Minima Version bleiben
viele Pins ungenutzt. Ist schon beim Every so richtig aufgefallen. Auch
wenn man da was mit dem Eventsystem machen kann, kann man doch nicht
alles zu gleich nutzen. Sowas müßte auf den Mega2560 Formfaktor oder der
Mut zu einem längeren Nano Formfaktor.
Ein Nachteil aller ARMs - der geringe IO Pin Strom. ;-) Warum
eigentlich? Die beim Renesas angegeben 8mA sind da schon sehr hoch im
Vergleich zu anderen mit nur 4mA oder gar nur 2mA.
Veit D. schrieb:> der geringe IO Pin Strom. ;-) Warum> eigentlich?
Weil er in den meisten Fällen ausreicht. Selbst wenn man LEDs direkt
daran anschließt; denn anders, als manch einer denkt, leuchten LEDs auch
dann sichtbar, wenn man weniger als 20 mA durch sie fließen lässt.
Hallo,
es geht doch nicht immer nur um Leds. Das ist meine geringste Sorge. Für
einen mittelmäßigen Transistor wird es schon eng.
Ganz konkret gefragt. Wenn ein ARM Controller irgendwelche
Leistungssachen schalten soll, werden da immer gleich sowas wie fertige
High-Side Switche oder ähnliches angeschlossen? Ein direkt
angeschlossenen Mosfet kann man ja mit üblichen 4mA nicht vernünftig
schnell schalten. Das ist schon mit 20mA grenzwertig nur reicht das fürs
"basteln". Aber mit 20mA kann ich eine Treiberstufe vernünftig
dazwischen schalten dann klappt auch mehr.
Wie sieht das Konzept mit ARM Controllern aus? Da muss es ja was geben
sonst wären die nicht in Steuerungen verbaut. Kurzum ich hätte gern die
Tür durch den Tellerrand. :-)
Ich wollte das Layout heute morgen nicht spontan bewerten und das mache
ich jetzt auch lieber nicht, das fällt unfreundlich aus.
Wobei ich mir gerade nur den "MINIMA" anschaue.
Dann lieber richtige Infos, wenn man eine robust designete Platine
braucht ist ein Arduino ohnehin nicht die richtige Wahl.
Zum Debuggen ist da ein SWD Anschluss drauf, eine 10pol Stitftleiste mit
1,27mm Raster, so ähnlich wie der ARM Standard das vorgibt mit SWDIO,
SWCLK, Reset, VCC und GND.
Leider liegt SWO nicht mit auf dem Stecker, der Pin wurde für die SPI
Schnittstelle verwendet.
Detail, im Schaltplan steht MISO und MOSI, im kunterbunten Pinout heißen
die aber CIPOB und COPIB - kein Kommentar.
Am SWD Stecker sind zwei "fremde" Signale, eine zusätzliche serielle
Schnittstelle, 7 = RXD, 8 = TXD.
Diese Pins vom Controller sind sonst nirgendwo angeschlossen.
Es ist ein 16MHz Quarz verbaut.
An den Analog Pins vermisse ich Kondensatoren, so wenigstens 10nF hätte
was.
Versorgt wird der verbaute RA4M1 mit 5V.
Und jetzt erstmal schauen wo man so ein Ding her bekommt und wie die
Software dazu aussieht...
Edit:
Ich weiß nicht, ob das hier schon mal erwähnt wurde:
https://github.com/arduino/ArduinoCore-renesas
Veit D. schrieb:> Hallo,>> was bei solchen potenten Controllern immer wieder Schade ist, dass> Arduino auf den alten Formfaktor beharrt.
Naja das Teil wird als Uno R4 vermarktet, da erwarte ich, das es
weitestgehend ähnlich zum R3 ist. Außerdem bleibt das Teil damit
kompatibel zu vielen anderen Produkten wie Shields und Gehäusen.
Zudem würde ich den Cortex M4 mit 48MHz nicht als sonderlich potent
bezeichnen, ich denke es ist ein sinnvoller Nachfolger zum leicht
betagten ATmega und erfüllt seine Anforderungen, wenn man mehr Leistung
braucht findet man auch aus dem Hause Arduino leistungsfähigere Boards.
Um als Einsteiger ein bisschen mit Mikrocontrollern rumzuspielen ist der
Uno (R4) völlig ausreichend und die ursprüngliche Zielgruppe von Arduino
waren keine Elektronikbastler, sondern Leute die mit Mikrocontrollern
eher weniger Berührungspunkte haben, die Arduino IDE und deren
Bibliotheken sollen einen einfachen Einstieg ermöglichen ohne sich im
Detail mit Mikrocontrollern auszukennen. Deshalb wird Arduino auch oft
als Spielzeug bezeichnet, es ist auch korrekt das man natürlich die
Boards auch mit der Hersteller IDE programmieren kann, wer aber diesen
Punkt erreicht hat, dem ist es in der Regel egal ob das Ding von Arduino
kommt oder ob es ein offizielles Evaluation Board ist, der primäre Grund
auf die Arduino Hardware zu setzen, ist dann nur noch die gute
Verfügbarkeit und der niedrige Preis für die Nachbauten.
Marc X. schrieb:> Naja das Teil wird als Uno R4 vermarktet, da erwarte ich, das es> weitestgehend ähnlich zum R3 ist. Außerdem bleibt das Teil damit> kompatibel zu vielen anderen Produkten wie Shields und Gehäusen.
Na toll, da wird die windige Hardware "Shield" draufpassen, aber keine
der Arduino-üblichen Libraries mehr funktionieren.
Wir freuen uns schon auf die nächsten Threads "Fehlermeldungen beim
Compilieren für A*UNO". Nach 25 Posts kommt dann Salamischeibe Nummer
zwei "ich habe xyz von Adafruit verwendet" und als Scheibe drei "Es ist
ein R4".
Und wie falk schon schrieb: Formfaktor und vermurkste Pinabstände. Wer
mehr als nur auf dem Steckbrettchen spielen will, macht einen Bogen um
die UNOs.
Manfred P. schrieb:> aber keine> der Arduino-üblichen Libraries mehr funktionieren.
Ich denke da täuscht du dich!
Sicher werden ein paar Hardwarespezifische erweitert werden müssen.
Aber das meiste läuft aus dem Stand.
Rudolph R. schrieb:> An den Analog Pins vermisse ich Kondensatoren, so wenigstens 10nF hätte> was.
Das kann man entkräften. Die Pins sind unterschiedlich verwendbar, dabei
könnten fest verbaute Kondensatoren stören.
Reichelt hat sie übrigens lieferbar.
Falk schrieb
>Die vermurksten Pinabstände sind immer noch da.
Die werden auch nie mehr verschwinden, da ca. 5 Trillionen
Arduino-Shields auf diese Abstände ausgelegt sind. Es ist sozusagen das
spezielle "Aleinstellungsmerkmal" des Arduino Anschlusses.
Wastl schrieb:
>Wenn es denn von Renesas eine vernünftige kostenlose IDE gäbe>(gibt es die?) dann konnte man mit diesem Arduino abseits der>von mir nicht gerade geliebten IDE und deren APIs mal mit einem>ARM-Prozessor arbeiten der nicht von STM und Atmel ist. Und>in der Praxis sehen welche Vorteile und/oder Nachteile es gibt.
Was spricht gegen die Verwendung von PlatformIO? Die unterstützen das
Arduino-Framework und ziemlich viele Prozessoren. Sämtliche STM32-Nucleo
und Discover Boards werden unterstützt. Ob die Renesas schon drinn sind,
weiß ich nicht, wird aber sicher so passieren.
Veit D. schrieb:> Rudolph R. schrieb:>>> An den Analog Pins vermisse ich Kondensatoren, so wenigstens 10nF hätte>> was.>> Das kann man entkräften. Die Pins sind unterschiedlich verwendbar, dabei> könnten fest verbaute Kondensatoren stören.
Dann hat man halt Analog Pins die für andere Dinge Limits haben statt
"Analog Pins" die analog schlechter funktionieren als sie müssten.
Nun, ist so.
> Reichelt hat sie übrigens lieferbar.
Bei Reichelt habe ich einen bestellt.
TME hat die übrigens auch, Watterott hat die auch schon im Shop.
Reichelt hat nur scheinbar eine seltsame Vorstellung davon was lieferbar
bedeutet, ich bin gespannt wann das Ding hier ist.
Christoph M. schrieb:> Was spricht gegen die Verwendung von PlatformIO?
Das man den mit PlatformIO noch nicht verwenden kann, mir wäre das auch
lieber aber so habe ich gestern als ersten Test meine Library mit der
Arduino "IDE" 1.8.19 compiliert.
Und zumindest hat mein Test Projekt direkt compiliert.
> Die unterstützen das Arduino-Framework und ziemlich viele Prozessoren.
Ja, schon, tolle Sache, vor allem schreibt man in die Config was man
benutzen möchte und das wird installiert.
> Sämtliche STM32-Nucleo und Discover Boards werden unterstützt.
Nein, werden sie nicht.
Ich habe hier schon länger ein Nucleo-Co31C6 liegen das nicht
unterstützt wird und der Support für das Nucleo-H503RB das hier auch
liegt wird sich wohl auch noch hin ziehen.
Leider ist es nicht damit getan ein Board-File zu erstellen, das bekomme
ich noch selber hin.
Aber wie man ein Package aufsetzt oder gar ein Framework, so weit bin
ich da noch nicht vorgedrungen.
> Ob die Renesas schon drinn sind,> weiß ich nicht, wird aber sicher so passieren.
Sind sie nicht, von Renesas ist ohnehin kaum was in PlatformIO.
Und dann wird es wohl eher keine Bare-Metal / CMSIS Unterstützung geben,
sondern "nur" Arduino wie bei Atmel SAM oder RP2040.
Die greifen sich im wesentlichen den fertigen Arduino Core und machen da
ein Paket draus.
>Die greifen sich im wesentlichen den fertigen Arduino Core und machen da>ein Paket draus.
Und warum sollten sie das nicht für den Renesas-Arduino-Core tun?
Rudolph R. schrieb:> Leider ist es nicht damit getan ein Board-File zu erstellen, das bekomme> ich noch selber hin.> Aber wie man ein Package aufsetzt oder gar ein Framework, so weit bin> ich da noch nicht vorgedrungen.
Hier ist der Startpunkt:
https://arduino.github.io/arduino-cli/0.21/platform-specification/Rudolph R. schrieb:> aber so habe ich gestern als ersten Test meine Library mit der> Arduino "IDE" 1.8.19 compiliert.> Und zumindest hat mein Test Projekt direkt compiliert.
Das habe ich gestern auch getestet!
Wegen:
Manfred P. schrieb:> Wir freuen uns schon auf die nächsten Threads "Fehlermeldungen beim> Compilieren für A*UNO". Nach 25 Posts kommt dann Salamischeibe Nummer> zwei "ich habe xyz von Adafruit verwendet"
Was ich von Adafruit getestet habe kompiliert.
Meine eigenen Libs auch alle.
Bis auf eine, die in den AVR ADC Registern rum fummelt.
Die wird gar nicht gefunden, weil in deren Properties "nur für AVRs"
festgelegt ist.
Da kann sich der Manfred wieder entspannen....
Der Error Wildwuchs bleibt aus.
Endgültige Tests stehen noch aus, dank fehlender Hardware.
Arduino F. schrieb:> Der Error Wildwuchs bleibt aus.
Vorausgesetzt, daß auch wirklich alle, die sogenannte "Libs" produziert
haben, sich auch konsequent daran gehalten haben, in deren "Properties"
zu vermerken, für welche Hardware sie geeignet sind.
Warum habe ich nur leichte Zweifel daran, daß dem so ist?
Harald K. schrieb:> leichte Zweifel
"wirklich alle"
Naja...
Tausende.... und dann "alle".
Das ist eine überzogenen Erwartungshaltung.
Gerade auch weil es keinen allmächtigen Dompteur in dem Umfeld gibt.
Wenn ein neues Produkt in die Arduino IDE integriert wird, wird es schon
an ein paar Ecken Probleme geben.
So war es bisher immer.
Sollte einen also nicht wundern.
Anders rum wäre das schon überraschender.....
Libs, welche noch gewartet werden, werden korrigiert werden.
Aber, dass dieses Forum mit sowas überschwemmt wird, steht nicht in
Aussicht.
Gerade das von Manfred genannte Adafruit, das ist bekannt dafür die
nötigen Anpassungen recht zeitnah vorzunehmen.
Veit D. schrieb:> Ein direkt angeschlossenen Mosfet kann man ja mit üblichen 4mA> nicht vernünftig schnell schalten. Das ist schon mit 20mA> grenzwertig nur reicht das fürs "basteln"
20mA und "vernünftig schnell" will man aber auch nicht auf den GND- und
VPP-Pins sehen.
Arduino F. schrieb:> Joachim B. schrieb:>> was stimmt denn nun Platinendruck oder Beschreibung?>> Vermutlich beides falsch!>> Die 6 Polige Stiftleiste ist sicherlich SPI (ohne /CS), wie es z.B. vom> Ethernet Shield und manchen LCDs erwartet wird.
Alles falsch? ICSP™ ist ein Warenzeichen von Microchip, wie geht das mit
Renesas zusammen?
Wastl schrieb:> Tam H. schrieb:>> Arduino entschied sich für den RA4M1 – eine auf einem Cortex M4-Kern>> samt FPU basierende MCU, die Renesas wie in der Abbildung beschreibt.>> Wenn es denn von Renesas eine vernünftige kostenlose IDE gäbe> (gibt es die?) dann konnte man mit diesem Arduino abseits der> von mir nicht gerade geliebten IDE und deren APIs mal mit einem> ARM-Prozessor arbeiten der nicht von STM und Atmel ist. Und> in der Praxis sehen welche Vorteile und/oder Nachteile es gibt.
Zumindest für nicht kommerziell kostenlos:
https://www.segger.com/products/development-tools/embedded-studio/
Falls jemand ein RTOS darauf laufen lassen möchte, könnte ich dafür
evtl. ein Board Support Package erstellen:
https://wiki.segger.com/Board_Support_Package
Wastl schrieb:> Tam H. schrieb:>> Arduino entschied sich für den RA4M1 – eine auf einem Cortex M4-Kern>> samt FPU basierende MCU, die Renesas wie in der Abbildung beschreibt.>> Wenn es denn von Renesas eine vernünftige kostenlose IDE gäbe> (gibt es die?) dann konnte man mit diesem Arduino abseits der> von mir nicht gerade geliebten IDE und deren APIs mal mit einem> ARM-Prozessor arbeiten der nicht von STM und Atmel ist. Und> in der Praxis sehen welche Vorteile und/oder Nachteile es gibt.https://www.renesas.com/us/en/software-tool/e-studio#overview
Wie gut oder schlecht das ist kann ich aber nicht sagen.
Matthias
Interessant wäre, ob es irgendwann einen Nano R4 geben wird. Gleicher
Formfaktor wie der aktuelle Nano, 5V-kompatibel, nur etwas schneller und
mehr Programm-, Variablen- und EEPROM-Speicher.
Christoph M. schrieb:>>Die greifen sich im wesentlichen den fertigen Arduino Core und machen da>>ein Paket draus.>> Und warum sollten sie das nicht für den Renesas-Arduino-Core tun?
Um mich zu zitieren:
"Sind sie nicht, von Renesas ist ohnehin kaum was in PlatformIO.
Und dann wird es wohl eher keine Bare-Metal / CMSIS Unterstützung geben,
sondern "nur" Arduino wie bei Atmel SAM oder RP2040.
Die greifen sich im wesentlichen den fertigen Arduino Core und machen da
ein Paket draus."
Es ging nicht darum, dass das nicht passieren wird.
Es ging darum, dass ich keine Hoffnung habe, dass da mehr passieren
wird.
Arduino F. schrieb:>> Aber wie man ein Package aufsetzt oder gar ein Framework, so weit bin>> ich da noch nicht vorgedrungen.> Hier ist der Startpunkt:> https://arduino.github.io/arduino-cli/0.21/platform-specification/
Das Thema war PlatformIO, nicht Arduino Cores.
Arduino F. schrieb:> Gerade das von Manfred genannte Adafruit, das ist bekannt dafür die> nötigen Anpassungen recht zeitnah vorzunehmen.
Gerade bei Adafruit würde ich nicht erwarten, dass da zeitnah was
passiert.
Ich habe seit über einem Jahr einen kleinen Pull-Request in einem
Adafruit Repository hängen um einen Bug zu fixen.
Also nicht mal nur ein Issue, gleich fertig.
Wenn auf Bug-Reports die Reaktion ist "machs dir selbst, ist doch open
source", dann sieht das nach kompletter Zeitverschwendung aus wenn
Pull-Requests glatt ignoriert werden.
Martin schrieb:> Interessant wäre, ob es irgendwann einen Nano R4 geben wird. Gleicher> Formfaktor wie der aktuelle Nano, 5V-kompatibel, nur etwas schneller und> mehr Programm-, Variablen- und EEPROM-Speicher.
Man hätte sich sowas vor Jahren schon mit einem ATSAMC20 oder ATSAMC21
bauen können, also Cortex M0+ auf 48MHz und damit etwas langsamer als
der UNO R4, aber eben auch 5V und deutlich mehr Speicher als der M328.
Rudolph R. schrieb:> Man hätte sich sowas vor Jahren schon mit einem ATSAMC20 oder ATSAMC21> bauen können
Heute könnte man sich so etwas mit den etwas einfacheren Varianten der
RISC-V-µCs von WCH bauen, der CH32V103x8x6 wäre da ein Kandidat. Kann
mit 5V betrieben werden (also nicht nur 5V-tolerante I/Os), 20 kiB RAM,
64 kiB Flash, bis zu 72 MHz CPU-Takt, LQFP/QFN48 und LQFP64. Ist wohl
was die Peripherie angeht, sehr nah am ST32F103 und seinen diversen
Klonen angelegt ...
Und dann hat man die Freude der Eindeutigkeit chinesischer Datenblätter
und Entwicklungsdokumentation. Hat halt alles zwei Seiten.
(Wie die Performance eines RISC-V gegenüber eines ARMs aussieht, wäre
auch noch zu vergleichen)
Rudolph R. schrieb:> Ich weiß nicht, ob das hier schon mal erwähnt wurde:> https://github.com/arduino/ArduinoCore-renesas
Das gefällt mir übrigens nicht so wirklich.
Es gibt da nämlich in dem Paket keinen Source-Code für die
Funktions-Einheiten auf dem Chip, also sowas wie SPI.
Das wird als lib rein gelinkt: libfsp.a
Die SPI Klasse ist zum Beispiel rein generisch und den Kommentaren nach
von 2014.
Also kein DMA Support.
Damit wird der SPI kaum schneller laufen als beim UNO, immerhin könnte
der SPI theorethisch nach Datenblatt mit 24 MHz Takt laufen (PCLKA / 2).
Der Controller könnte 8/9/.../16/20/24/32 Bit Transfers machen,
die SPI Klasse arbeitet aber fest mit 8 Bit.
Es gibt zwar SPI.transfer16(uint16_t data), da werden aber zwei Mal 8
Bit verschickt.
Immerhin gibt es auch noch SPi.transfer(void *buf, size_t count).
Und Reichelt hat verschickt, die Zeichen stehen gut für neues Spielzeug
zum Wochenende. :-)
Rudolph R. (rudolph)
>Man hätte sich sowas vor Jahren schon mit einem ATSAMC20 oder ATSAMC21>bauen können, also Cortex M0+ auf 48MHz und damit etwas langsamer als>der UNO R4, aber eben auch 5V und deutlich mehr Speicher als der M328.
Das hat man schon vor Jahren getan, allerdings war das kein
Erfolgsprodukt:
https://store.arduino.cc/products/arduino-zero
Mir gefällt der Name "Uno" nicht, obwohl ein völlig anderer
Mikrocontroller verwendet wird, als bei den vorherigen Unos.
Die Antenne des ESP Moduls ist schlecht platziert. Da hätten sie mal den
HW Design Guide von Espressif lesen sollen.
Martin schrieb:> Interessant wäre, ob es irgendwann einen Nano R4 geben wird.
Kennst du Nucleo32 Boards? Die kannst du mit der Arduino IDE
programmieren.
Christoph M. schrieb:> Rudolph R. (rudolph)>>Man hätte sich sowas vor Jahren schon mit einem ATSAMC20 oder ATSAMC21>>bauen können, also Cortex M0+ auf 48MHz und damit etwas langsamer als>>der UNO R4, aber eben auch 5V und deutlich mehr Speicher als der M328.>> Das hat man schon vor Jahren getan, allerdings war das kein> Erfolgsprodukt:>> https://store.arduino.cc/products/arduino-zero
War mitten im Arduino-Bürgerkrieg, lies sie konnten das Ding nicht
effizient promoten. Außerdem das 3V3 bzw 5V0-Problem...
Ich habe den R4 erhalten und gerade ausprobiert.
Erster Eindruck: grauenhaft
Ich habe ein Projekt in der Arduino IDE 1.8.19 compiliert und auf den
UNO R4 gespielt, das klappt soweit einwandfrei.
Die Software lief auch praktisch sofort.
Das ist das hier: https://github.com/RudolphRiedel/FT800-FT813
Also angesteuert wird ein TFT per SPI.
Für die Arduino IDE habe ich mein Beispiel Projekt angepasst,
normalerweise benutze ich PlatformIO.
In der .ino wird die Funktion TFT_display() aufgerufen und die Laufzeit
der Funktion wird mit micros() gemessen.
UNO R3 (clone): 532µs
UNO R4 MINIMA: 2532µs
Kein Tippfehler, der 3x schneller getaktete R4 braucht fast fünf Mal so
lange für exakt die gleiche Funktionalität.
Dabei gehen beide durch die SPI Klasse, normalerweise gehe ich für die
AVR Arduinos an der SPI Klasse vorbei direkt auf die Register für den
Transfer.
Habe ich auch gerade gemessen, sind 520µs, also eine eher schwache
Optimierung.
Der SPI Takt ist 8MHz für beide Boards, ein Byte braucht auf dem SPI
1µs.
Nun, warum ist das so?
Die angehängten .sal Files sind für die Logic 2 Software von Saleae.
Im Logic-Analyzer Trace für den R3 sieht man, dass die Pausen zwischen
den Bytes beim UNO R3 so zwischen 1µs und 2µs sind gelegentlich gibt es
auch mal eine Pause von 7µs.
Im Trace für den R4 sieht man, dass die Pausen zwischen den Bytes um
11µs Länge haben - autsch.
Da der Source-Code für den SPI Treiber nicht im Arduino Core ist, sieht
man zum einen nicht was zum Geier der auf dem R4 da treibt, zum anderen
kann man den auch nicht mal eben so manipulieren und neu compilieren,
toll.
Den SPI Takt anzuheben bringt unter den Umständen auch nichts.
Ich wundere mich gerade was da los ist.
Ist da beim R4 ein RTOS drunter? Sieht eigentlich nicht danach aus.
Oder ist das einfach nur ein Fall von miesem Code vom Chip Hersteller
der mit angezogener Handbremse läuft, weil bei jedem Aufruf die SPI
Schnittstelle komplett konfiguriert wird und drölf sinnlose Checks
durchgeführt werden?
Hurra, ein neuer UNO mit mehr Speicher und schnellerem Controller der je
nach Anwendung läuft wie ein mit 4MHz getakteter AVR.
Mal schauen was man da machen kann...
Rudolph R. schrieb:> Oder ist das einfach nur ein Fall von miesem Code vom Chip Hersteller> der mit angezogener Handbremse läuft, weil bei jedem Aufruf die SPI> Schnittstelle komplett konfiguriert wird und drölf sinnlose Checks> durchgeführt werden?
So in etwa. Schau dir mal die SPI-Umsetzung von RP2040 an, die ist auch
lahm!
Falk B. schrieb:> So in etwa. Schau dir mal die SPI-Umsetzung von RP2040 an, die ist auch> lahm!
Oder ESP32, geht auch gar nicht.
Aber wenigstens habe ich beim ESP32 und auch RP2040 heraus gefunden wie
man SPI über DMA macht, auch für Arduino, nur an der SPI Klasse vorbei.
Und das war beim RP2040 gar nicht mal so schwierig.
Für den R4 werde ich da nicht drum herum kommen, genau wie beim ESP32
ist das sonst praktisch unbrauchbar.
Aber ok, das ist der halbe Spaß, auch wenn mir eine brauchbare SPI
Klasse lieber gewesen wäre.
Ich habe gerade noch etwas gespielt und die SPi.transfer(void *buf,
size_t count) Funktion verwendet die ich in der SPI Klasse gesehen
hatte.
Den Code um einen Puffer zu füllen habe ich für DMA ja eh vorgesehen.
Nun ja, damit bin ich jetzt bei 690µs für den R4, was immer noch traurig
ist.
Die reine Zeit für das was in dem Puffer übertragen wird ist 524µs beim
UNO R3 und 643µs beim UNO R4.
Wobei der Aufwand die Daten für den Puffer zu erzeugen beim R3 enthalten
ist und beim R4 noch dazu kommt, das sind noch mal so 30µs Plus für den
R4.
Oh man.
Ach ja, bevor jemand auf die Idee kommt das zu zählen, das sind nur 228
Bytes die da für ein Bildschirm Update verschickt werden.
Mein Test Programm zeigt kaum was an.
Veit D. schrieb:> Hallo,>> dann schreibe dir eine neue SPI Klasse und gut ist.
Warum können das die Leute nicht, welche für Arduino arbeiten?
Fachkräftemangel?
Hallo,
ich spreche aus meiner Sicht, ich muss Arduino nicht in Schutz nehmen.
Aber man muss Arduino nüchtern betrachten. Für die Leute für die es
gedacht ist funktioniert es. SPI ist vorhanden und funktioniert. Nicht
mehr und nicht weniger. Arduino muss in erster Linie auf Kompatibilität
ihrer bereitgestellten Klassen achten.
Tja und dann gibts Leute wie hier im Forum die zerlegen jedes Register
Bitweise und erwarten maximalen Speed. Wenn man den Anspruch hat muss
man es selbst schreiben wie für jeden anderen Controller auch. Ganz
einfach.
Was mich nur echt wundert ist, dass wird hier ganz deutlich. Die ganze
Zeit schreit regelrecht "das Forum" permanent aus vollen Hals wie Sch...
doch Arduino und die IDE ist und dann wollen plötzlich alle deren
Klassen nutzen. Und ich dachte die meisten Leute hier im Forum nutzen
nur das Arduino Board weil es günstig ist und programmieren alles Bare
Metal. Ihr solltet euch nun einmal langsam entscheiden. ;-)
Hallo,
Rudi, messe bitte einmal wie lange digitalWrite() benötigt. Musste aber
mehrfach hintereinander in die loop() schreiben. Sonst verfälscht der
ständige loop() Aufruf die Messung. Dann kann man abschätzen ob generell
eine Handbremse vorhanden ist oder nicht.
Veit D. schrieb:> ich spreche aus meiner Sicht, ich muss Arduino nicht in Schutz nehmen.> Aber man muss Arduino nüchtern betrachten. Für die Leute für die es> gedacht ist funktioniert es. SPI ist vorhanden und funktioniert. Nicht> mehr und nicht weniger. Arduino muss in erster Linie auf Kompatibilität> ihrer bereitgestellten Klassen achten.
Das schließt Leistung und Qualität nicht aus.
> Tja und dann gibts Leute wie hier im Forum die zerlegen jedes Register> Bitweise und erwarten maximalen Speed. Wenn man den Anspruch hat muss> man es selbst schreiben wie für jeden anderen Controller auch. Ganz> einfach.
Nö, nicht ganz einfach. Man kann auch ab und an mal etwas Qualität und
Leistungsfähigkeit deutlich über der Teppichkante erwarten. Alles andere
ist erbärmliche Bloatware, welche leider nur allzu verbreitet ist.
https://de.wikipedia.org/wiki/Bloatwarehttps://de.wikipedia.org/wiki/Wirthsches_Gesetz
Ich habe gerade per digitalWrite() einen Pin wackeln lassen:
digitalWrite(EVE_PDN, HIGH);
digitalWrite(EVE_PDN, LOW);
digitalWrite(EVE_PDN, HIGH);
digitalWrite(EVE_PDN, LOW);
...
So beim Start in der setup().
UNO R3: 3,5µs -> ~56 Taktzyklen @16MHz
UNO R4: 800ns -> ~38 Taktzyklen @48MHZ
Ok, nicht toll, aber schneller, absolut und im Verhältnis.
Schönes Ding am Rande, es sah kurz aus als hätte ich den R4 gebrickt da
ich aus Versehen den Reset Taster betätigt habe während der noch am
Flashen war.
Der ist dann komplett tot am USB.
Man kommt dann in den Bootloader wenn man den Reset Taster zwei Mal
schnell betätigt.
Allerdings bin ich der Meinung das der Bootloader eine unvollständig
geflashte Anwendung gar nicht erst starten sollte.
Veit D. schrieb:> Und ich dachte die meisten Leute hier im Forum nutzen> nur das Arduino Board weil es günstig ist und programmieren alles Bare> Metal. Ihr solltet euch nun einmal langsam entscheiden. ;-)
Ich bin nur ich und nicht die meisten Leute, ich nutze die Arduino
Boards und die Arduino API praktisch gar nicht, die Arduino "IDE" erst
recht nicht.
Ich unterstütze das nur mit meiner Library, da ich gerade Spaß daran
habe den Controller Support möglichst breit zu machen.
Und ich schaue da auch nur auf den SPI, was anderes nutze ich praktisch
nicht.
Demzufolge werde ich mir auch nicht die Arbeit machen für den UNO R4
eine Build-Umgebung aufzusetzen oder auch nur ein Makefile zu schreiben.
Und ich empfehle ganz klar PlatformIO mit VSCode zu verwenden, das geht
nur bislang nicht.
Für mich ist der UNO R4 ein neues Spielzeug und dabei ein exotisches im
Bezug auf den verbauten Controller von Renesas.
Hier liegt zwar zum Beispiel auch länger schon ein Eval Board mit einem
RX660 herum, aber für den Software zu machen war mir bisher zu viel
Arbeit, also einfach so zum Spaß.
Mit schlapp 20 Euro finde ich das R4 recht teuer.
Wenn man überlegt das ein Teil davon in die Software geht dann
relativiert sich das etwas, im Moment steckt in der SPI Klasse an sich
aber Null Arbeit und da der eigentliche Code in einer Lib vergraben ist
kann man den nicht mal eben so auf die Schnelle ändern.
Ich hatte mich auch für das Early Adopters Programm angemeldet, die
haben ja extra Leute gesucht die Hardware spezifische Anpassungen
machen.
Nur wollten die meine unbezahlte Arbeit nicht, ist dann so.
Hallo,
Danke für den Test.
Den Rest lasse ich so stehen, hat jeder seine Meinung, soll man haben.
Wegen PlatformIO. Damit werde ich bis heute nicht so richtig warm. Ich
weiß aber jetzt an wem ich mich wenden kann zu Fragen für PlatformIO.
:-)
Ruhiges WE allen.
Veit D. schrieb:> Was mich nur echt wundert ist, dass wird hier ganz deutlich. Die ganze> Zeit schreit regelrecht "das Forum" permanent aus vollen Hals wie Sch...> doch Arduino und die IDE ist
Wirklich "das Forum" oder eher nur ein paar Schreihälse?
> und dann wollen plötzlich alle deren Klassen nutzen.
Genau das tue ich, wobei die nicht unbedingt aus "offiziellen" Quellen
stammen, z.B. ADS1115 von lygte-dk und SSD1306 von github.com/greiman/.
> Und ich dachte die meisten Leute hier im Forum nutzen> nur das Arduino Board weil es günstig ist und programmieren alles Bare> Metal.
Ich hatte bislang weder Lust noch Not, das zu tun.
> Ihr solltet euch nun einmal langsam entscheiden. ;-)
Ich weiß, was ich tue - und habe aus genau diesem Grund Bedenken
geäußert, was die Kompatibilität des R4 angeht. Das hat mir auch den
Spaß am ESP32 verhagelt, weil vorhandenes Zeug für den nicht ohne große
Änderungen nutzbar ist.
Hallo,
man sollte jetzt nicht ESP mit Arduino verwechseln oder über einen Kamm
scheren. ESP ist speziell und die ganzen ESP Boards sind vom Pinout her
speziell. ESP hat auch nichts mit Arduino zu tun. Alles was fremd ist
kann zwar die IDE nutzen aber der ganze Rest hat nichts zu sagen.
Ich sehe erstmal keine Bedenken bezüglich des R4. Der Formfaktor lässt
da nichts anderes zu. Welche Bedenken hast du denn konkret?
Veit D. schrieb:> man sollte jetzt nicht ESP mit Arduino verwechseln oder über einen Kamm> scheren. ESP ist speziell und die ganzen ESP Boards sind vom Pinout her> speziell.
Formfaktor und Spannung sind für mich zweitrangig, ich spiele nicht auf
Steckbrettchen und kann Hardware.
Veit D. schrieb:> Ich sehe erstmal keine Bedenken bezüglich des R4. Der Formfaktor lässt> da nichts anderes zu. Welche Bedenken hast du denn konkret?
Sagte ich doch: Existierende Klassen (Arduino "Libraries") sind für AVR
gemacht und passen nicht zum neuen µC.
Mein Traum: Ich nehme das Programm meines Akkutesters von 2020, was mit
98% noch gerade so in den UNO passt und packe das auf den R4. Ich bin
mir sicher, dass das nichts wird.
Hallo,
ich glaube du erzählst nur Mist. Wenn du Hardware kannst verdirbt nichts
den Spaß.
Und was soll der wiederholte Unsinn mit dem Arduino Libs. Wer sagt denn
das die Arduino Libs nur für AVR gemacht sind? Kennst du die Arduino
Produktpalette? Schon einmal deren Seite angeschaut?
Wer kompatible Libs schreibt und schreiben möchte und kompatible
Programme schreibt und schreiben möchte der verwendet nur Arduino
Standard Funktionen/Methoden. Die gibt es immer und funktionieren immer.
Maximal noch eigene Libs die man selbst anpassen kann. Daraus folgt,
wenn fremde Libs sich daran halten werden auch diese funktionieren.
Das ist ja der Grund für diese gewachsene Arduino Framework. Eben damit
alles abstrahiert werden kann. Der kleine Wermutstropfen ist das nicht
alles so schnell ist wie es Bare Metal ggf. sein könnte.
Wegen deinem Programm. Probiere es doch einfach aus. IDE auf R4 Stand
bringen und Programm kompilieren, gucken welche Meldungen erscheinen.
Aber warum sage ich das überhaupt. Habe das Gefühl das willst du gar
nicht hören. Du wünscht dir ja regelrecht das es nicht funktioniert.
Falls jemand eine schnellere SPI.cpp für den R4 braucht und dafür mit
einem Entwurfs-Stand leben kann, ich habe angefangen das zu
beschleunigen.
https://github.com/RudolphRiedel/ArduinoCore-renesas/tree/main/libraries/SPI
Bisher läuft das nur mit dem SPI und nicht mit den SCI im SPI Modus.
Und vermutlich läuft das nur als Master, wobei ich bei der
ursprünglichen Implementierung nicht mal sicher bin ob die nicht auch
nur als Master funktioniert.
Das ist bisher auch noch mit der originalen SPI API, also kein DMA und
keine nur-Schreiben Funktionen, ich habe keine Ahnung wie offen man bei
Arduino für Erweiterungen der API ist.
Aber nun ja, der DUE ist zum Beispiel 11 Jahre alt, hat die gleiche API
und unterstützt kein DMA.
>ich habe keine Ahnung wie offen man bei>Arduino für Erweiterungen der API ist.>Aber nun ja, der DUE ist zum Beispiel 11 Jahre alt, hat die gleiche API>und unterstützt kein DMA.
Da dürfte das Problem liegen: überhaupt nicht offen.
Es dürfte ziemlich viele Leute auf der Welt geben, die am Standard etwas
verändern wollen. Um so mehr es sind, um so schwieriger wird es.
Man könnte hier einen Versuch wagen: Einen
Mikrocontrollernet-Arduino-API Standard. Man diskutiert die
Funktionalität und wenn man sich geeinigt hat, implemtiert der ein- oder
andere die Funktion auf einer der MCU Architekturen.
Christoph M. schrieb:> Einen> Mikrocontrollernet-Arduino-API Standard.
eher gefriert die Hölle...
Ein PR ist schon der richtige Weg. Aber ich auch mal einen
offensichtlichen Fehler gemeldet der nie beachtet wurde. Es gibt
scheinbar nicht viele aktive Maintainer in den Arduino Repos, altes Zeug
lässt man vergammeln.
Rudolph R. schrieb:> ich habe keine Ahnung wie offen man bei> Arduino für Erweiterungen der API ist.
Erweiterungen mögen gehen...
Solange es zum original kompatibel ist/bleibt.
Verbesserungen werden angenommen, mag allerdings ein zäher Prozess
werden, da eben auch wirklich viele Libs auf der SPI Lib basieren bzw.
sie nutzen.
Aber was du problemlos machen kannst, ist deine eigene SPI Lib bauen und
publizieren. Auch so, dass sie vom LibraryManager gefunden wird.
Wenn sie gut angenommen wird, "könnte" es sein, dass sie in das Paket
übernommen wird. Da bin ich allerdings auch nicht so optimistisch.
Tja nun, erstmal schauen das es für einen Pull-Request reicht, mein
Display läuft hier jetzt schon seit 6 Stunden nebenbei vor sich hin,
alle 20ms ein Update, alle 5 ms eine Touch-Abfrage, bei 24 MHz SPI Takt.
Der Teil mit den dafür vorgesehenen SPI Pins tut schon mal was er soll.
:-)
Wenigstens
void ArduinoSPI::transfer(void *txBuf, void *rxBuf, size_t count)
sollte ich dem wohl noch mit geben, so mit der Option rxBuf auf NULL
setzen zu können.
DMA kann man sonst auch an der SPI Klasse vorbei implementieren, bzw.
ging ja bisher bei Arduino auch nicht anders, mal von Ausnahmen wie der
Teensy Implementierung abgesehen.
Nur wünsche ich mir schon das meine Library mit den anderen in der
Sandkiste zusammen spielt...
Übrigens ist die Dokumentation von Renesas zum RA4M1 interessant.
Ich habe den SPI erst nicht zum Laufen bekommen, habe dann aber gesehen
das in der Renesas FSP Library ein Bit gesetzt wird das im User Manual
nicht dokumentiert ist.
In den Includes ist das Bit aber.
Dazu hat Renesas ein "Technical Update" veröffentlicht - statt das User
Manual zu aktualisieren.
Ohne SPBYT im Register SPDCR zu setzen macht der SPI im 8-Bit Modus gar
nichts.
Im gleichen Register gibt es in den Includes noch zwei 2-Bit Symbole die
nirgendwo erwähnt werden.
Und es gibt noch das Register SPDCR2 für das es nicht mal ein "Technical
Update" gibt, zumindest nicht öffentlich, wenn man das BYSW Bit da drin
nicht setzt kommen die Bytes beim 32 Bit Transfer in der falschen
Reihenfolge raus.
Sowas macht richtig Lust auf noch mehr Schnitzel-Jadg, den DMA zu
verwenden könnte interessant werden.
Hat hier eigentlich schon wer CAN mit dem UNO R4 am laufen?
Da der Takt aus einem der internen Oszillatoren kommt, MOCO meine ich,
würde mich mal interessieren, ob der UNO R4 überhaupt sauber CAN
Botschaften verschicken kann.
Ich messe hier gerade am SPI der mit PCLKA läuft nicht 24MHz, sondern
23,81MHz, gemessen mit einem Logic Pro 8 bei 500MS/s.
Der CAN läuft mit PCLKB und PCLKB sollte 12MHz haben.
Ich habe nur kein CAN-Transceiver Breakout Board herum liegen um selber
zu testen was etwa bei 8 Byte und 1Mbps passiert.
Thread beobachten
Seitenaufteilung abschalten