Arduino introduceert Uno R4-microcontroller met 32bit-Arm-cpu

Arduino heeft de Uno R4-microcontroller aangekondigd. Het bordje maakt gebruik van een 32bit-Arm-cpu met een kloksnelheid van 48MHz. De R4 heeft 32 kilobyte ramgeheugen en 256 kilobyte opslagruimte. Het bordje komt in mei uit. Hoeveel het moet kosten, is niet duidelijk.

De Arduino Uno R4 beschikt over een nieuwe Renesas RA4M1-cpu. Dat is een 32bit-soc die gebaseerd is op de Cortex M4-architectuur van Arm. Volgens het Italiaanse bedrijf zijn de meeste softwarelibrary's compatibel met deze cpu, maar zullen er in sommige gevallen alsnog kleine aanpassingen nodig zijn. Het bedrijf zal een lijst beschikbaar stellen met zulke library's. De R4 beschikt ook over een 12bit-dac, een USB-C-poort en een CAN-seriële databus. Het bordje kan een maximale spanning van 24V aan.

Er komen twee versies van de Uno R4. Een versie zal beschikken over een wifi- en bluetoothmodule, terwijl de andere het zonder deze draadloze technologie moet doen. Het bedrijf zegt dat de microcontroller eind mei op de markt komt, maar deelde nog geen exacte datum mee. Het is ook niet duidelijk hoeveel de Uno R4 zal kosten. Geïnteresseerden kunnen zich wel inschrijven op een wachtlijst om het bordje zo snel mogelijk te kopen.

Arduino Uno R4

Reacties (63)

[NLkaiser]

Ik snap niet zo goed dat er nu nog nieuwe 32-bit producten uit komen

https://en.m.wikipedia.org/wiki/Year_2038_problem

[youridv1]

Als je het vanaf de pc-markt bekijkt, kan ik dat heel goed begrijpen.

64 bit biedt alleen weinig tot geen voordelen voor heel erg veel embedded implementaties. Je bent in 99% van de gevallen niet gelimiteerd door de 32 bits architectuur. Dus dan heeft het ook geen zin om te investeren in een duurdere chipset.

Die wiki link is leuk, maar zoals hieronder al is uitgelegd, kun je gewoon 64 bit integers gebruiken op 32 bits chips. Het is werkelijk zo eenvoudig als een ander woordje gebruiken op de plek waar je de variabele declareert en dan heb je ineens een 64 bit integer, waardoor dat hele probleem wegvalt.
Alleen heeft het meerendeel van de embedded systemen uberhaupt geen concept van “tijd”. Veel meer dan de interne clock, of een externe hardware clock eventueel, is meestal niet nodig.
Ze nemen meestal gewoon aan dat tijd is begonnen toen zij zijn opgestart.

Er wordt vaak uberhaupt geen gebruik gemaakt van getallen groter dan 32 bits. Je ziet vaker dat er bewust wordt gekozen voor getallen met een nog lagere limiet, zoals 16 of 8 bits omdat dit snelheid en/of opslag voordelen heeft.

Je moet arduino’s niet zien als een raspberry pi ofzo. Ze draaien geen OS. Ze draaien echt alleen code specifiek voor hun doel

[Reactie gewijzigd door youridv1 op 23 juli 2024 03:32]

[farlane]

Nou is het zo met de huidige "IoT" boom dat dit soort controllers meer en meer een (RT)OS draaien maar ook meer en meer door hun "connected" zijn een datum/tijd nodig hebben om bijvoorbeeld TLS en daarmee bv ook HTTPS te kunnen gebruiken.

Bare metal is eigenlijk alleen nog maar bij de allerkleinste toepassingen aan de hand, maar dat is niet deze controller.

[Amanoo]

Is dat niet deze controller? Een controller vereist doorgaans geen RTOS. Het is een optie waar de developer voor kan kiezen. Je kan prima een enkel programma met 1 doel op een CPU knallen die ook een RTOS had kunnen draaien. De Arduino Due bijvoorbeeld heeft een Cortex M3 met een nog veel hogere kloksnelheid, maar die draait meestal ook geen RTOS. En de M3 en M4 schelen niet zo enorm veel.

