I'm new to the forum but have been exploring Arduino for a bit now. I understand that the Arduino Nano and Nano Every are quite different in terms of hardware specs, even though they look almost identical. The Nano Every uses the ATmega4809, which has more SRAM (6KB vs. 2KB in the Nano) and flash memory (48KB vs. 32KB), making it more powerful for handling complex tasks. Plus, it’s more efficient in terms of power consumption and has a lighter build and cheaper than Nano.
That said, my main question is about library compatibility. Can I use the same libraries for both the Nano and Nano Every when working with common components like:
DHT11/DHT22 temperature sensors
OLED and LCD displays
Gas sensors (MQ series)
L293D motor driver
Ultrasonic sensor (HC-SR04)
IR sensors
PIR motion sensors
Flame detection sensor
Water detection sensor
Rain sensor
Soil moisture sensor
And a lot more!
I understand that the Nano Every’s ATmega4809 has different registers and some changes in the pin mapping. Could this affect compatibility with libraries like those for I2C or SPI devices? Has anyone encountered any issues or had to tweak libraries to work with Nano Every?
I appreciate any insights or advice on using the same libraries for these components on the Nano Every versus the regular Nano.
You're right and both of the boards have different specs although purposely the same footprint.
The question is that each library also has its own specs, according to the developer of the library. Some of them have better documentation, other ones were designed for a specific hardware and conditions. So, we can't assure every library that works on the Nano will also work on the Every, but I would venture to say that the most common libraries used will work in both of them.
I completely understand that libraries are developed with specific hardware and conditions in mind, and it makes sense that compatibility can vary depending on the implementation. While the Nano and Nano Every share the same footprint, the ATmega4809's architecture and resources definitely introduce new variables into the equation.
It’s reassuring to hear that most common libraries tend to work across both boards, but I guess for more hardware-specific libraries (especially those involving direct register manipulation or timing), there might be some edge cases where modifications are necessary. I’ll probably test libraries for I2C, SPI, and sensor handling to see if any subtle issues arise.
Thanks again for the guidance! I’ll keep this in mind as I explore the Nano Every further and will definitely report back any notable findings in terms of library compatibility.
You must be careful regarding instructions involving timers, for instance by adding compiler's directives such as this one :
#ifdef ARDUINO_ARCH_MEGAAVR
#include "EveryTimerB.h"
#define Timer1 TimerB2 // use TimerB2 as a drop in replacement for Timer1
#else
#include "TimerOne.h"
#endif
Many libraries are not compatible and would need rewritting.
I don't have a Nano Every; however I've helped people to adjust some libraries; from memory, it's all related to the difference in the type of the variable that you need to pass to a function in the library for the pinMode() (there might be some other functions that are also affected). Some libraries have catered for it and others did not.
You can install the board package for the Nano Every, take examples of the libraries that you are interested in / need and compile. You will quickly find out what compiles and what not.
You can also look at MCUdude's MegaCoreX; it might be more compatible with the existing libraries but I'm not sure of that.
To my understanding the specific #define is a concatenation of the word ARDUINO_ARCH_ and the capitalised name of the core. I've verified this against a couple of boards. For e.g. Nano Every and Uno WiFi REV2 the core is the last directory in the patch (for a Windows sustem) C:\Users\bugge\AppData\Local\Arduino15\packages\arduino\hardware\megaavr
All #defines used during compilation can be found in the file platform.txt of a specific core; search for -D. The file platform.txt can be found in the version subdirectory of the core directory above: C:\Users\bugge\AppData\Local\Arduino15\packages\arduino\hardware\megaavr\1.8.8.
Thanks for that info. I am just trying to put together a model sketch and one of the things to do is know when to wait for Serial or not. I know that is architecture-dependent so I was hoping for a convenient resource.
It's just a side project. At 82 I still have lot's of unfinished pet projects and many will never get done.
As @sterretje mentioned, there is a standard convention that Arduino boards platforms will define a global macro with name in the form ARDUINO_ARCH_<architecture> (where <architecture> is the platform's architecture ID, converted to uppercase). The architecture IDs are listed under the "Architecture" column of the spreadsheet I linked above.
So, for example, here we have the entry in the spreadsheet for the "Arduino megaAVR Boards" platform of the Nano Every:
From this, you can determine that a macro named ARDUINO_ARCH_MEGAAVR is defined when compiling for any of the boards of the "Arduino megaAVR Boards" platform.
With the risk of derailing the topic, is that about while(!Serial). If so, that should handle it "automatically" as far as I know. You can start a new topic in the Programming section if you need more information about it.
Wait for Serial:
Some boards have processors with native USB and two cores. It is possible that one core starts executing the sketch while the other core is still busy initializing the peripherials. This is not the case for the Nano (ATmega328) or NanoEvery (ATmega4809), these have a USB bridge. I never used a 'wait for Serial' and never got problems.
Libraries included again:
Library files typically contain a test to prevent it from being included twice. The ones I’ve seen in my system did.
Libraries for NanoEvery:
Many libraries have been rewritten for many processors. Usually they have the same name. Arduino IDE will pick the ones for the board you selected.
If nothing is connected,while(!Serial) will wait forever on some platforms (those with "native USB"), and continue immediately on others (though with separate usb/serial chips.) This is relevant if you have "informational" messages being sent, where you don't care whether they are actually seen.
It has nothing to do with multiple cores; it has to do with the required "enumberation" process with the connected PC.