Want to Learn Programming and Microcontrollers?(eejournal.com) |
Want to Learn Programming and Microcontrollers?(eejournal.com) |
Not sure if I would recommend building a career in embedded but you will start learning transferable skills doing it in your free time.
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.
Sorry for the wall of text, hope to hear back!
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.
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.
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.
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.
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.
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.
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.
[0] https://www.st.com/en/evaluation-tools/nucleo-f401re.html
https://github.com/atsamd-rs/atsamd
I have at least managed to get some literal blinkenlights doing what I want on various Adafruit boards with very little effort.
[0] https://www.nordicsemi.com/Software-and-tools/Software/nRF5-...
[1] https://developer.arm.com/tools-and-software/open-source-sof...
[2] https://www.segger.com/products/development-tools/embedded-s...
[2a]https://www.segger.com/products/debug-probes/j-link/models/o...
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.
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.
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.
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 )
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.
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!
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.
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 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.
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.
And of course, there’s a book: https://docs.rust-embedded.org/book/
I feel like I should also mention that I tried some bare metal embedded Rust about 2 1/2 years ago and didn't get anywhere with it.
Now I try and there's support for quite a few boards, and it's easy to get started with them. (good CLI tools, etc.)
I have the impression that the Rust ecosystem and community have progressed very rapidly in the embedded direction, and in short time.
The three biggest categories that I see are:
1. Toys/novelties (i.e. blinking/flashing things, simple robots, audio/music gadgets, etc.)
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.
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.
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.
The problem solved I suppose was developing an interest in programming.
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.
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.
Can you expound on that?
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).
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.
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.