[Reactie gewijzigd door Amanoo op 23 juli 2024 03:32]

[farlane]

Het is niet dat het niet kan, maar het komt steeds minder voor. Als je iets simpels bare-metal wilt doen is een Cortex-M0(+) meestal voldoende.

[diondokter]

Ik heb het idee dat dat vooral is omdat ecosystems aan een RTOS gekoppeld zitten en niet zozeer voor de RTOS zelf. Dat komt ook door de combinatie van de dramatische dependency management en de afwezigheid van echte abstractie methodes in C. Dus als je productief wil zijn, zul je nou eenmaal snel grijpen naar een Zephyr of een stm32cube.

Zelf ben ik nu ruim 3 jaar fulltime embedded Rust development aan het doen. Dependencies en abstractions zijn heel makkelijk daarin. En wat grappig is om te constateren is dat vrijwel niemand een RTOS gebruikt. Omdat vrijwel alle drivers en HALs van dezelfde abstracties gebruik maken (link) is alles behoorlijk portable tussen verschillende chips, maar ook tussen verschillende runtimes.

In de praktijk resulteert dat in dat je bijzonder vrij bent in wat voor runtime je wil gebruiken. Dat kan zijn bare-metal, dat kan met RTIC (een runtime gebaseerd op interrupts), een normale RTOS of zelfs met async code via bijvoorbeeld Embassy. Deze keuzevrijheid is super fijn! Je kan namelijk het beste kiezen voor je project en vaak is dat toch geen RTOS.

(BTW, hot take, de Cortex-M0+ zou gedepricatet moeten worden. Het heeft geen atomics, dus het is niet mogelijk om portable lock-free code of te draaien voor bijvoorbeeld queues en shared ring-buffers)

[farlane]

Ik heb het idee dat dat vooral is omdat ecosystems aan een RTOS gekoppeld zitten en niet zozeer voor de RTOS zelf.

Als je de STMCube gebruikt, heb je default geen OS, maar je kunt ook kiezen voor FreeRTOS of ThreadX/Azure RTOS, maw je hebt nog steeds de keuze waarbij default geen RTOS wordt gebruikt.
Feit is wel dat je als je een netwerk stack nodig hebt bv het vrijwel niet te doen is zonder RTOS.

(BTW, hot take, de Cortex-M0+ zou gedepricatet moeten worden. Het heeft geen atomics, dus het is niet mogelijk om portable lock-free code of te draaien voor bijvoorbeeld queues en shared ring-buffers)

Je zou als je dat soort dingen nodig hebt misschien ook niet een M0 moeten willen. /shrug

[Brousant]

"Feit is wel dat je als je een netwerk stack nodig hebt bv het vrijwel niet te doen is zonder RTOS."

Als je maar 1 netwerkinterface nodig hebt kan dat prima, je gebruikt dan lwip met de raw API.

[farlane]

Vandaar "vrijwel niet te doen", het is in de ecosystemen waar ik voornamelijk mee werk (STM, ESP32 voornamelijk) geen supported use case.

[Brousant]

"geen supported use case"

Als je het daarvan moet hebben, tja, dan wordt het lastig.

[farlane]

Kun je die reactie toelichten? In eerste instantie lijkt 'ie vrij trollerig nl...

[Brousant]

"Kun je die reactie toelichten?"

Ik denk kennelijk iets anders over wat "vrijwel niet te doen" is dan jij.

[Hobbit13]

Ken überhaupt niemand die op een 32bit platform nog zonder os aan de gang gaat, lijkt me ook nodeloos complex.

De meeste embedded systemen zijn inmiddels multicore, daar goed gebruik van maken zonder os is pittig.
En als je aan de gang wilt met wifi, Bluetooth, USB enzo dan wordt het ondoenlijk.

Arduino code draait over het algemeen ook als een soort van applicatie in RTOS.

De radiomodule op deze nieuwe Arduino heeft waarschijnlijk ook al z’n eigen OS en ARM processor.

[Vuikie]

Ik draai code op een Bluepill, Blackpill, Arduino Due zonder RTOS....

Meestal grijp ik naar een RTOS als ik iets met wifi/netwerk moet doen. Zelfs met multi-core is het niet altijd nodig om met een RTOS te werken.

