A self-contained AVR programmer using an Arduino Uno(blog.jgc.org)
blog.jgc.org
A self-contained AVR programmer using an Arduino Uno
https://blog.jgc.org/2022/07/a-self-contained-avr-programmer-using.html
3 comments
What draws people to start projects with AVR in 2022?
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?
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?
> What draws people to start projects with AVR in 2022?
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.
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.
It is an honest question: the first of my many AVR-based projects was at least 15 years ago, and it was an improvement over PIC prior to that, but I just don't see the draw to AVR anymore. For the cost of pint at the local pub, I can have a delivered STM32 development board. The tools and techniques that make sense to use with that development board will serve me well both in a hobby and professional context. [Edit to add: there seems to be plenty information/guides/forums freely available.]
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.
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.
Again, I think you've lost sight of just how difficult some of this stuff is from the perspective of someone who has no or only passing familiarity with it.
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.
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.
> Again, I think you've lost sight of just how difficult some of this stuff is from the perspective of someone who has no or only passing familiarity with it.
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.
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.
What is your preferred tool chain for the esp32?
The Espressif Arduino IDE plugin, but IIRC MicroPython was looking pretty good on that platform too.
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.
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.
> I just don't see the draw to AVR anymore. For the cost of pint at the local pub, I can have a delivered STM32 development board.
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.
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.
[deleted]
5V compatibility can still be useful for interfacing with older devices. 5V tolerant low voltage IO can come with some problematic caveats many of which are blissfully ignored by much of maker community.
> 5V tolerant low voltage IO can come with some problematic caveats
Such as? I’ve never had any issues with 5V IO on the 32F103
Such as? I’ve never had any issues with 5V IO on the 32F103
DIP package meaning it's easier to plug/unplug into a breadboard.
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.
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.
> High current sink/source capable pins, meaning you can drive LEDs and other stuff directly.
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?
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?
> Pins with builtin schotky diodes meaning you can power the thing from AC power sources.
Well, the clamping diodes that are present in all I/O pins are supposed to be used only for ESD protection. I think they were refering to the fact that some people have used them (and a quite big series resistor) as a "cheap" way to connect them to AC directly. There's even a application note (from 1997!) mentioning this: http://ww1.microchip.com/downloads/en/AppNotes/00521c.pdf
Obviously the device loses its galvanic isolation and should be kept in an enclosure that can't be touched.
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.
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.
Interesting, thank you. That's not an experiment I would do, but it is interesting to know nonetheless.
AC doesn't necessarily mean 110-240V mains voltages, it just mean alternating current.
It could be 12V from a transformer or some other induction coil like RFID or Wireless charger.
It could be 12V from a transformer or some other induction coil like RFID or Wireless charger.
Sure, but is that ever actually encountered in practice?
In hobby/student projects, yes, very often. Maybe even in some cheap white goods. Otherwise they wouldn't have bothered publishing application notes on it.
It's awesome to just hook up a random coil you found/wound to the pins of an AVR and watch it just work.
It's awesome to just hook up a random coil you found/wound to the pins of an AVR and watch it just work.
Terrific, thank you! I've never seen this, but it's good to know if I ever come across such a device.
> What draws people to start projects with AVR in 2022?
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.
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.
> 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.
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.
Yes, you are correct.
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.
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.
Tool chain is very decent, doesn’t require any vendor IDE crap, the data sheets have less bugs that STM32 and PIC, they are easy to work with, have a decent set of peripherals and there’s a hell of a lot of info out there.
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.
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 think they are an easier architecture to learn about microcontrollers than ARM. The atmega328, used in a lot of arduino boards, only has 84 peripheral registers. At least with avrgcc, a program to blink an LED is less than 10 lines. Every ARM device I've used is far more complex, both in register count, and minimal code examples. The ability to understand all of the hardware of an entire device is much more attainable on an AVR.
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.
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.
As I've tried to write in another response; my assumption is that most people aren't getting in to embedded to learn about architecture, and they'll start with a development environment like the Arduino IDE that handles that complexity of setting up clocks etc for those examples.
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.
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.
I don't think the arduino software ecosystem is a good path to becoming proficient in embedded development. The very concepts that you need to really understand well, working with registers and understanding the microcontroller as a set of digital circuits, are abstracted away.
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.
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's a tricky one; there's just such a wide variety of learning styles, goals, prior knowledge, interests... In my formal education, we used a 68k platform to learn assembly and the sorts of things you're talking about. That epistemic style is very different from what I see most makers using, and maintaining excitement about.
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.
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.
I'm with bacon_waffle on this - for the majority of people where I witnessed this the entry doesn't really matter, and once you come up to the limitations you'd have to kinda start from scratch for this arch anyway, but the top-down approach goes a long way.
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
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
Cheap, simple, easy to learn about, and write assembly for. Also the new tinys have alot of neat features, and 8-bit is just retro :P
They are reliable, easy to learn, low power, have an open source toolchain (and multiple open source programmers), a wide range of package and feature combos, TONS of examples and libraries (even without Arduino), require few external components... on and on and on. If they fit the needs of a project they are quite pleasant to work with and not every project needs a powerful MCU. I dunno if I'd pick them for a large scale product because of unit costs, but I use them all the time for hobby and even some limited production work-related stuff when parts costs are a rounding error.
An Arduino Uno is ready to go out of the box with IDE and cable. I recommend that people buy Elegoo starter kits, which also come with components and instructions for projects. The ecosystem is unsurpassed. It's also one of the simpler microcontrollers, so you're not overwhelmed if you want to peek under the hood.
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.
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.
I love the sheer variety, ingenuity, and even photography of these largely AVR projects:
http://www.technoblogy.com
http://www.technoblogy.com
As with anything, a toolset you know, a broad, welcoming community, a well-established, well documented set of libraries.
AVR, through Arduino, is probably the easiest microcontroller to get started with.
AVR, through Arduino, is probably the easiest microcontroller to get started with.
> What draws people to start projects with AVR in 2022?
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:
http://www.technoblogy.com/show?3RC9
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:
http://www.technoblogy.com/show?3RC9
It's not just a tiny CPU. Microcontrollers typically have a bunch of "peripherals", blocks which implement a specific function or protocol, like SPI, I2C, PWM, DAC, ADC, and so on. For a given project, choosing the right microcontroller means you need substantially less chips to interface with the outside world. I've worked on projects where AVRs were just the perfect choice.
It's mainly Arduino-induced popularity, I think.
You can get fake Arduinos for less than the price of cheap coffee.
What the hell does AVR mean???
edit: google says it's a processor like ARM but it is not ARM.
edit: google says it's a processor like ARM but it is not ARM.
Atmel AVR are very popular microprocessors. It's what powers the first and probably still the most common Arduino.
If i remember correctly, these are initials of the first designers of the architecture. Norwegian guys.
Yes initials of Norwegian guys.
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.
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.
automatic voltage regulators are all i can think of, and i get a downvote, lol
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.