Problem with arduino NANO EVERY and libraries

[david_prentice]

The NANO-EVERY is just a board with the same pinout as the popular NANO

The NANO-EVERY uses an ATmega4809 instead of the NANO's ATmega328P

You get 48kB vs 32kB Flash
You get 6kB vs 2kB SRAM
You get 256B vs 1024B EEPROM

The Arduino pinout may be identical but it maps to different MCU Port pins on the mega4809.
The regular Arduino functions and classes e.g. digitalWrite(), SPI.begin(), ... work the same.

If a library dives into the mega328P hardware it will not be the same on a mega4809.
Hence you need to report any problems.

The mega4809 peripherals are "better" than mega328P but don't expect them to work any faster.
The extra Flash and SRAM is handy.  The smaller EEPROM might be awkward.

It is generally easier to put everything on one big MCU than to use many small MCUs.
i.e. single-chip design if possible.

David.

[erikjanssen]

I found a little help in the tool.

If I select Genuine UNO and go to files, examples and scroll down I can find the examples for keypad, LiquidCrystal I2C, RF24 and RF24Network.

When I select NANO EVERY and go to files, examples and scroll down I find a folder INCOMPATIBLE with, guess what, LiquidCrystal I2C, RF24 and RF24Network. So no wonder my application will not run on an Every.

They missed Keypad, the Hello Keypad does not verify.

This is a start and will help to determine whether I can use a library for a specific board. Still you can only see this after you installed a library.

I would love to see a filter on board in the software library manager.

[david_prentice]

Have you upgraded the libraries?
Have you raised an Issue with the relevant library authors?

I suggest that you use hd44780 library instead of the randomly named LiquidCrystal I2C

David.

[erikjanssen]

Yes, I keep my development environment upgraded.

Keypad can be replaced with Adafruit Keypad
LiquidCrystal_I2C can be replaced with hd44780

RF24 and RF24Network are classified as INCOMPATIBLE by Arduino, I assumed raising an issue would be useless.

So on my project, 4 libraries need work to get things going again. For me that is not worth the trouble. In order to move forward I decided to go for the Arduino NANO IoT and start from skratch to rebuild my application together with the possibility to publish the results on the web.

[david_prentice]

Anything that can be done on Uno or Nano should be possible on NANO-EVERY board.

The authors just need to be told.   After all,   the RF24 libraries were written before the ATmega4809 was invented.
The GitHub site seems to have some activity.   So it is simply a question of raising an Issue or offering a Pull Request.

The author might want you to do some testing.    That is how the world benefits from OPen Source.

David.

[david_prentice]

I built the pingpair_ack example for Uno and Teensy3.2 without problem.
It failed for NANO-EVERY because two digitalWrite() statements were not correct.

RF24.cpp

Code: [Select]


...
#if !defined (RF24_LINUX)
digitalWrite(csn_pin,mode ? HIGH : LOW);  //.kbv
delayMicroseconds(csDelay);
#endif

}

/****************************************************************************/

void RF24::ce(bool level)
{
  //Allow for 3-pin use on ATTiny
  if (ce_pin != csn_pin) digitalWrite(ce_pin,level ? HIGH : LOW);   //.kbv
}
...


Compilers are fussy.   digitalWrite() expects an enum and not a bool for the second argument.
TRUE and HIGH happen to have the same value but are obviously completely different type.

I have not tested on real hardware.   A correct build does not mean the library is going to work.

David.

[david_2018]

I built the pingpair_ack example for Uno and Teensy3.2 without problem.
It failed for NANO-EVERY because two digitalWrite() statements were not correct.

RF24.cpp

Code: [Select]


...
#if !defined (RF24_LINUX)
 digitalWrite(csn_pin,mode ? HIGH : LOW);  //.kbv
 delayMicroseconds(csDelay);
#endif

}

/****************************************************************************/

void RF24::ce(bool level)
{
  //Allow for 3-pin use on ATTiny
  if (ce_pin != csn_pin) digitalWrite(ce_pin,level ? HIGH : LOW);   //.kbv
}
...


Compilers are fussy.   digitalWrite() expects an enum and not a bool for the second argument.
TRUE and HIGH happen to have the same value but are obviously completely different type.

I have not tested on real hardware.   A correct build does not mean the library is going to work.

David.

I tried your code with the scanner example and it compiles and runs, but gives no output on the serial monitor.  The printf.h file included with the library needs to be modified to allow for the megaavr architecture.

Code: [Select]


#if defined (ARDUINO_ARCH_AVR) || defined (ARDUINO_ARCH_MEGAAVR) || defined(__ARDUINO_X86__) //added ARDUINO_ARCH_MEGAAVR