De ESP series zou ik niet aanraden om zonder RTOS te doen, maar kan wel...

Wat deze uno R4 betreft. Ik heb meer het gevoel dat dit een soort 'relevence-move' is. Wat mij betreft is de 328p nog steeds voldoende voor waar een Uno voor bedoeld is. Plus, zoals ik al noemde, zijn er genoeg andere opties die je kan kiezen.

Wat ik wel een goede toevoeging vind is de Giga R1. Naar mijn mening is de Due nooit tot zn volledige potentieel door ontwikkeld en daarom nooit de opvolger geworden van de Mega256.

[SG]

Multi core vereist niet zozeer os. Maar eerder dat de software architectuur en tools rekening houden met shared data. Als je iot project de source code van hebt. Kan je dat niet effe multicore geschikt maken. Omdat code en data het sharen van data geen rekening mee gehouden is. Dus software moet op de schop en naar meerdere threads.
Op zich is zelfs meerdere verschillende chips mogelijk.
STM32 H7 zijn er versies met soort van enkele big en enkele little core.
Er zijn drone flightcontrollers met 2 verschillende STM32 chips.
Ja de opensource bron code moest dan wel geforked worden om software aan te passen voor 2 MCU .
En nee geen OS erop. Daar heeft STM MPU reeks voor.

[memphis]

Je moet arduino’s niet zien als een raspberry pi ofzo. Ze draaien geen OS. Ze draaien echt alleen code specifiek voor hun doel

Is het? Een bootloader is toch ook een vorm van een OS?

[laurxp]

Nee, de bootloader van de meeste (alle?) Arduino's is heel duidelijk géén OS.

Een OS is een stuk software dat altijd draait, en een vertaal- en managementlaag is voor applicatie-code. Denk aan device drivers, hardware abstractie lagen, of functionaliteit om meerdere applicaties parallel te draaien.

De Arduino bootloader is een stukje code dat compleet los staat van de applicatie. Bij het opstarten van de Arduino wordt óf de bootloader, óf de applicatie gestart. De bootloader heeft als enige doel om nieuwe applicatiecode naar de Arduino te schrijven. Als de applicatie draait is de bootloader niet actief, en vice versa.

[dmantione]

In mijn definitie van een besturingssysteem, in de verste verte niet.

[jbhc]

Je moet een arduino meer zien als een PLC

[uiltje]

Nou, ik heb zelf onder andere een 32 bit Java Card integer class gemaakt (Java Card is meestal gelimiteerd op 16 bits signed shorts), en als je eenmaal op dingen als devide, divide&remainder & remainder komt wordt het snel ingewikkeld. Da's natuurlijk nog steeds geen probleem zolang iemand anders het probleem heeft opgelost, maar je moet dan wel calls of macros gebruiken.

[Pieter_621]

Javacard is dan ook wel heel erg spartaans, met ook nog eens magere tooling. Op een 32 bit arm cpu kan je prima met weinig moeite 64 bit berekeningen doen. De C-compilers ondersteunen gewoon direct 64-bit integer datatypes, en je hoeft daarvoor zelf echt helemaal niets te bouwen.

[uiltje]

Ja, dat zal dan ook wel weer. Er moet nog eens een taaltje komen wat er ergens tussenin zit, Open Source natuurlijk. Anyway, de berekeningen zelf zijn verre van triviaal, maar goed, daar hebben we Knuth enzo voor.

[youridv1]

Da's natuurlijk nog steeds geen probleem zolang iemand anders het probleem heeft opgelost, maar je moet dan wel calls of macros gebruiken.

Het is ook geen probleem als je gewoon geen java card gebruikt. Wat je hier noemt zijn geen limitaties van embedded systemen met een 32 architectuur, maar limitaties van java card.

[Reactie gewijzigd door youridv1 op 23 juli 2024 03:32]

[jeroen3]

Nou, niet echt. Veel dingen praten met internet, en dit ding heeft wifi, dus draait er waarschijnlijk een klein OS, en moet hij de tijd weten.
En dat gaat stuk: https://github.com/arduin...b/master/NTPClient.h#L108

Zo even een ander random voorbeeld:
Hier fixen ze het year-2038 probleem door er een year-2136 probleem van te maken.
https://github.com/hwstar...aster/include/time.h#L114

