Arduino Nano V3 versus R4

The main differences are that the Arduino Nano R4 uses a much more powerful 32-bit Arm Cortex-M4 processor (48 MHz) compared to the Nano V3's 8-bit ATmega328 microcontroller (16 MHz), resulting in significantly greater processing power, more memory, and additional features like a 12-bit DAC and CAN bus support on the R4. The R4 also has a USB-C connector, while the V3 uses the older Mini-USB.

Er zit dus een compleet andere MPU op. Maar verder zou volgens mij alles hetzelfde moeten zijn.
Heb je wel echt ook de nano R4 geselecteerd, want als je dat niet veranderd dat werkt het op die andere CPU/MPU niet.
Kan dan best dat je nog een nieuw bord moet downloaden waar de nano R4 wel inzit.

Nee, ik heb wel degelijk de R4 geselecteerd en daarna gedownload.
Dat zat wel goed. De R4 deed de rest, bv ledjes en ingangen allemaal prima.
Maar de communicatie naar de HC12 lukte niet.
Dan denk je Rx en TX verkeerd enz. Dus ook dat was het niet.
Uiteindelijk alles op een breadbord en naast elkaar gezet en vergeleken.
Programma gelijk en aansluitingen gelijk.

En dan kom je er achter na veel testen dat het aan de R4 ligt en dus niet aan het programma.

Maar waarom.....

werk die softserial wel op die poorten?
bij andere arduino's zijn er ook een aantal poorten waar softserial niet op werkt.

dit vond ik op google

The Arduino Nano R4 does not support the SoftwareSerial library, as it has a hardware issue with stop bit transmission, causing errors with the library's communication protocol. While the Nano R4 has a powerful Cortex-M4 microcontroller, its native UARTs and other communication protocols like SPI and I2C are supported, but SoftwareSerial is not compatible.

Limitations with SoftwareSerial
Communication errors: The primary issue is that the Nano R4's hardware has a bug where it does not correctly transmit the stop bit, leading to communication errors when using the SoftwareSerial library.
Code incompatibility: Code written for previous versions of the Arduino Nano using SoftwareSerial will not work as expected on the Nano R4.
Alternatives to SoftwareSerial
Use hardware serial: The Nano R4 has multiple hardware UARTs available, which should be used instead of SoftwareSerial whenever possible for reliable communication.
Use other communication protocols: If you need more serial ports, consider using other protocols like I2C or SPI, which are supported by the Nano R4's microcontroller.
Look for community workarounds: Community members may have developed workarounds for this issue, though these are not officially supported by Arduino. It's important to be cautious when using unofficial solutions.

[Bericht gewijzigd door fcapri op woensdag 15 oktober 2025 21:45:26 (48%)]

Maar waarom.....

Draait de R4 wel op 5V want er zit dacht ik een jumper voor om de spanning te selecteren.
Kan het aan de softserial zelf liggen die speciale functie's van de atmege328 gebruikt.
Is de softserial ook ingesteld voor de goede baudrate. Dan kan bv bij de atmega CPU standaard op 9800 baud staan maar deze CPU is veel sneller en mischien gaat daar wat verkeerd.
Kunnen die gebruikte io pinnen wel werken met softserial of zijn die al in gebruik door iets anders.
Staat op die io pinnen niet per ongeluk iets al pull-up of pulldown aan?

Maat goed allemaal zinloos omdat ik het net even aan google gevraagd heb en die kwam met dit antwoord.

SoftwareSerial doesn't work well on the Arduino Nano R4 because the R4's new Renesas microcontroller requires a different implementation than the AVR-based boards, and the library's port for the R4 is known to have bugs, such as incorrect stop bit timing, and doesn't support all features. A better approach is to use one of the two available hardware serial ports on the Nano R4, such as

and the library's port for the R4 is known to have bugs,

