Hello,
Would you choose Arduino Nano Every over Arduino Nano? And why?
For what application?
In general, not for a specific project.
Probably not. It's marginally better (RAM, Flash, clock speed) in everything but EEPROM, but if those are a problem you can get much more power for your money using an ESP32 or a Teensy.
If it is only in general, then the obvious feature differences stand out, memory, processor power, etc. But that is only without regard to cost.
Hence, the application really does matter.
So it's a tie for now, one for Nano, and one for Nano Every. Any other opinions?
I'm looking for the highest quality of two, regardless the price for simple projects that doesen't need much processing power but realiability is important (like a relay, an LCD, a button, an LED, a sensor things like this).
In that respect there is no difference but cost.
Only for applications that need bigger processor and bigger memories than the ordinary Nano.
The second hardware serial port Serial1 on the nano every can be useful,
1 Like
The Nano Every is generally better specified than the original Nano (ATMEGA328P v. ATMEGA4809) but not all code samples for the original Nano, Uno etc. work because it has a newer architecture. If you are breaking away from the ATMEGA328P based systems, there are also other interesting alternatives such as ESP.
1 Like
If HW specs doesn't make a difference for the duty, then the price would do.
On Arduino page (Europe) the price difference is 11,50€ before tax.
Cheers!
I have no comment on the boards, I am not very familiar with the boards, but I choose the parts that I use based on how demanding the application I have in mind is.
I use modern ATtiny parts (3224/3226/3227 and smaller flash versions for low pincount - the 2-series has dual USART, proper I2C and SPI, 6 PWM pins and up to 32k of fullt memory mapped flash. 4 CCL LUTs anda 6-channel event system, plus a killer ADC with 12 bits of resolution, 1-16x programmble gain amplifier support for differential measurements.
When they actually start shipping, for the most demanding low pincount applications, that're will be an AVR32DD14 and 20 (with 14 and 20 total pins respectively, that translates to 9 and 15 fully usable I/O pins, less 2 if you want an external crystal), flash is also memory mapped, and they've got a type D timer. and they have MVIO on 3 pins for interfacing with stuff that runs at different voltages. There will also be a 64k version (which means only half is memory mapped, and you need to declare constant variables you want to not be copied to ram as const PROGMEM_MAPPED if you want to access them like normal variables like you can
I have some designs sketched out that I don't think I'd be able to get the performance I'd like see w/out the 8k SRAM of the 64k version. I'll test whether the concept is viable with a 64DD32 (which are shipping!), since if it works as well as I think it will, it will make all UPDI uploads to a tiny, without regard the serial adapter, go like 2x faster since USB latency - which is > 50% of the time on upload at 460800 - would appear only randomly when they did appear, it wouldn't slow down the write, the timing thing around page writes would be trivial to solve, response signatures could be interpreted by the firmware, and the python script to drive a semi-intelligent UPDI programmer would be mad simple. Not only that, it would be just one step away from a standalone lightning fast UPDI programmer, and there'd be enough space in the flash that could could switch it into a mode where it wrote to it's own flash instead of a target, and kept an index of all the sketches it has and try to score some of the DD20 QFN version to make the whole package smaller (it would go from 6/PMP to 10/PMP, reducing pcb cost by 40% and the QFNs are like 20% cheaper than SOIC.) In any event, the key features that dictate that decision to me are if I need either a crystal, MVIO or loads of flash or ram. That design needs the latter two and wants the first. It's definitely not going to be a tiny.
If I need more storage, (16k of ram would allow for a massive buffer to hold data to be written, often the wholes sketch, which would probably allow writes literally as fast as the hardware can accept it, and 128k, even if the code took half of that (my guess is it would be under 10k) that would give me 64kb to fill with at least two tinyAVR sketches and more if the code is as small as I think it will be. So maybe I will just make it with a 32-pin DB in QFN. The DB and DA series also go up to 64 pins (54 usable), and the DB has on-chip opamps, and you get 6 more PWM pins when you step above 48 pins. So if I needed lots of pins, or lots of timers, or 6 USARTs, or extra CCL LUTs and event channels, that would tell me I should go with the DA/DB-series. Those also have 12-bit ADC, but no programmable gain, and both voltages in differential mode have to be below VREF which rules out almost everything I can imagine usine a differential ADC for - the killer ADC is only on the 2-series tiny and upcoming EA-series.
I recently thought I didn't have any DA's with me, and assembled 2 boards with 4808's, because they're entirely sufficient to my needs, but then I realized MegaCoreX doesn't have onewires serial support exposed, so I'd have to port the basics over or get him to add it. (DxCore does have one-wire serial mode fully exposed). I think I'll throw together a few now that I found my DA32's.(this is for an entirely different project; I can see myself needing to make over a dozen just for my own use: They're test fixtures that let me detect shorts and open. Will be connected to spring-loaded test probes tor fast testing of boards I assemble.
The only time I use classic AVRs is when testing products I sell that use them, or as nanos, because they're dirt cheap, and then I just load code onto them via ISP (screw the bootloader), usually code that other people wrote (I have a few each dedicated programmers - nanos permanently set up with JTag2UPDI or ArduinoISP (with slight modification - add the clock output to revive softbricked chips, and use a modified ISP header on the end to bring the reset signal over, install one of those rows of 6 leds to give status indications, etc).
But yeah, my point is, I'd stick to modern AVRs for any task, choose which one based on the needs of my application, which you hopefully would sketch out ahead of time.
I only use AVR boards so don't know what I would prefer.
This is indeed the problem.
Any 3rd party library that is not actively maintained will probably not compile without modifications. Some modifications to those libraries are simple, some can be complicated.
True. Almost once a week here, someone starts a topic, "Why won't this Nano code compile or run on my Nano". Then we learn that it's an Every.
I would choose both.. 4 total, 2 of each. One for the desk prototype and 1 in reserve for suspected hardware issues.
Why, compatibility with libraries that are older and not updated actively.
You will need time to decide your "go to" board. The original "Nano" will always have some value even if just glue-logic.
Were I only wanting to go "cheap" the older board wins.
Were I only wanting the latest without regard for libraries, the new every wins.
For basic hacking and mucking around, testing things out, I just pull out a random board from the draw (As long as it meets the requirements). Its only when I am thinking about how to turn that test project into a real project inside a box, inside the wall, or other location, do I then think about what board to use.
Actually I would like to get to the point that when I am designing my final project I can actually just design a PCB board custom to the project. One day this will happen 
Its just a hobby for now.
Yeah. Two UARTs, and a MUCH better 5V power supply (at least, on paper.) More memory is nice, but I rarely run into the limits on the older Nanos. They're cheaper, too. (Well, if "genuine." Nano clones are much cheaper, barring "supply chain" issues.)
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.