Join us on Wednesday, April 21 at noon Pacific for the AVR Reverse Engineering Hack Chat with Uri Shaked!
We’ve all become familiar with the Arduino ecosystem by now, to the point where it’s almost trivially easy to whip up a quick project that implements almost every aspect of its functionality strictly in code. It’s incredibly useful, but we tend to lose sight of the fact that our Arduino sketches represent a virtual world where the IDE and a vast selection of libraries abstract away a lot of the complexity of what’s going on inside the AVR microcontroller.
While it’s certainly handy to have an environment that lets you stand up a system in a matter of minutes, it’s hardly the end of the story. There’s a lot to be gained by tapping into the power of assembly programming on the AVR, and learning how to read the datasheet and really run the thing. That was the focus of Uri Shaked’s recent well-received HackadayU course on AVR internals, and it’ll form the basis of this Hack Chat. Then again, since Uri is also leading a Raspberry Pi Pico and RP2040 course on HackadayU in a couple of weeks, we may end up talking about that too. Or we may end up chatting about something else entirely! It’s really hard to where this Hack Chat will go, given Uri’s breadth of interests and expertise, but we’re pretty sure of one thing: it won’t be boring. Make sure you log in and join the chat — where it goes is largely up to you.
Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, April 21 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
The irony is, what’s going on inside the AVR is in the end quite simple and easy to understand once you have a look around. The Arduino ecosystem manages to obfuscate that to the newcomers by saying essentially, “you don’t have to look at the datasheet, in fact, it’s a bad idea to touch the registers yourself.”^ Then it plonks on a bunch of poorly documented do-it-all libraries that think for you, do stuff behind your back, and don’t tell you about it. Then everybody just copy/pastes the “sketches” without understanding what it means.
In the end, you have to remember that the point of Arduino is to sell Arduino – the brand, the ecosystem, and finally the various boards. It manages that by convincing the users not that embedded programming is easy, but that it’s hard – even if it’s not the real intention. It’s like directing someone two miles down the river from the fording and helpfully offering them a boat ride across – for a just a tiny token fee of course. Oh, and don’t look at the map for the shallowest point to go across – you don’t need that thing while I’m your guide. See how easy it is?
The original intention may have been to help the hikers not get their feet wet by taking a short detour, but then somewhere along the line you forgot that people can just simply walk across the river themselves because hey, the boat makes you money – and that’s how you get something like Arduino.
^(See the arduino documentation on direct port manipulation.)
Whatever Arduino’s intent, the result is that it’s a gateway drug into embedded computing for many. First you deal with the abstractions and simple tools, then many start first using and then writing (often badly written) libraries, then you start doing more advanced stuff more properly and many subsequently jump to other microprocessor families. Entering the process is trivial and there’s a very neat near seamless gradient towards low level embedded computing.
That’d be a lot harder to facilitate with full blown ARM processors and manufacturer IDE’s. Just properly configuring an ARM processor and its peripherals can be a tough nut to crack if you don’t already know what you’re doing.
If the gateway theory holds. I don’t find the “gradient” neat or seamless at all, since the hand-holdy nature of Arduino means people are coming in with no programming background, no electronics background, no comp-sci background and suddenly you’re expecting them to untangle wiring.c to solve why some ARM board doesn’t go into low power sleep. Not happening.
^ This!
In my experience the “hard” part is setting up the Makefile, not fiddling the registers, which isn’t really any different than assigning a value to a variable.
And you can mostly just use the same one, usually you don’t change more than a file path.
GCC does the hard parts for you, not the IDE. ;)
(to clarify, I meant the hard part of AVR programming without “Arduino”)
This is exactly what I want to get into, RubyPanther. I like the Arduino as a family of cheap dev boards, but I would *love* to move away from the IDE. Are there any guides you (or anyone else who is reading this!) can recommend that explain how to program an AVR with GCC? I’m happy to do it either on an “arduino uno” style board or to flash directly using ArduinoISP.
Thanks :-)
Indeed. You already have a bunch of standard libraries without Arduino. Arduino does more shady things, such as redefining some of the standard functions, like the abs() function which in Arduino is made to work on all types, but which then fails in certain cases like abs(a++).
Being so “helpful” they actually make subtle differences that break compatibility outside of the Arduino ecosystem. With the standard libraries, you have one absolute value function for int and another for float, and this is explicit – with Arduino it’s implicit, and it behaves in a different way, so code is no longer portable. This is why Arduino is said to have its “own” language.
I do have to agree that a lot of people seem to go into microcontroller programming by starting out with Arduino and then never even trying to take a step beyond it.
That the Arduino ecosystem provides a lot of creature comforts is fairly true. It is honestly nice to just hook up a single USB cable and then be on one’s way.
An Arduino is more or less a stopgap between microcontrollers and “industrial” PLCs. Sitting in between with the advantages of non. It lacks the industrial certifications of a proper PLC. But an Arduino also obfuscates a lot of the hardware while also being more expensive than the raw micro it is building on. And shoehorning in an Arduino into a product is something I have seen far too many times…..
To a degree, the ESP32 is in the same boat. But its substantially higher computing performance and networking capabilities makes it more of a lower end Raspberry pi than anything. Not to mention that its form factor is more adapted to be a drop in module in a more competent fashion than what most Arduinos are.
In the end, Arduinos are great at introducing people to microcontrollers, but are also painting a far more horrific picture of microntrollers in general than what normally is the case.
i believe my expierences with microcontrollers may help.
first i learned bs2 (basic-stamp-2)
then i learned arduino
then i learned assembler on PIC16F877A, this was the first time i truly enjoyed…
now im learning assembler on AVR
i ONLY switched for more RAM and ROM and i have got to say; assembler on AVR would be intimidating if i hadnt learned assembler on such a simple chip first…
then again some say the mindset required to enjoy assembler on a PIC16F877A indicates personality disorder or other mental defect… let me explain; for every 1 hour of creating you spend 3+ hours optimizing, you only get 8k prog and 300 BYTES ram; so code wisely.
framebuffer, animation, features, main-program, then MAKE room for new-est feature,
then MAKE room for next feature, then MAKE room for next feature…
then again, i think if i learned assembler on AVR first; i would bash my head into the wall trying to wrap my head around the PIC16F877A… you need to switch program pages and switch RAM pages… there is a small shared area between pages (of RAM) and if im not mistaken the main-status register is on first-page, not so bad? how about YOU ONLY GET ONE CPU REGISTER, the W register, thats right ONE 8-bit register the rest is RAM that needs a page-switch and a location-pointer, but if you are on a different page (for the destination) then your already full shared area needs to pass the data, so back up the data there to a page by switching pages, but the sub-routine to do that is on a different PROGRAM page… oh the madness.