My problem with using things like the RPi for such simple LED blinking projects is that it contributes to the cult of overengineering that plagues the industry. People seem to grow up thinking they need innumerable layers of abstraction to do things, when often they have actually made their solution not only inefficient, but actually less stable and more difficult to develop.
+1. Another criticism is consumerism - the hype that some of these devices created was more about purchasing and plugging boards and calling a library, without actually help hobbyists to learn something.
Or as John Carmack has said, low-level programming is good for the programmer's soul, it's hard to imagine that programmers do have souls if they has never been exposed to low-level programming. Unfortunately, in the modern computing world, the chances are becoming fewer and fewer, most systems are far beyond a complete understanding for most people. I think I'll never completely understand the x86_64 instruction set (w/ SSE, SSE2, FMA, AVX), or the signal path of the PCI-E interface on my motherbard.
Recently, I think some popular microcontroller projects may be the solution for a bare-metal programming experience.
But we can also looking it from another perspective - the proliferation of mobile devices changed everything, nowadays, even using a general purpose computer is not an experience that many members of the new generation may have (there was a Hacker News article about it). Some don't understand a hierarchical filesystem of files and directories anymore, and others have problem typing on a physical keyboard. In this sense, to blink an LED on Raspberry Pi is already a big step forward, and it was exactly the motivation behind Raspberry Pi.
Yes, it is unfortunate that in the pursuit of both compatibility and performance we now live in a world where even the CPU is so maddeningly complex that it is basically impossible to reason about how it will perform on any given piece of code. Even writing assembly leaves you a few layers of abstraction above where it would have 30 years ago.
I like to think that it is possible we'll one day develop a CPU architecture that is both simple enough to reason about and also highly performant.
Yes, and it's also the my reason of mentioning microcontroller projects. For example, some find the AVR instruction set is clear and powerful, optimized for both ASM programming and C compilers, and can be used as a good introduction to both hardware and assembly.
> I like to think that it is possible we'll one day develop a CPU architecture that is both simple enough to reason about and also highly performant.
RISC-V is getting there, with open-hardware cores such as Rocket (in-order) and BOOM (out-of-order). Too bad that many and perhaps most of the peripheral components even on a general-purpose SiFive SoC are still closed hardware blocks. But people are working on opening these up as well.
I don’t see a problem with this because this only happens in individual projects. Who cares if some teenager wants to control her reading lamp with a RPi instead of an ESP8266? Or if some dad wants to make a noise detection circuit for his nursery using an old laptop instead of an Arduino? What’s likely to happen is that they will both learn a lot of new things, including about the inefficiency of this. Just because you know better doesn’t mean it is bad that they did this. Besides, when you go for controlling your lamp with an ESP32, someone can always point to a simpler and cheaper processor to use instead. Then we can run into circuits designed without any software at all. Eventually you’ll be left with a MOSFET and a proximity sensor and your inner purist will be happy.
I say the point is that you should try to do trivial things with complex control systems and vice versa. You’ll do it better and more efficiently the second time. And the third. And if you decide to scale it, you will quickly learn the cheapest way to blink 10,000 LEDs.
Last year I've seen project that used two RPis for somewhat simple industrial automation task. After I pointed out that the whole thing is huge overkill the original author did some optimalizations and redesign which resulted in design that still had two RPis, with one of them being used as one bit 3.3V logic invertor and nothing else.
Needless to say the whole thing was replaced by single ~$20 chinese FX1N clone (which also neatly solved how to drive 24V industrial loads from RPi/Arduino/ESP...).
For this kind of problem you don't want breadboard. But on the other hand board with ATtiny, 12bit PIC or smallest MSP430 and few relays and optocouplers would solve the problem. And on the griping hand random chinese PLC exists and does not involve few man-days of NRE involved in designing such a thing.
"My problem with using things like the RPi for such simple LED blinking projects is that it contributes to the cult of overengineering that plagues the industry."
I disagree a bit with you (I do agree that if all the RPi ends up doing is flashing a LED, then that is a waste) You have to start somewhere and if it is flashing a LED with a Pi then cool. The path to ESP32 or ESP8266 is not far away and there is a lot, lot more to discover and play with and learn and frankly have fun with and maybe do something useful or change the world (or a tiny bit of it) with.
I had some of the best opportunities available to me in IT and electronics and electrics, schools, teachers etc etc etc. but I didn't have today's opportunities. If I was growing up today I think I would probably have started with a Pi and blinked some LEDs.
