A self-contained AVR programmer using an Arduino Uno
blog.jgc.org
blog.jgc.org
FTDI has a 'bitbang' mode that can work as a SPI (or well in this case, a ISP!) peripheral and lowish speed, and that's pretty much all you need.
Is it simply that AVRs are available in through-hole packages? Are they perceived to be easier to start with, compared to small ARMs for instance?
5V operation mean you can just plug it in to USB power directly without any voltage regulators.
High current sink/source capable pins, meaning you can drive LEDs and other stuff directly.
Pins with builtin schotky diodes meaning you can power the thing from AC power sources.
The Arduino ecosystem with many available projects for which moving to an ARM chip would bring no benefits.
> Pins with builtin schotky diodes meaning you can power the thing from AC power sources.
This can also be used for "accepting" 5v inputs in 3.3v devices, provided that the clamping current doesn't support the maximum allowed. Other microcontrollers don't always define maximum values for those currents, so it might be harder to use them like that.
It could be 12V from a transformer or some other induction coil like RFID or Wireless charger.
It's awesome to just hook up a random coil you found/wound to the pins of an AVR and watch it just work.
FWIW, it's common to drive LEDs from GPIO pins on other micros too. From a quick look at the SAMD21 datasheet for instance, GPIO pins are rated to sink up to 10mA which will make a typical indicator-type LED probably too bright for indoor applications.
> The Arduino ecosystem with many available projects for which moving to an ARM chip would bring no benefits.
My question (which you and others have answered, thanks!) was in the other direction: the Arduino ecosystem largely works for these 32-bit chips too; what benefit is there in moving to an AVR?
There is no other community that has documentation, tutorials, libraries, support forums, modules or just sheer number of people working with it compared to any other community in this space.
I don't want to be too unkind to your question but the tone sounds like you're disdainful of it because of a cost or performance issue (in that there are other options that are cheaper and/or more powerful) and this sentiment betrays a profound lack of understanding of how difficult it is to get into electronics, microcontroller programming or, really, any technical field, for most people. The "community" of Arduino is the selling point, not so much the power or cost (though if it weren't cheap enough this would be a moot point).
Personally, I think the libre/free aspect of it is also important as it allows people to use the tools and libraries in a commercial setting providing a "virtuous cycle" of sorts.
Are you in a technical field? When given the choice between using a new library, framework, programming language, etc. do you shop around for the one that has the best benchmark ratings or do you tend to look for a library, framework, programming language etc. that has a strong community, good documentation and a good track record or success? There are conditions where you do want to choose, or build, the most bleeding edge technology but this is usually when the core technology you're looking at is the main focus of the project. Most of the time, especially when it's not the main focus of the project, most people choose on multiple dimensions, not just bottom basement prices or speed.
Picking AVR seems a bit nostalgic, frankly, and I get that - a lot of my hobby time is working with old tech (like, sharp steel) because it's more enjoyable to me. I agree with you that there is a lot of "accidental complexity" in getting started with embedded, but I don't see how that really speaks to AVR vs newer 32-bit. Yes, the 32-bit chip itself is more complex inside, but a beginner doesn't need to know/care about that if the surrounding tooling is doing its job. I thought Arduino IDE had SAMD21 as a first-class citizen these days, so assumed it took care of that - is it not the case?
I work on firmware for my day job, and help run a makerspace. At makerspace, people starting fresh usually learn SMD soldering, and ESP32 with Arduino IDE seems like the most popular platform. At work, I'm a big fan of libre/free firmware, but hate how Arduino IDE fits in to a professional context (highly variable library quality, library management is a mess, difficult to handle build scripts, etc). I am 100% on the embedded Rust train.
This happens to a lot of people as they move through technologies. You’ve moved on and up, but that doesn’t necessarily mean that the STM32 boards are as welcoming to the individual who is getting started, or does only a project or two a year. Personally, I lean on ESP8266s for most everything these days. I have a cache of AVR devices that haven’t been plugged in for years because they don’t serve my needs anymore.
Such as? I’ve never had any issues with 5V IO on the 32F103
As an analogy, this is like a race car mechanic saying that "for the cost of dinner and a movie you can get a new fuel injector that makes your car run 10% more efficient". Technically true but you're not accounting for the domain knowledge that goes into knowing what are compatible parts, which model, what parameters to choose, how to install, how to fix etc etc etc.
Maybe newer 32 bit models will supplant all the Unos and siblings but as a snapshot of right now, documentation, tutorials, community etc. are mostly geared towards the atmega328 and friends. I also may not be accounting for the benefit of having all the cheap clones that are just as functional at 1/10 the cost.
> ... a beginner doesn't need to know/care about that if the surrounding tooling is doing its job.
This is one of the key points I'm trying to make and maybe where we disagree. I think the Arduino platform, with it's community, forums, tutorials documentation and including, but not limited to, the IDE, provide the cushioning to allow for people to create rather than need intricate knowledge about the domain, at least initially. In other words, I believe most other tooling is doing it wrong.
Let me restate that I help run a makerspace (minor asterisk, it has been in hibernation for several months for COVID). In practice, that looks like people with no prior experience wanting to make an embedded system (not in those words, obviously), 3-d print something, or just see what we're about. We tend to start people in the first group on ESPs, and they seem happy/successful. The second group more-or-less randomly ends up on OpenSCAD or FreeCAD depending on who they talk to, and has a fairly low success rate.
My impression of the Arduino IDE experience, when targeting one of the many available 32-bit boards, is that it's just as good as targeting AVR. There should be enough abstraction in the right places, so that a driver for an LCD or whatever will work just as well on either architecture. There might be one additional step to install the extension to use Adafruit boards for instance.
Are there a lot of people in the community struggling with 32-bit systems, doing things that just work on the AVR ones? From what I've seen, struggles with these small ARM systems, are usually either people starting from closer-to-metal (and the micro is, obviously, more complicated than an 8-bit AVR), or people working on problems that are just bigger than would be appropriate to solve on an AVR to begin with.
I'm familiar with the forums, blogs, etc. and I can accept there's more beginner-oriented material for AVR. However, that does not say that the material for more modern parts is insufficient - either in the Arduino world or outside of it. For the most part, the material people use when learning isn't (or doesn't need to be) architecture specific.
That said, I've been off in Rust-on-ATSAMD land in my programming time for a while (and am pretty burned out on programming in general), and haven't kept up with the ESP scene. There may be something better now, embedded tooling has been improving at a remarkable pace lately.
Another big draw is all of the daughterboards that use the arduino headers. No other ecosystem besides perhaps the raspberry pi has anything close to the amount of compatible boards.
In my experience, most newbies who have yet to pick a micro either want to learn programming, or electronics, or they've got an idea for a thing they want to build which will need a microcontroller; in any of those scenarios I think AVR is probably not the best answer.
So, I feel like recommending a person start with ATMEGA328P because it's a simpler architecture than ATSAMD21, is like saying that people should learn to drive in a 1960s pickup truck because it's simpler.
> Another big draw is all of the daughterboards that use the arduino headers. No other ecosystem besides perhaps the raspberry pi has anything close to the amount of compatible boards.
This isn't really an argument for AVR though, is it? All but one of the dev boards I've worked on in the last few years have either been Arduino or Feather form-factor, none have been AVRs. The one exception is a much chunkier machine.
With that goal in mind, I see simple devices like AVRs as a better first device because there is just less to configure. There's less to debug when things go wrong. There's only one clock domain. The datasheet is far shorter than most ARM devices.
When I look at the example projects for devices I use at work, such as nrf52, or stm32, and then try to put myself in the shoes of someone learning this for the first time, they seem overwhelmingly complex, when compared to similar examples for AVR parts.
I must admit that AVR hardware debugging is miles behind ARM though.
That said, I'm also just a higher-level software person and doing low-level embedded is too tedious for me to do it as a hobby :P
As you say, the debugging story on AVR in particular isn't great, but these tiny systems are famously hard to debug in general. I honestly think that people learning this stuff would usually be better served on a bigger machine where there's at least a console available. Yes, more complex, but at the same time that complexity allows for some separation between the thing being debugged and the debugging environment itself.
Professionally, most of my biggest challenges are around working with people who tend to attack the low level problem, without leveraging the high-level tools and abstractions. They might "fix" the problem quickly, but it creates this horrible maintenance situation where every little thing is subtly different, iteration is incredibly slow, and the system requires a bunch of skill to work on at all. I'd much rather have people who're good at software development and vaguely aware of how the machine works under the hood, than folks who're great at assembly and vaguely aware of how to use Docker.
AVR, through Arduino, is probably the easiest microcontroller to get started with.
Very small current draw, particularly in sleep mode (picoamps), otherwise good enough processing power up until 32 Mhz. The craft is complex because it requires both software and hardware (electrical engineering) knowledge for just about anything more than blinking a led.
It's fascinating in its own, when things work. When they don't (faulty wiring, lack of electrical contact, etc.), it's very frustrating.
> Is it simply that AVRs are available in through-hole packages?
Perhaps, for small projects. If you go a bit more advanced, you can order PCBs very cheaply online (5$ for 5 pcs).
> Are they perceived to be easier to start with, compared to small ARMs for instance?
In the end, you write code for a compiler so from your perspective, nothing changes.
Isn't this only true if you're only using the CPU and not any of the other onboard hardware? For example, consider this small Arduino program I wrote: https://arduino.stackexchange.com/a/56595/33351
It would need to be entirely discarded and rewritten from scratch to work on any non-AVR microcontroller.
But in most cases, you would use a driver and abstract away what individual registers get read/written. The HAL can be taken from anywhere, really. Doesn't need to be avrgcc/Arduino.
The registers in the link are C macros resolving to uint8_t*, pointing to memory locations where you read/write to.
It's much easier to learn how to do simple things with an AVR than with an ARM. For example, you can configure a timer to blink an LED with just four relatively simple lines of C on an AVR-based Arduino Uno, whereas it takes 11 lines of C on an ARM-based Arduino Zero:
The killer though? Very very long part supply lifetime. STM32 parts disappear all the time and have months of lead time.
Oh and they are second sourced now with some caveats.
I might use an Arduino Nano on a rare occasion. The same goes for an ATtiny85. The 85's are great for size-constrained projects, and are suitable for running off of coin cells. The RP2040 tiny might be a good substitute nowadays with a more generous pin count, but a higher price.
My go-to boards these days are STM32's and RP2040. I found the bluepills a lot of fiddle to work with, and I don't use them anymore. Maybe because I was using Chinese knock-offs. I recommend the Nucleo-64 F411RE because it has an ST-Link built-in, and you can transfer your code to a blackpill if you want to incorporate it onto a veroboard.
The RP2040 is a great board, too. Their SDK is the gold standard of SDKs (although admittedly I haven't seen all of them). It's relatively easy to peer under the hood to see how the code works. What would be really great if they released boards that had ST-Link equivalents on them, like the Nucleo boards. Uploading code is then no longer a chore, and you can use debugging.
edit: google says it's a processor like ARM but it is not ARM.
AVR--Alf (Egil Bogen) and Vegard (Wollan)'s RISC processor.
In addition, to my understanding, they held the patent on the first single-clock-cycle instruction execution. Atmel doesn't seem to want to acknowledge that so they don't pay patent royalties.