Funny that you needed to use microservices as the base analogy for embedded MCUs. It illustrates how large the gaps are between hardware engineering, software engineering, and programming, compared to when I entered the field in the 80's. It was possible for one person to have principal-level knowledge in all three fields. The 90's broke that.
There’s a huge gap but at the same time, each layer is still very similar to each other.
Hardware engineering might be floor 1 of a building and microservices might be floor 19. Yes, they are very far apart, but one day, you realize that every floor has a bathroom. When you go down to floor 1, you might not know where the bathroom is but you know that it exists and how it will probably function. You are already 80% of the way there.
My friend owns his grandfather's "engineering encyclopedia" from the era before WWI. At that time it was possible (and expected) for a single person to have principal-level knowledge in the whole field of "engineering".
"The Network Information Service (NIS) was formerly known as Sun Yellow Pages (YP). The functionality of the two remains the same; only the name has changed. The name Yellow Pages is a registered trademark in the United Kingdom of British Telecommunications PLC, and cannot be used without permission."
Nowadays peripheral ICs are usually accessed over SPI, I2C, onboard USB, or some other indirect method. It is common for complex devices to have a micro on the other side handling I/O requests rather than spilling their guts to the world. That "other micro" could also be a full blown multi-core processor with an MMU running at hundreds of MHz and beyond. The difference back then is that parallel bus interfaces were king and custom ASICs couldn't necessarily afford the gate overhead of an embedded micro at all.
That's funny. I've been doing full-stack embedded development (bootloader assembly all the way to touchscreen UIs) for 30 years but the idea of trying to learn modern web front end scares the hell out of me.
React? Angular? Node? What happened to Notepad and Apache?
That ecosystem used to suck heavily as of 3-5 years ago, but I know it's improving. But you still need Node and a bunch of shit running underneath to glue the UI to the drivers.
As much as I'm starting to hate Qt, I can still have it up and taking to hardware in a few minutes. And the onscreen touchscreen keyboard is worth the money.
One of the devices I’m working on had to use rust (we were looking for some niche libraries, and we found that the C ones weren’t working, while the Rust ones did).
Building GUIs in rust is still a WIP, and I had to spend 2-3 days fixing libs and tweeking stuff to get to something that compiled but was very buggy.
Instead of losing more time on that I set chromium + apache on the thing, and built the GUI as a web app. The rust executable has a simple API with actix that works flawlessly.
In that case it was the perfect solution because I had to add an API for remote management anyway, but I found the approach quite nice to work with.
I can get a decently functional UI app working in native code with just the SDK for whatever platform it’s on, but try to use React and suddenly I’ve got a web of 200 dependencies, each more shady than the last. And that’s just for “hello, world”
Plus the JavaScript engine is single-threaded and insanely slow.. it’s gross. I’m guessing that one of these days app developers are collectively going to snap out of it and throw Node in the trash
As single-board devices get faster and cheaper by the week there's a flood of developers that have cut their teeth on Node/JS/React and they get something working on a Raspberry Pi and think "Yeah, embedded development is a piece of cake. I can do this."
And maybe they're right, because doing it all by scratch and cobbling together robot parts to make a system work is just really getting to be old.
I used to get annoyed at the RPi newbies but now I welcome it as job security because someone still needs to write the bootloader and drivers. And if you read StackOverflow/Reddit you'll see there's nobody teaching that anymore.
Man, I kinda feel like embedded software is doomed. There are only a dozen or so companies where embedded software is a first-tier product for them that gets a lot of resources put into it. It feels like everything is moving toward using super low-quality Chinese drivers/firmware and really badly-designed microkernels (or treating linux like a microkernel) to squeeze all the functionality out of the OS and into bad managed software stacks.
Then again, any company that takes firmware engineering seriously can make devices 5+ years before Moore's Law makes it feasible for others, so maybe there'll always be room for us.
It feels like everything is moving toward using super low-quality Chinese drivers/firmware
You must be a Broadcom user. My sympathies. =)
But I totally hear you. I'm not as pessimistic because I tend to follow parts that the automotive sector uses (yeah, not great right now) and they typically don't put up with random Chinesium parts and code. And yeah, it seems more and more like everyone is just throwing Linux into the mix and hoping that some OSS developer and/or Otavio Salvador swoops in and fixes things up.
RISC-V may be a way out of this. Maybe. Or it will make things ten times worse.
Notepad and Apache are still present and working. Probably not a good choice for a payment processing single page online store, but fine for a simple informational website.
Strong disagree. I do embedded development of varying complexity. I often have to learn and figure out new things, but once I have something figured out, I have it figured out, and I can drill down to hardware register level to figure things out when something is misbehaving.
Every single time I touch anything web-related I discover that the entire landscape has shifted, all the tools I used last time are now abandonware, and I have to figure out everything anew. It may be more accessible if you're starting from scratch, but it's a constant treadmill that you instantly fall off of as soon as you do anything else. And when something doesn't work? Good luck finding out what's happening in the countless layers on top of layers on top of layers.
Maybe it's just me. Vendor documentation in hardware tends to be kinda crap but there's usually plenty of other sources for information from other people who implemented something using the part, and that information doesn't get stale, ever, and documentation state improves over time. I've had problems finding reliable info on what's going on in webdev, most posts are "do this" solutions which don't really help you understand what is happening under the hood, and there are countless crappy tutorials. To be fair, I'm an extreme case, I touch web stuff once every few years, and only if there's really no way around it, and a lot happens in browser capabilities and javascript in a few years.
> but there's usually plenty of other sources for information from other people who implemented something using the part
That’s only the case if you use the small (tiny!) subset of parts that everyone uses.
If instead of using some nice and common stm32FXX MCU, you need to work with some obscure Renesas or Fujitsu for example, prepare for a world of pain.
The good thing with web stuff is that you can swap frameworks until one does what you want nicely, and leave it at that. You can’t really change the IC in your board just because the I2C module is doing something weird.
I use obscure parts. For example, just this month I've used a part that the manufacturer doesn't admit exists on their website, and a part where the manufacturer doesn't even have a website, and neither is anything widely used. But there's always a small community of people who use the part, and we cling to each other and compare notes vigorously.
Web APIs are most of the time just added, rarely removed or changed. If you ignore all the frameworks and libraries from random celebrities on github and all the FOMO on not updating them constantly, the base platform is quite solid and versatile enough.
> all the tools I used last time are now abandonware
I think you are exeggarating. Over last few years, there were no hard deprecations, except for AngularJS. Many tools, popular in past, went "maintanence mode" and receive mostly bug fixes, but these tools are still viable.
I'd certainly think so.
I almost did.
I initially learned Java on my own.
It's good to know at least one full programming language before diving into embedded programming, I think.
Then got into Arduino programming. There are tutorials for that online. Try communicating with other Chips like a Shift-Register, then something that uses a standard serial protocol (ex. I²C).
When you feel like you have a good grasp of the basics, I recommend getting a development board and doing the same there.
Most Microcontrollers (ARM Cortex Processors at least) are pretty similar:
You get a datasheet and a User's Manual.
The User's Manual describes a bunch memory addresses, which control the built-in peripherals.
There are excellent descriptions of what value will give you what result, but it can be a bit daunting to get your head around it at first.
I recommend a chip that has a so called "Board support Package". I have experience with LPCOPEN.
This will make things a bit easier, as you don't have to figure out each register address for each thing and can instead use functions like "Chip_TIMER_Enable(timer_t timer)".
There is a lot more to it, but once you get started, you usually always see the next step.
I self-taught enough to design and build a working PCB (that passed a bunch of certification testing), including writing programs for an ARM Cortex microcontroller. Took about six months of learning and then a couple months of design/implementation to get a product that can be sold and have the fundamentals in place to make similar kinds of products much more rapidly.
It's very doable with dedicated study and I'd argue it's one of the best ways to get your design ability to rise to the level of being able to build something from scratch, without reference to other code / searching google for answers.
My strategy has been to get into 80s game consoles where assembly programming was expected but the platform is small and standard enough that I can use emulators with memory views/debuggers & see everything going on.
Nice, I'd like to do this too. Which console would you recommend starting with? I'd love to see an old timey programming manual and emulators for that platform. I've heard good things about Nintendo consoles, but I don't know where to start.
I think nintendo consoles, by virtue of being the most popular of the era, and therefore the most nostalgia, have probably the best debugging/tools of the lot. Personally I'm not a fan of the 6502 as a general-purpose CPU, but it's just fine for single-tasking games and global variables (there's almost no stack space).
I'm starting out on z80 since I have an MSX and I hope to move to Sega Megadrive/Genesis later since I hear nothing but good things about the motorola 68k. The z80 seems pretty easy to understand (though it's not always consistent).
It's worth checking the limitations of the video and sound hardware to see what you like as well. I'm partial to FM synthesis so Sega consoles make sense to me. 8-bit stuff is going to land you with really tough colour restrictions (often about 3 per 8x8 square, tops). You may want to start with the "16-bit" era, which generally used 4-bit colours (16 for the whole screen, easier to create assets for).
I personally like to compare it to building houses.
Programming is laying the bricks, the cables, etc. Basically doing the actual building.
Software engineering as in other engineering disciplines is more concerned with making sure everything actually works and fulfills certain standards of quality. The planning, design and architecture part of the work.
For the last decades the person doing the programming and engineering were usually the same, but they are more and more drifting apart with more engineering focused roles like software architect.
In much of the world engineer is also a protected title that requires formal education like with doctors or lawyers. The US is using it pretty inflationary.
Shades of the 1980s and prior decades! In the 1980s, I worked in the aerospace division of a Fortune 5 company. A headhunter called me up, was chatting, and asked me what I did. I said I was a "programmer". Silence on the other end and then, "Are there any people who design programs there?" "Umm, yeah, we all do." I was book-aware of this distinction in previous decades, but this was the first time I had encountered it in the real world (of a headhunter). I see that we "programmers" are still regarded as being like the streetsweepers in Victorian London, sweeping out a path in the manure and mud for the software engineers! :) (We had software architects back then.)
There’s no line. Programming a a strict subset of, and is much smaller than, software engineering. Communication, technical writing, customer and stakeholder management, system design, technology awareness and many, many more are what make a software engineer in addition to programming.
Software engineering has a higher level view which is more concerned about the architecture of the whole system.
Programming is more concerned how it's implemented on the specific hardware/language, and how its limitations and advantages play a role in the implementation.
You can know both, they intersect in a lot of places but, programming goes deeper, and software engineering goes higher.
That's a reasonable way to look at it, but there is a missing component. In the early 1990s, I was a subcontractor at a large firm which had software people who were only interested in designing software, down to a medium-level pseudocode, after which the design was handed off to coders. These designers were great people, but, on this project, none of the firm's designers and coders had hands-on knowledge of and experience with the hardware and operating system (an early version of VxWorks). The coders would gain this knowledge and experience from writing and testing the software, but not so the designers.
My missing component was that there was no mind-to-mind feedback loop conveying this knowledge and experience gained by the coders back to the designers, from which it would inform the designers' future designs. (And there was no regular feedback about how well the design fit the problem and if the design required radical changes during coding and testing, although some of that is more an administrative concern than a technical one.) The "coders", by the way, were quite capable of designing their own programs - and did. I don't know why the firm had this subset of design-only'ers; they were smart and maybe the firm wanted to hang on to them and maybe "coding" roles were intended for brand new employees.
I don't know if you can really make the distinction, is anyone actually hired as a "programmer" instead of an "engineer"?
I feel like developer is the best name for what we do, it doesn't limit us to the act of coding and it doesn't make the presumption we're engineers (very few of us actually are).
Then again if I could choose I'd probably prefer computer programmer, it doesn't get confused with property developer and pretty specifically covers what we do.
Competent interns and other skilled juniors are usually good programmers but lack all the business acumen to be good engineers. This can’t really be taught in a curriculum, because it’s something that needs to be internalized by practice.
Kind of disagree, I haven't really needed to learn much about business other than what I picked up in a couple of business papers at uni, there just isn't much to learn about business systems as far as building software is concerned.
Any good degree should be covering all the software lifecycle stuff and general information systems as a concept.
I guess there are definitely people out there that have no interest in the business side of things but I think theyre outliers.
But now that I think about it maybe I'm wrong, I know a lot of business product people and even other developers just assume I don't know anything about business. At least that's what's happened now working for an American company. Working for Aussie companies it's just assumed that were sort of business analysts as well.
