Hacker News Reader

Comment by joezydeco | Hacker News Reader

That is spiritually what their Scheduler library is doing, as mentioned in the article. Which works for a lot of things just fine until one task begins to overrun its time slice or just hangs. And then you're looking into preemption.

But if you're overruning an AVR micro maybe it's time to take the training wheels off and move up to a larger system.

View on HN

> move up to a larger system

I'll take this one step further and suggest that beginners not start with the AVR, but instead with a Blue/Black pill (STM32) or ESP32. Leave the AVR for the more advanced people who are trying to squeeze every penny out of a project (even there, in many cases STM32 will cost less!!!).

I visit the arduino.cc forums at least once every day and the things that beginners want to do these days is far more advanced than what they would have attempted even 10 years ago. It gets very difficult trying to explain how to do things on an AVR that would be much easier on a processor with far more resources. String vs char* is one of those.

Hell, I don't know why we're even telling beginners to code in C++ in 2022.

My downvoted comment that boils down to "just use an ESP32 and get FreeRTOS along for the ride" is in this vein. The reality is that beginners have a lot of trouble wrapping their heads around writing nonblocking code using timers and something like a FreeRTOS thread is a much simpler concept to explain.

Rant over :-)

I agree- I think just about everybody should start with an ESP32 instead of an Arduino. I still use the Arduino API when programming the ESP32 (due to the large amount of compatible drivers) but I've also installed FreeRTOS and ported zork. I am embarassed to say I also got C++ STL working on an AVR with 8k of ram- enough to allocate a std::vector<int> of length 2.

I actually use the ESP32 version of FreeRTOS professionally, and I can't imagine rolling your own scheduler and all the work involved when someone could just use the existing FreeRTOS codebase. The ESP32 stuff is awesome for my hobby projects, I do see the warts when I use it professionally though, trying to get the system to do more than a couple things at a time is not easy. We've re-written a number of core ESP-IDF packages, or gone through the pain of porting the vanilla FreeRTOS stuff over. We're also using C++, I'm looking forward to Rust.

It's funny - I stepped away from electronics when I started college and in the first few years out of it just due to not having enough free time. About a 10 year period.

I come back and now AVR is old and slow and ARM is hot stuff. All it took was the tooling becoming nearly free. No more $500 ISP programmers, just USB DFU boot.

yea, usb dfu, better tooling and the price is nearly interchangeable. heck, small PDIPs are sometimes more expensive and less stocked

I remember the first ARM board I got back in like 2008 required some Keil IDE which was >$1k for hobbyists and only had a 30 day evaluation included in the kit. Made by a company called Luminary Micro iirc. Builtin programmer was locked to only work with that specific chip. Never seriously considered ARM for a long while after that.

I'm a casual embedded-electronics user at best, most of my projects haven't advanced much past turn a simple servo, light some LEDs, maybe read a sensor and POST to an endpoint. For these tasks, Arduino has been pretty good for me and removed a lot of the complexity. The `setup()` and `loop()` model makes a lot of intuitive sense. That being said, I've spent no small amount of time on `String` vs `char*` (as an inexperienced C/C++ developer) and found the guardrails of the Arduino ecosystem to be very frustrating.

Do you have any recommended resources or additional search terms to explore to learn more about hobbyist-level embedded electronics outside of the Arduino ecosystem? FreeRTOS looks interesting but it seems to add a lot of overhead versus something simple like Arduino. Similarly, I've looked at STM32 programming before but my searches were very generic and the STM ecosystem is massive. Specifically, I was trying to figure out if I could reprogram some old drone flight controllers (equipped an STM32F103CBT6 with a bunch of useful embedded sensors, running old versions of "betaflight") for personal projects but the entrypoint to STM programming (STM32Cube?) and the setup code was considerable.