Hier nog een implementatie van arduino zelf die breekt in 2038:
https://github.com/arduin...tform/mbed_rtc_time.h#L44

Hier is nog veel werk aan de winkel.

[Verwijderd]

Sterker nog; meestal is er bij dit soort zaken, als je iets met tijd wilt doen, achteraf nog een losse RTC nodig oid. En daarnaast, is het overdreven om een 64bit architectuur te gebruiken, enkel om een incidentele tijd te gebruiken, terwijl een 64bit int ook gewoon op te breken is in 2 32bit ints.

Maar sowieso werken dit soort controllers niet met real-time tijd, maar anders zal het 99 van de 100 keer gaan om tijd sinds power-on.

[Sissors]

Je kan gewoon de timestamp als 64-bit integer opslaan op een 32-bit systeem he. Kan ook bij een 8-bitter.

[el-Raza]

Veruit de meeste embedded systemen (waar dit soort processors voor worden gebruikt) hebben geen datum/tijd nodig maar hebben genoeg aan een interne klok. Die kan ook een overflow krijgen maar het is meestal erg eenvoudig om code te schrijven die daar goed mee overweg kan.

En zoals @Sissors al opmerkte: je kan ook 64-bit integers gebruiken op een 32- of zelfs 8-bit systeem.

[IStealYourGun]

Dit dus, je zou verbaasd zijn hoeveel 8-bit cpu's vandaag de dag nog gebruikt worden. Ik heb gisteren nog maar een simpele ATtiny45 gebruikt voor een projectje.

[MachIII]

Ik onlangs nog een attiny85 voor een projectje.
Ik zie dan ook geen reden om een groot board aan te schaffen voor een simpele oplossing.

[gday]

Geen probleem om een timestamp gewoon in 64 bits op te slaan hoor.

[akooijman]

In milliseconden gaat zo'n timestamp 250 miljoen jaar mee als ik me goed herinner.
In microseconden is dat pakweg duizend keer minder, maar 250000 jaar is voor de meeste toepassingen bruikbaar.

[IrBaboon79]

32bits betekent niet dat je geen grotere getallen kunt verwerken; het kost alleen wat meer ‘werk’ (om het maar even eenvoudig te houden). 32Bits moet je meer lezen als de hoeveelheid geheugen die je kunt adresseren. Voor een embedded toepassing - mits je geen luxe, hongerige frameworks gaat stapelen - is een paar Kb meestal al voldoende (toepassing afhankelijk natuurlijk) dus tot 4G kunnen is gigantisch.

Het is niet alsof de wereld niet bestond voor er 64 Bit CPUs met gigabytes aan Ram waren; dat geweld van de grote getallen is echt een luxe dingetje. Vergis je niet, een 8bit cpu op een paar MHz is voor de meeste embedded toepassingen al snel genoeg en zelfs overkill; waarom een duurdere nemen?

[Verwijderd]

Ik had op mijn oude 8 bit C64 een stukje software dat kon rekenen met 128 bit getallen.

[IrBaboon79]

Ja, dat is ook geen enkel probleem; meestal een kwestie van wat schuiven/bitwippen in registers en de stack; vergt wat meer "werk" en cycles maar dat kan allemaal gewoon.Voor embedded systemen (vooral het spul in grote aantallen) telt elke cent inkoop uiteindelijk dus een 8bit controller die voldoet voor 1 cent of een 32bit die 5 cent kost is een significante besparing op de inkoop van componenten(*fictieve getallen ter duiding...).

[uiltje]

Een 64-bit CPU heeft ook grotere adres-reeksen he? Die pointers en 64 bit registers nemen ook ruimte in. En wat wil je ermee aansturen? Er zit 32kiB aan RAM in en 256 kiB aan flash. Dat past makkelijk in de ~4GiB dat je kan adresseren.

[quoth]

Wat een rare opmerking. Het overflowen van unix epoch tijd, gemeten in seconden opgeslagen in 32 bit integers, heeft echt geen ene hol te maken met processor architectuur.

[Keyb]

In je link staan genoeg oplossingen voor het probleem zonder stap naar 64 bit producten?

[uiltje]