Dat betekend dat ze de oude library van de AVR gewoon hebben vertaald naar code voor de R4 maar dat het verder nog de oude library is. En dan zitten er dus ook nog fouten in die erbij gekomen zijn. Er moet dus nog iemand een keer een aparte library maken die speciaal voor de R4 softserial kan doen.

JE zou kunnen zoeken of ondertussen iemand dat al gedaan heeft en die die software ook ergens op bv github heeft gezet om te kunnen gebruiken.

Nou heren, dan zijn we er inmiddels wel achter hoe en waarom.
Ik was dus in de veronderstelling dat ondanks een andere chip de werking van de nano gelijk bleef, incl de code.
Dus niet.
Dat word dus een bestelling plaatsen voor de v3.

Dank voor jullie inzet,

de werking van de nano kan niet hetzelfde blijven. ze hebben gewoon een andere cpu op een printplaat gezet waar de 'footprint' van de nano ongeveer gelijk is, maar de werking is anders.

dat zie je ook bij het compileren, je moet een andere cpu selecteren, anders komt de code niet overeen en kan de chip er niet op draaien.

libraries zijn dan ook voor bepaalde ECU geschreven, maar dat wil niet zeggen dat het ook compatibel is met een andere

Ik was dus in de veronderstelling dat ondanks een andere chip de werking van de nano gelijk bleef, incl de code.

Dat is in principe ook de bedoeling en een library hoort ook zo gemaakt te zijn dat het over gezet kan woorden naar de nieuwe CPU.
Maar helaas zijn die library's niet allemaal even goed. Ook kan je niet altijd een library CPU onafhankelijk maken omdat die soms ook gewoon snel genoeg moeten zijn.

Misschien heb je hier nog wat aan

Hello!
Not all pins can be used for SoftwareSerial. See this note in the examples for SoftwareSerial on UNO R4:

// Note any pin can be used for TX, but only the following pins
// can be used for RX:
// D0, D1, D2, D3, D8, D14, D15, A1, A2, A3, A4, A5

de werking van de nano kan niet hetzelfde blijven. ze hebben gewoon een andere cpu op een printplaat gezet waar de 'footprint' van de nano ongeveer gelijk is, maar de werking is anders.

Dat is gelukkig niet waar. Alles is gewoon hetzelfde. zelfde io pinnen op dezelfde plaats. Alles hetzelfde. Daarom heet het ook een NANO en het is ook gebracht door arduino zelf juist omdat het dan hetzelfde moet zijn.

Het enige wat anders is zijn dat oude library's die niet altijd werken. En daar moeten dan aangepaste library voor terug komen die wel werkt.

Ook lees ik net dat de R4 wat beperkingen heeft ivm met wel pin je voor RX kan gebruiken.

[Bericht gewijzigd door benleentje op woensdag 15 oktober 2025 23:09:43 (31%)]

De processor op de UNO R4 heeft 4 hardware uarts aan boord, dus dan is het een beetje vreemd om nog met software uarts te spelen.

Maar zo te zien worden die uarts niet ondersteund door de Arduino libraries.

Maar hier is iemand die toch meer uarts gebruikt:
https://forum.arduino.cc/t/third-serial-port-on-uno-r4-serial2/1177436

Stukje voorbeeld van die site:

#include <UNOR4_digitalWriteFast.h>
// define
#define BAUDRATE 9600

#define UART2_TX_PIN (18u)  // Pin A4
#define UART2_RX_PIN (19u)  // Pin A5
#define DEBUG_PIN 2

// Instantiate the Serial2 class
UART _UART2_(UART2_TX_PIN, UART2_RX_PIN);  // Makes Serial2 available on pin A4 Tx, A5 Tx


// Setup
void setup(void) {
  Serial.begin(BAUDRATE);
  while (!Serial && millis() < 8000) {}
  Serial.println("Serial test");

  pinMode(DEBUG_PIN, OUTPUT);
  digitalWriteFast(DEBUG_PIN, LOW);

  Serial2.begin(BAUDRATE);
}


