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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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 im Beitrag #7443554:
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.
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?
"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.
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 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.
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.
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.
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.
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.
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.
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)
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. :-)
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:
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:
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.
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!
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.
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. ;-)
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.
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.
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.
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.
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. :-)
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.
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?
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.
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.
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.
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.
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.
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.
