One worry I have about the widely touted compatibility between the R3 and R4 Uno, is the current from a pin value. On the R3 a safe operating current is 20mA with many circuits on line assuming you can drag 40mA from it, as well as the many people who still think this is a limiting factor. That is the Arduino will limit the current to this value.
So now faced with a limit of 8mA I think a few words of caution are in order, which, so far we have not seen.
On a rather less important note, I find it very annoying, as a Physicist, to find the word "Quantum Leap" applied in marketing as if it was a huge change. Where as in fact a Quantum Leap is the smallest leap it is possible to make. This sort of nonsense was quashed in the UK in the late 1990s, by repeated ridicule of the politicians who mainly misused the term. I am saddened to see this reappear in your marketing department.
Every new Arduino board claims compatibility with the UNO but we all know the reality is different! Of course at the base level they aren't compatible, that's a given, and we are to rely on the software library to give a degree of compatibility. But that doesn't always work. You point out about the current on the pins, but there is also the missing EEPROM. Of course anything for which timing is critical will probably not work without tweaking. And compatibility frequently means that improved features in the newer microcontrollers are ignored -- it's really sad to make these recent microcontrollers look like the ancient AVRs. I'd say that certainly makes it a Quantum Leap forward.
But if you are careful the R4 Minima is a roughly 25% less expensive equivalent to the old faithful R3. Pretty much a no-brainer choice if you want to stay with official Arduino boards.
I am pretty sure that this can be emulated in software. It can be on other processors. But it will probably be a lot faster than the old EEPROM.
Not so sure about that because you are running a faster processor, so anything time critical will become less time critical. So any tinkering will just involve adding delays.
See this page for progress on testing compatibility.
Note how the Neopixel library compiles but will not work, I am sure that is just a delay away from being fixed.
Somewhat surprising, there does seem to be EEPROM emulation for the Renesas based boards. I say surprising since there isn't any emulation on the SAMD based boards. Might be due to different write protection mechanisms or flash memory implementation on the respective microcontrollers.
Yes, tweaking would involve adding delays. They are generally careful to have devices like the ADC run much slower than they can so that they are compatible!
I just looked at the schematic (first time!) and found another gotcha with this. In the R3 pin D13 drives the LED through a buffer so as not to load the pin. Not so for the R4, so that's even less drive on that pin. (The Arduino Nano also is missing the buffer, but it's a smaller board so has an excuse.) At any rate, my boards should arrive on Monday.
Aha, I just discovered that the Renesas microcontroller does have 8kB of data flash memory ("EEPROM") which explains why it gets the EEPROM library support not available for the SAMD microcontrollers. Downside is that while it can be programmed a single byte at a time, erasing is in 1KB pages. The virtualEEPROM.cpp defines a class that buffers a page in RAM but I haven't studied it enough to find out what will actually trigger an erase and write of the page. It would be bad news if it did an erase/write for each byte written as that would potentially wear out the EEPROM 1,024 times faster. But I expect that is going to be the case, which would not be acceptable for most real world applications.
Talking about "compatibility concern", the EEPROM in the ATmega328P can erase/write single bytes, and each byte can be written 100,000 times. If the Arduino provided EEPROM library does an erase/write on every byte written then writing to every byte in a 1K page of the Renesas data flash can only be done 100 times.
This can be mitigated by only writing to the flash when it is necessary, but it appears that the way the library functions were written (maintaining compatibility with the UNO R3) you can't control when the writing occurs. For instance, I would always wait a minute or so after a user configuration was changed before writing the configuration back to flash in case that some other setting might be changed. Writing back to flash after each single byte was changed would have been insane (and certainly caught in any design review!).
It is nice to have at least some hardware compatibility, but what about software?
In the R4 FAQ, I read:
"some UNO R3 libraries use instructions of the AVR architecture that are not compatible with the architecture of the UNO R4 Minima."
When I google for ARDUINO ISR, I am getting some 1.550.000 hits.
None of them will work using the UNO R4.
Will there be a tutorial on how to convert existing code using interrupts like ISR(TIMER2_OVF_vect)?
Yes that applies to any change in processor chip, not just the R4. For example the processors used in the Leonardo and Micro have different interrupt / times structures as do the Mega, Due, Nano Every and virtually any other processor built into an Arduino.
I don't know if some one will write one but eventually all the major libraries will be updated to use the R4 processor.
If you write to a byte, and do not proceed it with an erase, then what you are writing is NORed with the existing contents. This means you can set individual bits LOW but you can't set individual bits HIGH.
You could use this trick on non erasable or UV erasable ROM.
I laugh. None of the instructions of the AVR architecture are compatible with the Renesas (ARM Cortex M4) architecture. There is far more compatibility with the SAMD microcontrollers (ARM Cortex M0+) of the MKR series and a couple other Arduino board designs. But even then the on-chip peripherals are completely different as is the implementation style of the Arduino software library. While the Arduino libraries for AVR and SAMD go "straight to the metal" for the Renesas they seem to always go through another Renesas library that abstracts the actual hardware. Kudos to the folks that port the libraries -- it's not straightforward at all.