const uint8_t num_buf[] = "0123456789";

// Main Loop
uint32_t loop_count = 0;
void loop(void) {
  digitalToggleFast(DEBUG_PIN);
  Serial2.print(++loop_count);
  digitalToggleFast(DEBUG_PIN);
  Serial2.print("ABCDEFGHIJKLMNOPQRSTUVWXYZ");
  digitalToggleFast(DEBUG_PIN);
  Serial2.write(num_buf, sizeof(num_buf)-1);
  Serial2.println();
  digitalToggleFast(DEBUG_PIN);
  delay(50);
}

En inderdaad, de Arduino libraries ondersteunen toch meerdere hardware uarts. Alleen de documentatie is niet erg compleet blijkbaar.

De libraries gebruiken defines om uarts te kiezen:

#ifndef NO_USB
#define Serial  SerialUSB
#define Serial1 _UART1_
#define Serial2 _UART2_
#define Serial3 _UART3_
#define Serial4 _UART4_
#define Serial5 _UART5_
#else
#define Serial _UART1_
#define Serial1 _UART2_
#define Serial2 _UART3_
#define Serial3 _UART4_
#define Serial4 _UART5_
#endif

Op de UnoR3 gaat de hardware Serial naar pin1 en pin2. Op de R4 gaat die direct via USB naar de PC.

En kun je kiezen welke hardware serials je gebruikt en aan welke pinnen je die koppelt.

Het eerdere voorbeeld gebruikt _UART2_() om te pinnen te koppelen, en vervolgens Serial2.print() om data te versturen. Maar Serial2 en _UART2_ zijn synonymen dus je kunt beter overal consequent Serial2 gebruiken.

En dat moet ook werken voor Serial3 en Serial4 :

UART Serial2(PinTxd,PinRxd);

void setup()
{  Serial2.begin(115200);
   Serial2.println("Hello world");
}

Op woensdag 15 oktober 2025 23:05:07 schreef benleentje:
Dat is gelukkig niet waar. Alles is gewoon hetzelfde. zelfde io pinnen op dezelfde plaats. Alles hetzelfde. Daarom heet het ook een NANO en het is ook gebracht door arduino zelf juist omdat het dan hetzelfde moet zijn.

euhm, nee...
die chip is gewoon anders, met andere mogelijkheden

vooral die laatste regel dus, hardwarecompatible with MOST nano accessoires. dus niet alles zal werken.

en dus ook de 4 uart mogelijkheden. software serial is altijd al een beetje een moeilijke geweest, heb er ook al mee gespeeld en ook al ellende mee gehad. sommige apparaten willen er gewoon niet deftig mee communiceren dus ik probeer het te vermijden.
door dat bitbanging heb je zowieso al incompatibiliteit met verschillende cpu's

Na nog wat verder spitten blijkt het toch iets lastiger. Je kunt de pinnen niet vrij kiezen, en lang niet alle pinnen van de processor zijn bereikbaar op de connector.

Dat betekent dat je hardware-serial alleen kunt gebruiken op:
Serial1:
P302 D1
P301 D0

Serial2:
P101 D18/A4 of P103 D4
P100 D19/A5 of P104 D3

Serial3:
P109 D11
P108 D12

De Nano R4 blijkt ook niet te voldoen voor de AR488 (USB -> GPIB controller)
Dit terwijl de Nano V3 daar eminent geschikt voor is.

Het blijkt dat de pull-ups van de R4 te zwak zijn (te hoog-Ohmig) om de GPIB bus aan te sturen. Met extra buffer IC's tussen R4 en GPIB bus gaat het wél goed. Maar daarmee is de charme van de eenvoud verdwenen....
De Nano v3 stuurt probleemloos de GPIB bus aan. (tot 2 á 3 apparaten)

groet, Gertjan.

