Nano V3 ----> Nano Every, MCUFRIEND_kbv library no longer working.

Official Hardware Nano Family Nano Every
1

Hi,

I have been using this TFT LCD ( https://www.amazon.ca/gp/product/B077ZT7S38/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1 ) with an Arduino Nano v3, i recently got the new Nano Every and my project no longer compiles.

I ran the Tft paint example , and it also does not compile on the nano every. i am rather new to Arduino and the wide range of LCD's, Controllers and library's is mind boggling to me.

Attached is the txt file for the error message.

Nano every TFT error.txt (118 KB)

2

Although it has a similar name, the Nano Every is very different from the classic Nano. The Nano Every uses the new ATmega4809 microcontroller instead of the ATmega328P of the classic Nano. The ATmega328P is by far the most popular microcontroller in the Arduino world, and has been so for many years, so the community support for ATmega328P is excellent. The ATmega4809 is very new and not widely used so the community support for that chip is not so great. Due to Arduino's standardized API, you'll find that some sketches and libraries written before the ATmega4809 even existed work fine. However, low level code will only work if it was written specifically for the ATmega4809, and not many library authors are doing that yet.

There are several problems you'll encounter when attempting to compile the TFTLCD library's tftpaint example sketch for Nano Every:

Adafruit GFX library uses a typedef named PORT_t, which conflicts with a struct of that name defined in avr-gcc. The solution is to do a search and replace of the C:\Users\280gb ssd\Documents\Arduino\libraries\Adafruit_GFX_Library folder for PORT_t and replace it with something unique (which Adafruit should have done from the start) like AdafruitGFXPORT_t.

There are also some differences in register names, which are reported to be fixed by adding this to Adafruit_SPITFT.h:

#if defined(__AVR_ATmega4809__)
#define SPDR SPI0_DATA
#define SPSR SPI0_INTFLAGS
#define SPIF SPI_IF_bp
#endif

Next, there is a problem with the Adafruit Touchscreen library about RwReg not declared. I fixed this by changing touchscreen.h line 11 from:

#if defined(__AVR_ATmega328P__) || defined(__AVR_ATmega32U4__) || defined(TEENSYDUINO) || defined(__AVR_ATmega2560__)

to:

#if defined(__AVR_ATmega328P__) || defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega4809__) || defined(TEENSYDUINO) || defined(__AVR_ATmega2560__)

Next, I ran into a problem with the Adafruit TFTLCD library:

E:\arduino\libraries\TFTLCD-Library-master\pin_magic.h:350:3: error: #error "Board type unsupported / not recognized"

If you look at the contents of the file, you can see how the definitions are created for each microcontroller. You would need to spend some time with the datasheet for the ATmega4809 and figure out what needs to be added to that file to make the library support the Nano Every.

Adafruit has expressed interest in supporting these boards, so if you manage to figure it out, please be sure to submit pull requests to the relevant repositories so that others may benefit from your efforts:

There will always be more of a challenge to working with the new boards. I see these boards as being best suited for adventurous people looking for a challenge and opportunities to make significant contributions to the Arduino project (adding support for these boards to the libraries, for example). For people just wanting things to work with the minimum amount of frustration, the boards with a long history of use by the Arduino community are a better choice.

3

pert:
Next, I ran into a problem with the Adafruit TFTLCD library:

E:\arduino\libraries\TFTLCD-Library-master\pin_magic.h:350:3: error: #error "Board type unsupported / not recognized"

If you look at the contents of the file, you can see how the definitions are created for each microcontroller. You would need to spend some time with the datasheet for the ATmega4809 and figure out what needs to be added to that file to make the library support the Nano Every.

Adafruit has expressed interest in supporting these boards, so if you manage to figure it out, please be sure to submit pull requests to the relevant repositories so that others may benefit from your efforts:
Support for Arduino Uno Wifi Rev 2. · Issue #190 · adafruit/Adafruit-GFX-Library · GitHub

There will always be more of a challenge to working with the new boards. I see these boards as being best suited for adventurous people looking for a challenge and opportunities to make significant contributions to the Arduino project (adding support for these boards to the libraries, for example). For people just wanting things to work with the minimum amount of frustration, the boards with a long history of use by the Arduino community are a better choice.

I haven't messed with this kind of electrical/software level before, but I'm always willing to learn new things. how difficult would you estimate it would be to get the nano every to work with the TFT lcd?

ill try to show what level my understanding is at in terms of this subject.

Just by glancing at pin_maigc.h , this is what I was able to pull.

// Pixel read operations require a minimum 400 nS delay from RD_ACTIVE
// to polling the input pins.  At 16 MHz, one machine cycle is 62.5 nS.
// This code burns 7 cycles (437.5 nS) doing nothing; the RJMPs are
// equivalent to two NOPs each, final NOP burns the 7th cycle, and the
// last line is a radioactive mutant emoticon.

So somehow this code burns 7 cycles on the 328p

#define DELAY7        \
  asm volatile(       \
    "rjmp .+0" "\n\t" \
    "rjmp .+0" "\n\t" \
    "rjmp .+0" "\n\t" \
    "nop"      "\n"   \
    ::);

For the 4809 @ 20mhz, It would need to burn 9 cycles because 8 cycles is exactly 400ns, and that is the minimum.

I have no idea how to even start to modify this code to burn 9 cycles. Does that mean that is out of my league (unless I pour the equivalent of a full time job on this)?

4

1dot8TWM:
For the 4809 @ 20mhz

I notice the board definition of the Nano Every sets f_cpu to 16000000L:

nona4809.build.f_cpu=16000000L

And the fuses are also configured for the 16 MHz internal oscillator, just like on the Uno WiFi Rev2:

nona4809.bootloader.OSCCFG=0x01

Yet the product page of the Nano Every claims it's running at 20 MHz.
This makes me wonder if that was only a copy paste error in boards.txt when the Nano Every's board definition was copied from the Uno WiFi Rev2 board definition, or if the clock is really at 16 MHz and the product page is wrong? If the former, then the timing on the Nano Every is going to be off for any code that uses the F_CPU macro.

1dot8TWM:
I have no idea how to even start to modify this code to burn 9 cycles.

I'm no expert in this stuff, but it seems explained well enough in the comment:

the RJMPs are
// equivalent to two NOPs each, final NOP burns the 7th cycle,

So to add two more cycles, you just need to add an additional RJMP:

#if F_CPU <= 1600000L
#define DELAY7        \
  asm volatile(       \
    "rjmp .+0" "\n\t" \
    "rjmp .+0" "\n\t" \
    "rjmp .+0" "\n\t" \
    "nop"      "\n"   \
    ::);
#elif F_CPU <= 2000000L
#define DELAY7        \
  asm volatile(       \
    "rjmp .+0" "\n\t" \
    "rjmp .+0" "\n\t" \
    "rjmp .+0" "\n\t" \
    "rjmp .+0" "\n\t" \
    "nop"      "\n"   \
    ::);
#endif

Of course, that code relies on F_CPU being correctly defined, which it is not if the Nano Every is truly running at 20 MHz.

1dot8TWM:
Does that mean that is out of my league

My guess is that it will only take some determination and quality time reading the datasheet (be sure to download the "megaAVR 0-series Family Data Sheet" in addition to the "ATmega809/1609/3209/4809 - 48-pin Data Sheet" from:

You might need to do a bit of trial and error before you get everything completely right but I'm sure you'll get there eventually. There are some people on this forum much more knowledgeable about this stuff than I who will probably help you out if you get stuck.

5

I just got confirmation that the Nano Every will be running at 16 MHz by default. It's quite capable of running at 20 MHz, but to do this you'd need to modify the Arduino megaAVR Boards core (change line 56 of boards.txt). So this means you likely don't need to worry about that section of pin_magic.h.

6

You have a regular Blue 3.5 inch Mcufriend Shield.

It should work fine with all the conventional Arduino boards that have standard Arduino header sockets.

If and when there is a mega4809 board with standard headers, I will add them to the library (i.e. they will work automatically)

Meanwhile, you could use the existing SPECIAL that I use for my XPRO + XPRO-Shield-Adapter.

USE_BLD_BST_MEGA4809

My IDE v1.8.9 does not support the EVERY.
It seems very unwise (tm) to call a new board "Nano". A distinct name would be less confusing.

And if anyone creates an "official" adapter board with Shield sockets that receives the EVERY I will support the "shield wiring".

David.

Edit. I have found MKR1000 Adapter

The EVERY seems to have 30 pins and the MKR1000 has 28 pins. So it is not even worth investigating the pinouts.

7

david_prentice:
If and when there is a mega4809 board with standard headers, I will add them to the library (i.e. they will work automatically)

The Arduino Uno WiFi Rev2 uses the ATmega4809 and has the standard Uno headers:

david_prentice:
My IDE v1.8.9 does not support the EVERY.

You need to use Boards Manager to install Arduino megaAVR Boards 1.8.1.

david_prentice:
And if anyone creates an "official" adapter board with Shield sockets that receives the EVERY I will support the "shield wiring".

There are these things for $2.20 on eBay:

800×800 118 KB

I've never used one, but it looks like you could just solder some female headers on there and have a Nano to Uno adapter. The big problem is it doesn't have an ICSP header, so it won't support any shield that uses that.

8

The MKR2UNO Adapter has deep headers for the shield.
And the MKR board is low profile.

So I would assume that the Shield pcb will not touch the MKR board.

Your Red adapter looks as if it is designed for a cheapo Nano.
The Nano ISP header will definitely interfere with a Shield.
You would need to buy extra deep header sockets. (or stackable female header strip)

The EVERY is low profile. So it might work with the Red Adapter.
The EVERY appears to have the same pinout as the cheapo Nano.

It looks as if this Blue Nano Adapter is available from a UK seller.

Perhaps I will order an EVERY and try it with the Adapter.

David.

9

david_prentice:
And the MKR board is low profile.

So I would assume that the Shield pcb will not touch the MKR board.

The MKR board itself is low profile enough, but the MKR boards usually come with female headers on top which are certainly not low profile. This is on reason why the MKR2UNO product page says:

Please note that currently the MKR2UNO adapter is compatible only with MKR1000 without headers

This is because you can solder male header pins on the bottom of the MKR1000 without headers to avoid having the female headers on top that would stop the shield from being able to plug into the MKR2UNO.

Aside from the issue of the female headers on top, some of the MKR boards are a little longer than the MKR1000 and hit the ICSP header on the MKR2UNO (MKR Fox 1200, MKR WAN 1300, MKR GXM 1400, MKR NB 1500). The board goes far enough into the headers to get a good electrical connection and still allow most shields to be attached, but this will prevent the use of any shield that has an ICSP header. The MKR Zero and MKR 1010 WiFi can fit without hitting the ICSP header.

The MKR WAN 1300 also has a screw terminal that's the same height as the female headers. But anyone who can remove the headers to replace them will be able to easily remove the terminal at the same time.

david_prentice:
Perhaps I will order an EVERY and try it with the Adapter.

Cool! I'm looking forward to getting a Nano Every. It seems like a great board for playing around with the ATmega4809.

If you think of it, please let us know how things go with the adapter. There was another discussion about using those things for this purpose a while back, but I never heard how it worked out. I was surprised to not find something specifically designed for the purpose. Maybe it's because of the header height issue. As a DIY solution, stacking the headers is fine, but for a commercial product, maybe a bit too much of a hack.

10

I ordered the Blue Adapter and two EVERY boards last night.

I will solder one EVERY to a ProtoShield pcb. Mount female headers on the Protoshield. Hand wire from EVERY to Arduino headers. Shields will fit nicely.

I will solder male header strip to the other EVERY.
I will solder Stackable Headers to the Blue/Red Adapter.
This EVERY module can be plugged into the Adapter.

The second option is quickest. I already have Stackable Headers. It will look odd because the headers will have stalks showing.

The first option is neatest. It will be the same dimensions as a regular Uno.

Hey-ho. The only annoying thing is that the EVERY seems to be 5V instead of 3.3V.

David.

11

Yes, the Nano Every is 5 V. The idea is to make it like the original Nano, but with the ATmega4809 instead of ATmega328P.

If you like 3.3 V, you might be interested in the Nano 33 IoT:

This board uses the ATSAMD21G18A like the Zero and MKR boards and has the ESP32 module like the MKR WiFi 1010 and Uno WiFi Rev2.

There's also the Nano 33 BLE:

That's a nRF52 board and still only available for pre-orders.

12

I like 3.3V because all most external electronics is 3.3V
Very few external chips are 5V tolerant.

It is painful to add level shifters for Microchip when other manufacturers run faster and better at 3.3V.

David.

13

My two EVERYs arrived from Holland today.
The Ebay Nano Adapter arrived from England today.

Serial and Wire seem to work ok.
The Adapter works 100% with a regular Nano.

D10 does not seem to blink on the EVERY.
A4, A5 do not seem to blink on the EVERY.

I had written the EVERY driver code for MCUFRIEND_kbv. before the packet(s) arrived.
I need to investigate what the "blink" problems are.

Has anyone else received their EVERY boards yet?

David.

14

There is a known bug with the 1.8.1 release of Arduino megaAVR Boards that causes digitalWrite() on the analog pins to not work:

That bug has already been fixed, but they haven't done a new release yet.

15

david_prentice:
D10 does not seem to blink on the EVERY.

According to the variant file:

Arduino pin 10 is PB1. I looked at the code in that file and it seems correct for PB1. So my question is whether Arduino pin 10 on your Nano Every is actually connected to PB1 on the ATmega4809. I don't have an Every so I can't check this, but it should be easy to do with a multimeter set to continuity check mode. PB1 is physical pin 5 on the ATmega4809.

16

Thanks for the GitHub link. I have replaced the pins_arduino.h file. MCUFRIEND_kbv is working. SD is working with CS on D10. So the pins issue is resolved.

A new Core will be released next week. So things are looking good.

One EVERY is plugged into the Nano Adapter. I have soldered Stackable Headers about 8mm above the pcb. This lets you plug regular Shields into the Adapter. Actually the sandwich is pretty robust.

Tomorrow I will solder the other EVERY into a ProtoShield pcb. This will produce a less-deep sandwich.

The current Adafruit_SPITFT library b*ggers up compiles for a 4809. I only use Adafruit_GFX but Adafruit_SPITFT is bundled in the same directory.

I will investigate tomorrow.

David.

17

MCUFRIEND_kbv is working.

Thanks!

So the pins issue is resolved.

I'm glad to hear it.

One EVERY is plugged into the Nano Adapter. I have soldered Stackable Headers about 8mm above the pcb. This lets you plug regular Shields into the Adapter. Actually the sandwich is pretty robust.

Good to know. I'll be sure to keep that in mind for if anyone asks about an easy way to connect shields to a Nano. That's a cheap and reasonably easy solution.

The current Adafruit_SPITFT library b*ggers up compiles for a 4809. I only use Adafruit_GFX but Adafruit_SPITFT is bundled in the same directory.

I will investigate tomorrow.

Thanks! It would be great to see the community work to provide better support for the ATmega4809 boards. It seems like a pretty interesting chip that is likely to become more widely used now that the Nano Every is out.