int serial_putc( char c, FILE * )

/***********************************************************************************************/

void printf_begin(void)
{
  #if defined (ARDUINO_ARCH_AVR) || defined (ARDUINO_ARCH_MEGAAVR) //added ARDUINO_ARCH_MEGAAVR
    fdevopen( &serial_putc, 0 );


It is also necessary to wait long enough in setup() for the Serial interface to initialize before using it. The usual while (!Serial) doesn't seem to work properly for the Nano Every, so I use a delay().

(edit)
Made slight modification to code for readability, does not affection function.

[david_prentice]

There you are.   10 minutes to identify the digitalWrite() syntax problem.
10 minutes to identify any  conditional blocks that need extending for MEGAAVR

You have the hardware.    You can do real life testing of the library on your hardware.

And then make an Issue or Pull Request.
The library author can make a new Release.   The Library Manager will prompt for update.

We can help you with the procedure.
If you want help with targets,  I can probably dig out two NRF24L01 and a variety of targets e.g. Uno, Zero, Due, ESP32, ...
You will have to suggest suitable examples.

David.

[david_2018]

I found a little help in the tool.

If I select Genuine UNO and go to files, examples and scroll down I can find the examples for keypad, LiquidCrystal I2C, RF24 and RF24Network.

When I select NANO EVERY and go to files, examples and scroll down I find a folder INCOMPATIBLE with, guess what, LiquidCrystal I2C, RF24 and RF24Network. So no wonder my application will not run on an Every.

They missed Keypad, the Hello Keypad does not verify.

This is a start and will help to determine whether I can use a library for a specific board. Still you can only see this after you installed a library.

I would love to see a filter on board in the software library manager.

The INCOMPATIBLE listing is generated from the library.properties file in each library, and is not really a reliable way to tell if a library is compatible or not, since the megaavr architecture used by the Nano Every and WiFi Rev 2 board did not exist on any Arduino board before the beginning of the year.

As for the Keypad library, the errors are related to the change from using defines to an enum for the arguments of the digitalWrite() and pinMode() functions, which wreaks havoc with a lot of code.  I don't have a keypad to test with, but the following modifications to the Keypad.h file at least allow the library to compile without error:

Code: [Select]


.......
// bperrybap - Thanks for a well reasoned argument and the following macro(s).
// See http://arduino.cc/forum/index.php/topic,142041.msg1069480.html#msg1069480
#if not defined (INPUT_PULLUP) && not defined (ARDUINO_ARCH_MEGAAVR) // add test for megaavr architecture
#warning "Using  pinMode() INPUT_PULLUP AVR emulation"
.........


Code: [Select]


class Keypad : public Key {
public:

 Keypad(char *userKeymap, byte *row, byte *col, byte numRows, byte numCols);

#if defined(ARDUINO_ARCH_MEGAAVR) //change type of arguments to pinMode and digitialWrite functions
 virtual void pin_mode(byte pinNum, PinMode mode) { pinMode(pinNum, mode); }
 virtual void pin_write(byte pinNum, PinStatus level) { digitalWrite(pinNum, level); }
#else
 virtual void pin_mode(byte pinNum, byte mode) { pinMode(pinNum, mode); } //original line from code
 virtual void pin_write(byte pinNum, boolean level) { digitalWrite(pinNum, level); } //original line from code
#endif
 virtual int  pin_read(byte pinNum) { return digitalRead(pinNum); }


[pert]

Just to elaborate on what david_2018 said, the Arduino IDE determines whether a library is compatible or not with a given architecture based on the comma-separator "architectures" field in the library.properties file found in the library's root folder. If the library has no library.properties file, then the IDE assumes it's compatible with all architectures. The IDE will also display an incompatible library warning in the console when you compile a library that doesn't have a match for the currently selected board's architecture in its architectures field.

This is not always reliable because:

• Some library authors define this field as a wildcard (compatibility with all architectures), even though their libraries turn out to not be compatible with all architectures.
• Some library authors define this field as avr even though their library is compatible with all architecture. This is sometimes done because they don't understand what the field is for and they are just doing a copy/paste. I've also seen it done when the library author knows there is wider compatibility but doesn't have any interest in providing support to the users of other architectures.
• Incorrect formatting of the architectures field (often incorrect case).

[erikjanssen]

Thank you for your comments. With all the new boards available now it is indeed a good idea to validate a library before starting developments.

I have chosen not to proceed with the EVERY for my next upgrade but move directly to the NANO 33 IoT.