euhm, nee...
die chip is gewoon anders, met andere mogelijkheden

Ja meer mogelijkheden , sneller, beter. Maar op de IO naar de buiten wereld verder gewoon een Nano. OP paar kleine dingen die anders zijn. Maar bij snellere IO zijn grote pull-ups dan lastig.
Uiteraard zijn er altijd dingen die niet werken zoals Miedema nu ook zegt.

Maar daarmee is de charme van de eenvoud verdwenen....

Die is niet weg want het is aanvulling op het totaal en er is nu meer keus, en voor elke project zal je dan je keuze moeten maken.

Maar er zijn met de R4 dan weer dingen die eenvoudiger kunnen zoals een echte DAC, beter ADC zodat je externe ADC meer nodig hebt, CAN bus, hoge snelheid zodat je ook floating point goed kan doen. Meer interupt mogelijkheden.

ik vind het jammer dat ze die dan verkopen als 'nano' want ze zijn dus niet 100% uitwisselbaar.
ik zal ze hierdoor dan ook niet kopen.

voor de simpele taken gebruik ik de arduino nano
voor de sterkere dingen met hogere snelheid, meer geheugen of wifi gebruik ik een ESP8266. andere vorm, aansluitingen, ... zodat ik ze niet per ongeluk wissel. als ik een prototype print maak, en de vorm van een nano zit erop, dan weet ik dat het met een nano werkt.
zit de footprint van de wemos erop, dan is het met een ESP gemaakt.

programmeer ze met dezelfde software (arduino ide), maar sommige dingen zijn gewoon anders of werken niet. voor het sturen dan IR codes had ik destijds ook problemen omdat het net even anders werkt (https://www.circuitsonline.net/forum/view/168582)

[Bericht gewijzigd door fcapri op donderdag 16 oktober 2025 21:05:53 (19%)]

Het is goed dat je het zegt, ik had dit ook niet geweten. Ik denk dat er nooit helemaal aan ontkomt dat versies gaan verschillen, zeker als je dingen gaat doen als bitbangen of hem als vervanging in een oud ontwerp gaat zetten. Het lijkt me nagenoeg onmogelijk om elke nieuwe versie een superset te maken van de vorige zonder zelf de chip te (her)ontwerpen. En laten we wel wezen: het heet de "nano R4", dus je koopt hem niet volledig onwetend dat ze niet een exacte kopie zijn. Ik zou niet weten waar ik zou moeten beginnen om een processor te maken die volledig 'forward compatible' blijft zonder compromissen te sluiten in de vooruitgang.

Toch wat ik lees dat er anders is, is meer.
De R4 heeft zowel 3,3V io als 5V io. Waaronder 1 van uart die 3,3V is.
Incompatibiliteit komt ook vaak voor omdat er toch ergens specifieke code voor de AVR geschreven is.
De pull-ups zijn hoger in waarde, weak pull-ups.

Interrup pinnen niet naar gekeken dat zou anders kunnen zijn.

Maar het lijkt toch in de markt gezet te zijn om bijna 100% compatibel te zijn. Dat geld dan voor de hardware zelf.

Biblotheken zijn een heel andere verhaal, daar zitten toch veel specifieke AVR instructies in omdat je ander met de snelheid in de knoei komt.

Bij de softserial gaat het fout omdat er een register te vroeg de uitgang laag maakt waardoor de stop bit in lengte net iets te kort is. Voor de meeste Uarts zou dat geen probleem moeten zijn omdat die wat meer tolerantie in de lengte van de stopbit heeft maar hier heeft de ontvanger er wel moeite mee en herkent de stopbit niet.
Dat heeft dus niets met de hardware van de R4 te maken maar met een verkeerd werkende softserial op de R4.

M.i. moet je juist blij zijn dat Softserial vervangen is door meerdere seriele poorten. Je zou zelfs een constante kunnen zetten voor welke processor het gecompileerd moet worden.