Er zijn heel wat smart cards die draaien op een 8-bittertje met 16 bit extensions en een 24 bit adres bus. In principe kan je natuurlijk alles programmeren zolang het systeem maar Turing complete is. Praktisch gezien wil je natuurlijk wel een beetje prestaties en genoeg geheugen-ruimte hebben. Daarom hebben dit soort kleine processortjes vaak extra hardware, want je wilt op een 8-bittertje echt geen RSA operaties uitvoeren.

[rdridder]

Y2K bug flashback....

[HakanX]

Precies, we zouden allemaal vergaan, alle satellieten zouden op onze hoofden vallen en niks zou meer werken.

[sys64738]

ik kan je verzekeren dat de code die ik destijds aangepast heb bij een grote verzekeraar, compleet ingestort zou zijn en alle tussenpersonen hun werk niet meer hadden kunnen doen. Dus ja, we was wel echt iets ana de hand.

Epoch wordt minder vaak gebruikt volgens mij (in de systemen waar ik aan werk wel in ieder geval) dus ik verwacht minder problemen dan de vorige keer. En we hebben ook ruim de tijd dit keer.

[Antitech]

In 2000 hing nog niet alles aan computers (en internet) waardoor energiecentrales, waterbedrijven en de deltawerken toen nog relatief weinig problemen hadden. Toen hadden we er 2 jaar voor nodig.

Tegenwoordig is alles connected en dus veel complexer.
We zullen alle code weer moeten checken en aanpassen en daar zijn we ook wel weer minstens een jaar of 2 mee zoet.

[Rrob]

Dat is alleen een probleem als je de tijd in secondes meet.
De meeste micro controllers meten, volgens mij, de tijd in milliseconden en als de 32 bit vol is (na 50 dagen) beginnen ze weer op 0

[akooijman]

Dus wel even opletten wat de maximale tijdsduur (tijdsverloop/verschil) is die je wilt meten.

Als de eigenaar van een huis drie maanden gaat overwinteren in Zuid Spanje zou het alarmsysteem in de war kunnen zijn als hij thuiskomt als daar ergens een tijd-sinds-laastste-event wordt bijgehouden.

[blorf]

Volgens mij scheelt het behoorlijk in de produktie-kosten en voor het toepassen van de architectuur.
Wat wil je doen met 64-bit registers op een systeem van deze omvang?
Als je echt een berekening wil doen met een 64-bit getal kun je ook wel 2 x4 bytes aan elkaar plakken en dat verder als dusdanig behandelen. Alleen als je dat op machine-level doet moet je een redelijke constructie maken om dat op te lossen.

Ik ben eigenlijk wel benieuwd wat dit ding presteert vergeleken met een 386 25Mhz en 640KB. Dat komt er al aardig in de buurt, verwacht ik. Beetje weinig geheugen voor VGA graphics, dat wel.

[Reactie gewijzigd door blorf op 23 juli 2024 03:32]

[Cilph]

En ik zie niet in hoe het 2038 probleem uberhaupt relevant is? Tis niet dat tijd bijhouden gelimiteerd is tot de grootte van je adresbus.

[Reactie gewijzigd door Cilph op 23 juli 2024 03:32]

[Antitech]

Het jaar 2038 probleem zal op dezelfde manier opgelost worden als de y2k-bug. Dus nog wel wat werk te doen om het te fixen, maar geen showstopper.

[sympa]

Zelfs op een 8 of 16 bits processor kan je met 2038-bestendige datum-formats werken.

[memphis]

Renesas lijkt 1 van de weinige die ondanks Corona wel volop kon leveren, ik heb wat producten een re-design zien krijgen naar een Renesas processor. Zal deze stap dan ook een dergelijke achtergrond kennen? De chiptekorten bestaat immers nog steeds en sommige fabrikanten geven aan dat ze pas in 2024 weer alles op orde hebben.

[Amanoo]

Misschien dat de keuze voor Renesas bij een ARM bordje ermee te maken heeft, maar het lijkt me niet dat ze naar Renesas ARM gaan enkel ter vervanging van een ATmega328P uit de gewone Uno. De 328P is wel een stuk duurder geworden door de leveringsproblemen, maar de feature set van de RA4M1 is wel behoorlijk anders.