The beauty of the Arduino is the ecosystem behind it. The original hardware is verging on obsolescence, to be polite, but the same code and programming methods can be used on STM32 hardware (that's Arduino-compatible, like the Blackpills) or ESP32. The main difference is that now you have much faster, more modern processors, far more Flash and RAM to play with, not to mention a more powerful I/O peripheral structure if you want to dig into it at that level.

FreeRTOS on an ESP32 in the Arduino IDE is effectively free: you don't have to do anything to enable it. It's pulled in by default.

AFAIK, Arduino support for STM32 is limited to the F103 & F4xx series.

I confess that since my entry point is as a professional, I really haven't kept up with what other hobbyist-level entries are still on the market. That said, a good place to start would be with an STM32 Discovery board -- if you can find one these days! Looks like Digi-Key has exactly 1 in stock rn. It's a $19.95 board with an 'F407 and some sensors and output devices. No external tools needed: you can program it through a USB port. All the tools can be downloaded from ST Thomson or its partners for free. This is more entry-level professional than hobbyist, but there's no sharp dividing line there.

The Raspberry Pi pico is also taking off: https://www.raspberrypi.com/products/raspberry-pi-pico/ I haven't used one yet, but they seem to be amazing little devices and the community is rallying around them.

Pi Pico is also dual core, So in essence it should be easier to write multi-tasking code there.

I think AVR is a good architecture to learn on, because the devices are far simpler than ARM or other more modern chips. The main concept to master as an embedded developer is operating a device by its registers. The common arduino device, ATMEGA328, has a total of 84 registers across all peripherals. A simple program to blink the LED is less than 10 lines total. The datasheet is tiny compared to most ARM devices, but is still a complete source of information.

There are lots of libraries online that demonstrate how to set up registers for various peripherals. Avrgcc is an open source toolchain, and avrdude can program devices running the arduino bootloader.

That was true when one had to write assembly code. Now we don't really have to any more, thanx to Arduino mainly (which bilds upon avrgcc and avrdude). It's easier to learn on the new platforms because you can use higher level programming languages like MicroPython, especially for easy stuff. I can do a blinky by writing three lines in the uPy REPL.

If the registers are abstracted away, you're left relying on other people's code. I suppose learning microcontrollers can mean different things to different people, but as for becoming a professional embedded developer, micropython and Arduino are dead ends. There is no transition to truly understanding the hardware.

We use MicroPython commercially so my perspective is different. :) I do agree with your intent though; just because you're using a high-level language it doesn't excuse you from learning how the hardware works.

However, if you do know the hardware, if you are familiar with what's going on under the hood, then MicroPython allows you to write the majority of your system significantly faster.

This is subject to change, as embeded developers now focus on writing lower or higher level code mainly in C/C++ as the industry migrates away from 8-bit MCUs to 32-bit ARM and RISC-V. Of course you're relying on other people's code, as you can't expect everyone to write their own RTOS and standard library and also achieve an acceptable time to market. Most embedded hardware products use an existing RTOS and build upon it. Understanding how the hardware works always helps, but most of the time you don't have to dig to register level to do that.

Micropython and Arduino are not dead ends but hobby grade tools.

I hear ya, I think we're just in a different era now. Users can wrap their head around a precooked framework that's ready to go and only needs a few API calls to make something happen. Beyond that? That's homework and homework sucks.

FreeRTOS really isn't that large of a leap forward, in fact when it's done right on your target platform it's just a few API calls as well. But it means wrapping your head around a lot of detailed concepts (stack size? semaphores?) when all you want to do is light up that string of RGB LEDs.

Stack size is a thing on Arduino as well.

Don't be too quick to dismiss the "training wheels" of AVR.

While ARM and RISC-V may have beefier processors, and will probably be migrated to or adopted, AVR has a lot going for it.

First, a common AVR board like the Arduino Uno has built-in peripherals like a temperature sensor. You can build something out of the box without buying external items. If your target market is cheap educational, that's key.

Second, it offers basic microcontroller features like power management, external interrupts, serial and other stuff.

It provides a terrific cheap platform to understand managing interrupts and concurrency safely in your language of choice. Which can be applied to the bigger boards.

Finally, memory constraints require careful thinking through code. I'm not going to implement a full standard library on an Arduino AVR, so what do I bring with me?

Reply on news.ycombinator.com