To be fair something like an ESP32 runs circles around the PCW1512, which we had on the school computer club, where we spent countless hours playing Defender of the Crown.
So we don't have to necessarily constrain ourselves to Assembly and C on those tiny devices.
> So we don't have to necessarily constrain ourselves to Assembly and C on those tiny devices.
Good point.
> something like an ESP32 runs circles around the PCW1512, which we had on the school computer club
I think as long as people are having fun with them, the hardware already served a good purpose. Even if the LED blinking is implemented by running Linux.
But in my opinion, people who are interested in these popular embedded boards should also learn about the basis of electronics, or just be aware of its existence, and understand the things one could do without buying a premade "board", and that it's possible to blink an LED with a few transistors. Well, I think most will find out by themselves, it's just a matter of time and guidance.
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.
Gently, friend, the 555's less than 10 cents at Digikey in medium quantities [0]. One of my hardare cow-workers happily placed one on the same board alongside a sub $ ST ARM MCU. Sometimes the 555's still the best option.
Disclaimer: I'm not very knowledgeable about DIY electronics and pretty bad with a soldering iron (shaky hands). Regardless I think it's super interesting and cool and thus my question:
I checked that site and "medium quantities" is 5000 of them :) (for a total price of $493). Somewhere on the page it says minimum amount is 2500, but I tried and wasn't able to successfully add that to my cart (only 5000).
So I guess that's nice, but how are you going to put even 2500 of these chips to use? That's a LOT of soldering to do. Unless you have some kind of machine to do that for you? But even then what are you going to use 2500 of them for, if not for reselling?
I believe you're asking a genuine question. It's not DIY (well, after we've prototyped it's not), these components are elements of goods for sale. Specifically the 555 was used as a watchdog. Runs of 5000 are barely enough to get the attention of stateside distributors so long as they arrive with orders for everything else on the board. As to how they're used, someone sticks a reel into a pick-and-place robot that populates the board, and the assembly shuffles into a wave soldering machine for the dirty work. It's very conventional stuff to the extent that $DAY_JOB's factory manages it from a third world-country.
So we don't have to necessarily constrain ourselves to Assembly and C on those tiny devices.
Naturally it depends on the use case.