Before becoming a web developer I worked as an embedded systems dev for a few years. That experience left me with valuable skills in data structures (Everything is C), understanding how a processor works and executes instructions and hardcore debugging.
Not sure if I would recommend building a career in embedded but you will start learning transferable skills doing it in your free time.
Hey, maybe off-topic but I felt compelled to finally create a HN account to ask a question: would you mind sharing your thoughts and motivations behind your switch from embedded to web dev?
Currently, I am an embedded system developer and I concur, I've learned a lot about data structures and how computers work because "everything is C". Especially true as I graduated as EE with more interest in software. I've been enjoying my short career so far, and like the way my thinking has changed from all learned experience. But I can't lie that I worry about whether I should be focusing on web tech and that embedded stuff will fall off. You not recommemding building a career in this area and actually making the switch intrigues me a lot.
If your concern is the ability to get jobs, I can see the point of that question. Keep in mind (I think) that it's increasingly difficult to pull off a full career of any kind of programming.
One thing that happened in embedded, and bear in mind that it ain't just low-end microcontroller stuff, is that it tends to be tightly bound to hardware. Hardware tends to be built in Asia (which I remember ramping up in the mid 1980's). Successful/higher volume products tend to be built in Asia. Engineering tends to follow manufacturing over time.
For fun, it's hard to beat specialty companies that build complicated gizmos with software in some sort of sexy business, but they are hard gigs to track down.
There were a few reasons to switch. I was working in the automotive industry where building anything is a race to the bottom. "How much cheaper can we make this than our competitor" was how design decisions were usually made. Software was the bottom of this list as manufacturing doesn't see it as a profit driver and mostly as an expense. I was in a pickle because I loved the projects I was working on... Ultrasonics, Radar combined with some sort of actuator or motor. Lots of FFTs, debugging boards, soldering, learning Altium and a great boss but I was always pulling nails to get money for projects. I knew I wanted to work somewhere else where the product was software / electrical hardware and I was having a hard time finding the right fit.
After talking with some friends who do webdev (Node, Python) I learned JS in a couple of weeks and got hired into a consulting firm where I worked for 6 months building a document search engine in C# on top of ElasticSearch. I now lead a team at a small firm that builds specialized search applications for different parts of the internet.
I now know of places that have the software culture (and software money) that do embedded systems well but I love what I do now with no shortage of cool problems to work on. Not sure if I would go back into embedded but I still dabble with Arduino's and Pi's.
> "But I can't lie that I worry about whether I should be focusing on web tech and that embedded stuff will fall off."
While they're never going to be as plentiful as web jobs, it seems unlikely embedded jobs are going to be decreasing anytime soon. The market for industrial and consumer IoT and wireless mobile devices just keeps on growing and growing. Unless you actually prefer webdev over embedded, there's no reason to jump ship and every reason not to waste your specialized education.
If anything, it's more likely that web development will hit a peak and then start declining. As people on HN are fond of proclaiming, much of a college education isn't needed to be a successful web developer (very much unlike embedded development). So every year, more and more people keep flooding into web development and that is bound to depress wages and demand at some point.
My educational background is more towards EE (ECE, focused on control theory) but my work background is more towards software and IT. I've been working on embedded software for a decade or so. If anything, it seems like the embedded industry is getting bigger rather than smaller, like my role in the industry will be around for a lot longer than I'll want to be in it.
People get quite invested in their physical things, and I think that's going to translate in to ongoing software updates, and making interfaces between older things and new things (I'm currently working on an interface to old-school telephone gear, working in Rust). More things are being made with computers in them, those computers are getting more sophisticated, people are caring more about software quality and security. And, as a sibling post mentions there's always pressure to (re)engineer things to cost less or earn more money.
Sidetracking a bit, I think one of the best pieces of career advice is to be comfortable at the intersection of a couple different areas/fields. While it may be easy to find/train a developer or EE to some particular skill level (maybe not the best example given the closeness of these fields), it's much harder to get someone at that level in both fields. It sounds like you're already doing that by working as a developer but having an EE degree - you'll do well to stay sharp in both.
My first job out of college was doing embedded development and since then I've moved onto Mac and iOS development with a little bit of web frontend and backend work.
I have to say, the embedded stuff feels way more like you have control over the machine, I guess for obvious reasons. The tooling is specifically designed for your hardware, so what you need to do to achieve your goals is more obvious. I've found native app development similar to that. There's nothing quite like just focusing on a specific problem and plugging away at it and not having tools get in your way.
On the other hand, web development is kind of a chore in that there are so many tools, frameworks, and just different ways of doing things. For focused work, I think I prefer embedded development, but it's kind of limited in the type experiences you can gain for sure.
I've gone the opposite direction (kind of). I started learning web dev (self taught). PHP, Ruby, Python, JS. Full stack but never got into the cloud era much. But pretty confident I could build anything I set my mind to. This began in the 90s and a couple years ago I started messing with Arduino and finally using C after years of using C-inspired things (it's much less fun for me, 90% seamless but at times feels like work trying to figure out the simplest things seems difficult sometimes or the generally accepted solution is way more complex than I really want). During about Fall of 2020, extra bandwidth from COVID WFH, I finally thought of a big project I wanted to pour some effort into (excitement of making lights blink wore of fast). More difficult than the code, is all the EE stuff. And actually having to engineer things together to create a project. At least in my case, I'm using stepper motors, which means stepper motor drivers and secondary power supplies. I'm also using air pumps, solenoid valves, linear actuators, limit switches, rails systems (open builds is awesome), all kinds of things. The breadboard wiring was insane. Then I built a PCB to organize some of it. I still have no idea when or if I should be using resistors, capacitors, etc. I'm super unfamiliar with electronics but I feel pretty confident at this point I can learn/solve anything on YouTube. Emphasis on Youtube. I Google for software and Youtube for hardware; that's a key distinction I've noticed. I need to see how other people are wiring things together. I can't read a diagram at all. I'm pretty close to a working prototype and have somehow pieced it all together.
Glad you’re making headway and progress on your idea and glad you’re catching up on knowledge on youtube. My honest opinion is that you don’t need to know everything EE to get stuff done and if you indeed have a great idea that can potentially make some money, you can hire someone with experience in the field.
I work as a back-end developer so I usually get don't work at the "bare-metal" level. I did get to use a CPU profiler to isolate a lock contention issue with one of our services recently and it was super fun.
But I have realized that I have some gaps in understanding how a processor works (bad idea to not pay attention in your Comp Arch class), I am trying to cover that up by reading up on Comp Arch (Onur Mutlu lectures).
would working on Embedded (in my spare time) help in understanding the processor at a deeper level ? Any pointers on how I can accomplish that ? I am well aware that modern processors are complicated beasts, more complicated than Embedded systems for sure not sure how transferrable those skills are.
Are you more interested in understanding the processor itself, or low-level software, eg operating systems concepts and how that interacts with the hardware?
Embedded can certainly help with both, but I would go in the opposite direction from hobbyist-oriented systems like Arduino: learn to set everything up yourself. Bare metal programming, particularly with C and assembly, will require you to understand things like stack pointers, setting up your clocks, initialising hardware.
While 8-bit micros are simpler and you could start with one of those if you wanted (AVR is probably the most accessible), I'd probably go straight to a 32-bit Cortex-M4, get a cheap dev board like [0], and get the sample programs running and try to understand every part of those.
I found that AVR devices are more approachable microcontrollers for learning the concepts of setting up and using peripherals at the register level, and studying the part's datasheet. They are so much simpler than ARM chips, with far fewer peripherals and registers.
I think a good approach to this is to take working examples, look up the used registers in the datasheet, understand why setting up the peripherals that particular way accomplishes the goal of the example, and then start experimenting with changes to those registers.
I did embedded systems for 20 years before moving towards backend/web development. However, I still do a bit of embedded development. One thing I found is a "hobbyist" approach to writing embedded code is fine for home made projects, but tends to turn into disasters in commercial projects. Beyond simplistic embedded systems (quite a few projects I work on have multiple embedded devices, but often have code that do one very specific thing) you need to create a well designed "engine" which is like a mini custom OS with very modular and adaptable micro "services". Where everything is built from the ground up to be traceable and observable for easy debugging. This has to be done really efficiently where there often isn't much wiggle room. Everything has to be done very robustly where things can be easily tested and simulated. It's quite fun to build systems like that, but they do require quite a specific set of design skills.
That does sound fun. Formal systems approaches and automata always seemed more applicable to embedded development. State machines, statecharts, etc always seemed like something I was using on my projects. However, I also felt like I was always writing loops and tests for why some bit wasn’t flipping or some event didn’t occur. That’s the frustrating part... reading and rereading manuals and scratching your head.
Yup, exactly what you said. If you can define the system as a finite state machine do so, then define it. Much easier to reason about and if your state is correct you can have a high level of confidence on the robustness of your code.
Am admittedly too inexperienced to properly weigh the pros and cons of various platforms, but I find the Rust support for certain embedded platforms to be compelling.
You'll spend an inordinate amount of time painting boxes to be the right color and design. Or drilling holes that are just the right size. Or deciding on acrylic cases vs wood cases vs altoid containers. Or the pros/cons of 1.5" standoffs vs 2" standoffs.
Once you figure out those details: you need to think of power (4xAA is my favorite), with probably an efficient buck-converter to drop the 5V down to 3.3V, and then a myriad of sensors that are in the 3.3V range... probably SPI vs I2C interface, or maybe a raw voltage reading so that you can do thing from your ADC converter directly.
Then the whole thing is cobbled together with maybe 500 to 1000 lines of code. Like seriously, code is the easy part.
Then you realize that your ADC converter is having an aliasing issue (physical: nothing related to code), so you need to build a low-pass filter. Do you wanna go with a passive inductor+capacitor approach? Or is your ADC converter at a high enough frequency that you need to go with a quad-Op-Amp and get a 8th order Butterworth filter up in there? What's the frequency of the aliased noise? Can you measure it on your oscilloscope?
-----------
I'm talking about basic "read sensor" and "blink them lights" projects. These are the things that come up in practice.
Code... sure. Reading the docs for how to run the various sensors (if I2C or SPI) may be tricky at times, but they "just work" more often than not. Physical issues (voltages, frequency, filters, and making your paint actually stick on the altoid can etc. etc.) are harder to debug.
And if I were to take a guess why your I2C "code" isn't working, I'd bet on a physical issue (ex: fanout, resistor choice, trace length, capacitance) over code issues, especially if you're using a plug and play library like Arduino's I2C or Rasp. Pi's I2C stuff.
I've got the complete opposite experience. Maybe the kind of stuff I work on is just different but that sounds like a lot of work that could have been avoided by cobbling together some reference designs and carefully reading PCB layout documentation.
With all the different reference designs, parts libraries, and open source projects available these days, spinning up a PCB design has never been faster and easier (I use Altium). My record for a nontrivial design is less than 12 hours from idea to fab+assembly order with an FPGA + Wifi referenced design grafted onto a gutted STM32F4discovery followed by ~30 hours troubleshooting the bringup and sending out a second revision. I don't think I've ever written and tested nontrivial firmware in that time frame.
Even in complex microprocessor boards where routing high speed signals (DDR3/4, MIPI2/3, etc) takes up 90% of the design time, the time spent faffing with BSPs and device drivers far outweighs design time.
I have had to try multiple libraries to get a basic humidity sensor working with an ESP8266.
I agree that the hardware will be the dominating factor long-term; but I do think you're underselling the the complexity on the software side, and that it can make a big difference to a newbie.
I wouldn't necessarily say that ESP8266 is a beginner-friendly board. Its a cheap board with WiFi capabilities, but not as beginner friendly as say Arudino (and clones), or STM-stuffs, or Rasp. Pi.
But I think most hobby projects are the type you're basically talking about:
1. Insert some combination of sensors onto a microcontroller board.
2. Loop over reading those sensors.
3. Very basic math / addition / etc. etc.
4. Turn on blinky-lights based off of the sensor readings. Or maybe WiFi / Bluetooth / RS232 UART / some other I/O to "publish" the results somewhere. Maybe a motor in some cases.
This general process covers the typical projects a hobbyist would do: "useless boxes", blinky, temperature sensor recorder, remote-control car/sumo bot, etc. etc.
I wouldn't say Arudino "just works". There are definitely decisions where you can "hang yourself" or "shoot yourself in the foot" if you don't know what you're doing. But I guess the physical-version of that is "literally overvolt your board and maybe something catches on fire". So making sure that the physical bits (voltage levels, current levels, etc. etc.) are all set requires a bit of thought.
Ex: Doing some PWM-controls on a 12V motor? Good job, if you forgot the flywheel diode, you're gonna see a fire pop up somewhere. To understand why requires understanding the underlying physics of a motor (inductance, dv/dt and di/dt), and how that interacts with pulse-width modulation.
Even if things aren't catching on fire, you can damage components by having inappropriate controls thought out along the electronics (think of the voltages associated with the back-EMF when that motor turns off).
Interesting! For me ESP8266/32 felt trivial to reach successful prototypes. With no prior experience it took me less than a week to create PoE temp/humidity monitors for a datacenter with Grafana and Prometheus.
In contrast I have stumbled quite a lot trying to learn the STM ecosystem. I find myself really wishing for someone to work with to help me get past the initial startup hurdles so I can be more productive.
I'm having trouble finding the actual code for the demos included in the STM3210C-EVAL or STM3220G-EVAL, or tutorials for making use of the myriad peripherals included on the boards.
Heh, I guess a lot of it is up to personal tastes.
STM's documents seem very through, and when I use STM boards they seem to follow the docs without much issue. I usually use classic Arduino, or maybe the ATMega328pb directly, because I prefer 5V compatibility. But I don't recall any issues with STM last time I used them.
Rasp. Pi doesn't have much low-level stuff, but the board is so overpowered that you can manage to bit-bang stuff at lol Python levels and still get many things done. Its not my go-to tool because again: 5V preference, as well as timers / ADC aren't as capable as other chips.
But ATMega328pb / Arduino is a really nice starting point. You got the Arduino high level library, and a very short ATMega328pb document (well... short for chip level documents anyway. Still hundreds of pages, but its not like 1000s of pages like ARM stuffs)
-------
I'll admit to using the simplest STM F0 (ARM M0+) boards, which are trying to be ATMega328pb level in terms of complexity. STM has many, many boards of many capabilities and levels of complexity. Its a very big family. So my experiences with STM F0 stuff probably don't apply to everybody.
In my experience, ESP8266 development doesn't rely very much on the datasheet. Thats because there is a large community around one or two chips, and therefore a single driver implementation is good enough for everybody to write high level code on top of. There's little to no register interaction, and no need to look up how the peripherals work. There's no ARM Cortex I can think of that has this development style.
Visual Studio Code with rust-analyzer and probe-run give you the same turn key experience as Arduino except on a more professional level. Flash your devices with a simple “cargo run” command and see log messages magically appear from your microcontroller in your console. The STM32 line of microcontroller or nordic’s nRF52 boards are well supported. These are 32 bit microcontrollers rather than the 8 bit microcontrollers you get for Arduino.
How does the code size compare with a traditionnal C approach? The book website mentions using STM32 which usually have plenty of space (64-512kB). How well would it work for say, an ATtiny with 2-8kB of program space?
It's not much appreciated, but the Microbit V1 is an nRF51 and the V2 is an nRF52. Download the SDK from Nordic Semi [0], grab a copy of ARM GCC[1] or Segger IDE [2] (free for nRF5x, complete with drag'n'drop firmware upload [2a]) and you have a powerful Bluetooth LE/2.4GHz radio/LED blinky development environment (whatever platform you're on).
The Seeeduino XIAO discussed in the article is a ARM M0+.
The STM32F4 is a ARM M4, a higher-end ARM. There's a lot of different chips and chip categories at this level.
Ultimately, the CPU doesn't really matter in physical projects. Mundane issues like voltage support, ADC converters and timers dominate the issues you come across.
Personally I do not like Arduino (and its IDE) because it hides many complex things under cover. But, really good thing about it is that programming microcontrollers like this teaches you to keep your code lean, worshipping any single byte of memory you have left, counting any single tick of your clock. I wish all software developers would begin their careers by programming MCUs to work out proper habbits. :-)
This is actually the thing I like about Arduino. This is what made it accessible to folks who didn’t have any programming experience artists, experimenters, students.
There is a lot to be said for coding at the metal, but accessibility holds greater value for me.
That said, you also can skip most of the Arduino stuff even if you are using the platform.
Getting started with microcontrollers is a breeze today, so many good resources, ready add-on components, controllers that support high-level language, etc. My first controller was a PIC which you programmed in assembly language, then AVR/Atmel Atmega, which could luckily be programmed in C. Probably my favorite class in college too.
But from a hobbyist standpoint - if you want to build cool stuff that you're going to use, I'd probably go for something which has a more rapid development process than the older cards. MCUs are GREAT for learning applied/hands-on electronics, while also getting a small crash-course in computer architecture, but unless you're super motivated, and like to spend time on shopping for parts, it kind of becomes a chore to roll out everything on your own.
That's a good one, and it's an 8051 core, which is incredibly widely used. So there are lot's of 3rd party tools & tutorials. And there are 8051 cores hanging out in all sorts of places, so it's useful knowledge.
indeed should have pointed out its the classic 8051 with a crazy clockspeed to compensate.
silabs simplicity studio is the only out of the box eclipse based IDE available for 8 bitters that i know of as well. i believe this is covered in jay carlsons amazing $1 mcu writeup. which is also good details for someone curious from this article
( https://news.ycombinator.com/item?id=19851744 )
Well, that's kinda where 8051s get weird (not by a stretch the only way it's weird). 8051 performance is more '2 dimensional' in the sense it relies on clock speed as well as instructions-per-tick.
The 'classic' 8051 is (over simplifying) a 12-clock ticks per instruction processor. So you pretty quick had the second source providers introducing 6-clock and eventually 1-clock per instruction variants, with commiserate increases in speed. And then they jacked the clock speed.
So now you have '100 MIPS' 8051s, running at high clock speeds and 1-cycle per instruction.
After 8 years of working throughout Europe as a web developer and a burnout, I’ve gone back to my EE roots to designing embedded systems with Rust and hardware.
Honestly, I love it. It’s more cognitively challenging, and I really like bridging the worlds between digital and physical.
It’s fun getting flashbacks to University where I was studying the saturation points of a NPN BJT, using capacitors as LPF’s for analogue circuitry etc
Microcontroller courses in college were some of my favorites in college as you got to build something that actually moved and effected the world beyond a screen.
I tried hard to get a job doing anything with them when I first graduated. Sadly I got few replies, and I was often told I needed an EE not a CS to work with them.
Are there any useful embedded projects? With very basic app dev or web dev skills, I can easily hack together a somewhat useful project - useful as in used by real people, solving an actual problem. Is that a thing in embedded dev?
I'm do hardware/firmware/embedded engineering professionally, but I also like to tinker and follow the electronics hobbyist community for fun (stuff on hackaday and "electronics twitter" is usually more interesting than stuff on eetimes).
2. IoT stuff (e.g. some appliance that I have does some stupid/annoying thing, and I just want to build a one-off gadget to work around it; I don't trust cloud IoT devices and want to build my own; etc.)
3. Specialized hobby things (e.g. I have a hobby shop metal lathe and want to build an electronic leadscrew for it (https://github.com/clough42/electronic-leadscrew), DIY radio-control airplanes, drones, autopilots, etc.)
It's generally a lot harder to "solve a problem" with DIY electronics and then sell it as a useful product with broad appeal, like you often see in Silicon Valley with apps and SaaS webapps. Going from small prototype runs to any sort of mass production can be surprisingly difficult. There are often large step costs with their own engineering intricacies (e.g. 3d printed enclosure --> injection molded enclosure). Regulatory compliance (FCC, CE, UL, etc.) is a soul-destroying pain in the ass. Etc.
Probably 80%+ of embedded projects involve reading some sensors and doing something conditional with the output, either sending data somewhere or controlling an actuator. That's a very broad definition, but an awful lot of (frankly poorly made) hardware you can buy does that.
The main difference is that scaling/selling embedded stuff is a lot more difficult than throwing up a website that anyone can view or `git clone`. In principle you can release all your schematics as open source (and if you can, you should), but unless you're going to start manufacturing your widget, people will have to physically build it themselves. That's a fairly high bar, but take a look at the success of Adafruit and Sparkfun - DIY kits are perennially popular.
Also have a look at Tindie, where people sell their own projects.
The sweet spot for hobbyist electronics is building niche things that would normally be extremely expensive to buy off the shelf because there is no economy of scale. Once you understand how to glue things together (with digital electronics), a lot of things become possible. I'm currently working on a daylight-simulating alarm clock, because the off-the-shelf stuff is very expensive for what amounts to a dimmable lamp in a box (even when you go down the route of sourcing quality, high-CRI LEDs with cool-warm dimming, etc).
I have a side business selling an electronic gizmo. I sell a few per week at roughly 100 bucks a pop. I pretty much followed the mainstream advice on how to find a startup idea, such as finding a problem that you care about, and that other people experience as well. I didn't do anything brilliant. Of course this is not a "startup" by the contemporary definition, but a solid little lifestyle business that I enjoy.
I believe a difference is that it's easy to gain the domain knowledge needed to create a basic software project, assuming you've gotten over the "hump" of learning how to code. And at least for smaller projects, operations and distribution are pretty much solved problems. In other words, all of the reasons why software has eaten the world.
Hacking hardware necessarily involves moving and transforming physical material. I happen to have that domain knowledge in hardware thanks to my day job, but the starting point is to first get interested in it.
Yes, most certainly. Development boards like the Arduino suite, Adafruit Feather series, various ESP32 / ESP8266 boards and even the Raspberry Pi Pico makes it really easy to whip together a simple (or more complex for that matter) project at low cost and with little effort.
Add to that cheap PCB professional manufacturing, and the world is your oyster.
Some of the projects I have recently completed include:
- A door strike interface with RFID input that allows me to use my condo entrance FOB to open my apartment door.
- A custom sous-vide controller at 1/10th the price of a commercial one
- A secure hardware password manager.
- A cheap sensing unit installed in every room that measures light level, environmentals and presence, and communicates with my home automation system to adjust heat, cooling and light levels automatically throughout the day.
Currently working on a remote ePaper notice board with updates through LoRa. As I said, the possibilities are endless and it is really easy to hack something together with the tools that are available these days.
I've wanted to do something similar to your project of having a sensing unit in each room, or at least each level, of my townhouse. What do you use as the "presence" sensor? PIR?
I'm building a prototype water level sensor for my 30,000 litre tanks. Ultrasonic sensor to find the water level and an embedded web server to surface it (in my case it's near enough to my house to use my home Wifi - I'm publishing it as a Prometheus scrape target, but could easily be a website). When it's a bit more polished I will ask my neighbours if they're interested (we're all on tank water). I don't plan to make a profit but it would expand my skillset.
If you are just doing this for fun then have fun. If you want to commercialize it at all you most likely want it to communicate via MQTT not a scrape target. MQTT has much wider support for additional intergenerations.
I’d say yes, but with more work, non-zero startup costs, and not easily scalable for a hobbyist. Interacting with the physical world is the whole point, but it means you can’t just copy/share/publish a digital file and solve the problem for someone else.
As an example (which it’s debatable if you’d consider it “useful”), I was able to build USB adapters for vintage game controllers. It was a fun project, and I used the results for a while.
Espressif chips are excellent for making projects that work well, but it's a bit harder to recommend them for education.
It's tough to get truly "bare metal" code running on their chips once you want to dig more deeply into how things work. Everything is based around their development framework, which is open-source and quite easy to use, but somewhat difficult to read.
Part of why people like the Arduino ecosystem is that it supports a wide variety of platforms, many of which have excellent documentation and register-level example code.
But at the end of the day, the best way to learn about microcontrollers is to grab the first one you can find and treat it like a toy. Have fun!
One of my recent projects was a robot using a LILYGO T-Display module running MicroPython. I'm going to use them in "Build a Drawbot" workshops at our local Makerspace. The previous version used an Arduno running TinyBasic. I think Python and Wifi capability will make it a little more accessible.
Not sure if I would recommend building a career in embedded but you will start learning transferable skills doing it in your free time.