(2024-11-25) Boosting the 8-bit skills with AVR microcontrollers
----------------------------------------------------------------
Yep, I've got a new hobby that eventually can bring me one step closer to one
of my dreams. It started when I remembered that I had an old clone Arduino
Mega 2560 board from a RepRap-like 3D printer build kit that I never
finished and never will. Such boards, as you might well know, are usually
programmed via the C++-based Arduino IDE but I decided to go with pure C
from the day one and use bare avr-gcc and avrdude directly. I also purchased
a bunch of smaller clone Arduinos (all Nanos, either on ATmega168PA or on
ATmega328PB), a bunch of programmers (more on that in a bit), and a bunch of
wires, keypads, displays, resistors and breadboards, as well as downloaded a
bunch of pinouts and datasheets. And the journey began.

At first, I didn't need a dedicated hardware programmer at all, as the
ATmega2560 in the Arduino Mega is usually flashed via USB with the standard
bootloader ("-c wiring" option in avrdude). But then, it just so happened
that when the first of the (clone) Nanos arrived, they didn't have any
bootloader inside and I thought to make the Mega a programmer for them. And,
of course, I managed to flash the wrong .hex file onto it. And, of course,
it erased the bootloader. So, I rush-ordered the first USB-powered
programmer I could find online. It was marked as Arduino-compatible and
USBasp-compatible but... it turned out to be an ATmega88-based Chinese clone
that wasn't in fact compatible with USBasp and required a specific
(Faildows-only) Chinese piece of software to work. Luckliy, I found the
project to flash it back to the normal USBasp firmware ([1]) along with the
instructions on how to do this. But it still required a "normal" programmer
to perform the conversion. So I ordered another one, this time picking more
carefully. Well, guess what... The new one didn't want to work on my
Raspberry Pi 5 no matter how I fiddled with the USB ports and USB-related
kernel settings. Turned out that was one of the very first clone versions
that required more current than the Rpi5 could deliver. Luckily, I managed
to successfully connect it to my parents' PC with Ubuntu, so I quickly
installed avrdude there and flashed the first one according to the
instructions (basically, you have to make a jumper between the two "UP"
holes before flashing, and remove this jumper afterwards). After the bootleg
programmer was successfully recognized as USBasp, I tested it on my RPi5 and
everything worked smoothly. To be on the safe side, I ordered three more
programmers of yet another type, also marked as USBasp-compatible, but I'm
still waiting for their delivery as of today.

But then, when I managed to restore the Mega 2560 to its normal state, I
started tinkering with the Nanos. In my first batch of Nanos, two of them
had ATmega168PA, and two of them had ATmega328PB. For the untrained eye like
mine, these chips look identical, with the 168 having half of all the specs
of the 328. But when it comes to flashing a bootloader, the chip version
matters a lot. I guess you can interchange the bootloaders for the 168P and
168PA, but you definitely can't interchange the bootloaders for the 328P and
328PB. That's why I spent a lot of time trying out various bootloaders I
could find. And man, I don't know, I've read everywhere that Urboot is much
smaller and better than Optiboot but I couldn't get any Urboot build to be
as stable as Optiboot in any of those boards. Yes, Optiboot is much older
and a bit chunkier but works flawlessly every time. And it still requires to
specify "-c arduino" instead of "-c urclock" in avrdude when flashing.

So, what am I going to do with all this after learning all the necessary
basics? Well, I have several plans in mind. The first one is porting one of
my interpreted platforms to AVR. Since this is a Harvard-type architecture,
it's not a trivial task as you get the program memory completely separated
from the RAM, and you don't get a lot of RAM either. But I have started
porting my LVTL-R variant of the VTL-2 language to these MCUs and it looks
promising so far. The second plan is something I've dreamt of a long time
ago: an independent mobile platform that perfectly fits into my low-powered
computing paradigm. I have a couple of SIM800Cs and other wireless modules
to tinker with, so that looks like a perfect opportunity to finally make
some use of them. And I am learning to work with Nokia 5110 LCD displays,
character-based LCD displays, some OLED displays and 16-key keypads, so you
might take a guess where all this is heading.

Finally, I was pleasantly surprised to find out how cheap all this is
nowadays. In the previous decade, even an MCU board like Arduino Nano was
quite expensive. Now, you can get a full Nano clone with a microUSB or even
USB-C port for well under $3. I remember the times when you couldn't get a
single MCU chip for such a price. On the other hand, that makes it
economically impractical to purchase the ATtiny series: the chips alone
approach the price of these Nanos and sometimes even surpass the price of
full Arduino-compatible boards with 328P-like chips like LGT8F328P. I hadn't
experimented with those, for now sticking with the original ATmegas only,
but planning on ordering several of those clones as well. Cost-wise,
however, there are some strong competitors that give an even better bang for
the buck: ESP8266 and its clones, and, if you are ready to pay a bit more,
RP2040-Zero and its clones. Both of these families can even run Python, an
opportunity I definitely will explore in some of my upcoming posts (as I do
have some ESP8266 boards lying around as well), both of them have pretty
indestructible bootloaders, and both of them, especially the RP2040, require
much less hassle to get your code up and running. And, if and when I hit the
limit of what could be done on the AVR8 MCU family, I'll definitely consider
those as a more future-proof approach.

--- Luxferre ---

[1]: https://github.com/aleh/usbisp