[DaWaN]

De keuze voor Renesas is waarschijnlijk omdat dit één van de weinige Cortex-M chips die direct op 5V kan werken.

[Ablaze]

Vet dat er CAN ondersteuning is, zit er ook een driver op? Er zijn niet veel experimenteerbordjes die dat direct hebben.
En meerdere UARTs is uiteraard ook erg handig, dat was vaak een bottleneck bij de originele Uno.

Verder goed om te weten dat deze versie gewoon nog 5V compatible is.

[Reactie gewijzigd door Ablaze op 23 juli 2024 03:32]

[tolunaygul12]

Waarschijnlijk een externe driver nodig zoals op de Due bordjes en ESP32 borden.
Een aantal jaar geleden heb ik hiervoor zelf dev-boards gemaakt die 12v compatible zijn en can interface hebben voor gebruik in voertuigen met canbus

[GeeBee]

Wel grappig... een Arduino UNO met een Espressif ESP32-processor aan boord.

[uiltje]

Hmm, 48 MHz is wel een stuk lager dan de andere ESP32's die ik zie in op de site van Espressif. Beter om de processor als een afsplitsing te zien in dat geval (?)

[Reactie gewijzigd door uiltje op 23 juli 2024 03:32]

[Christoxz]

Zijn niet echt directe concurrenten van elkaar.
Arduino maakt development boards(met chips van externe fabrikanten) en Espresif maakt voornamelijk eigen chips.

[harakiri576]

als eindgebruiker, voel ik toch vreemd dat arduino rekent 20 euro voor een atmega328 boordje, terwijl ik een esp32 bordje kan kopen voor een fractie van de prijs.

ik ben wel dankbaar voor arduino en zijn framework, maar 10x verschil in prijs/performance is niet te verklaren.

[mutley69]

Die chinese Esp-module aan boord, hoe gevaarlijk achtten jullie dit?

[Antitech]

Niet gevaarlijk, maar ik zou ze persoonlijk niet gebruiken voor het aansturen van kerncentrales of wapentuig.

[bzzzt]

Ik denk niet dat die module 's nachts op jacht gaat in je huis en je in je slaap vermoord dus denk niet extreem gevaarlijk.
Als je theoretisch exploiteerbare dingen zoekt zal je misschien een issue vinden. Maar die kans is eigenlijk groot bij alle hardware ongeacht de fabrikant, dus dan kan China net zo goed exploits in bv Intel hardware verzamelen. Dat er backdoors verstopt worden door de fabrikant lijkt me onwaarschijnlijk omdat de hoeveelheid code en mogelijkheden daar gekke dingen mee te doen vrij beperkt is. (256 kilobyte valt nog wel te reviewen en ik mag hopen dat dat het geval is voor echt kritische toepassingen).

[uiltje]

Ik zat net een filmpje te bekijken van een 10ct Chinese MIPS. Die draaide ook op 48MHz. Maar het grote verschil wat betreft de CPU zelf is de magere 2kiB aan meegeleverd geheugen. SRAM is duur, want het neemt veel ruimte op de die, maar 2kiB is het wel een beetje erg krap. 32KiB is een zee van ruimte voor embedded processors. Ik raad echter af om iets met geluid of video te doen

De 16 kiB persistent memory is ook 16 keer kleiner, maar daar zou ik zelf iets minder moeite mee hebben. Een beetje OS erop draaien gaat echter niet werken.

[Reactie gewijzigd door uiltje op 23 juli 2024 03:32]

[-=bas=-]

De R4 heeft 32 kilobyte aan ramgeheugen en 256 kilobyte aan opslagruimte.

Voor 5 euro heb je een ESP32 met 4MB flash aan boord.
Waarom Arduino nog steeds vast houdt aan zo'n kleine opslagruimte is me een raadsel?

[Christoxz]

Waarschijnlijk te maken omdat je met Wifi/Bluetooth een groter project opzet, of althans onder de moterkop meer code en dan pas de extra ruimte van pas komst.
Op de UNO R4 WiFi zit een ESP32-S3-MINI-1 module up. Exacte PN is niet zichtbaar en nog niet bekend gemaakt, maar de module zelf is beschikbaar met 4 en 8MB