Embedded Systems – Shape the World (2014)(users.ece.utexas.edu) |
Embedded Systems – Shape the World (2014)(users.ece.utexas.edu) |
It's great in many ways, and free-to-cheap which is a particularly nice quality in a textbook, but it is _quite_ out of date at this point: it's tied to the old "ARM Compiler v5" bespoke compiler rather than the "v6" LLVM-derived one, and even Keil doesn't ship with v5 anymore. v5 used a different assembly syntax (v6 is GNU style, being LLVM derived - fortunately the toolchain can still ingest v5 style assembly _files_ just not inline so we can keep the assembly the students interact with matching the book), different tooling for C/Assembly interop, and an assemblage of bespoke macros and extensions, so there has been some creative tooling work to keep the book and assignments consistent for the students.
The EK-TM4C123GXL TivaC board that is the less expensive of the two targets the Valvano materials are built around is a pretty nice if slightly expensive embedded trainer, about $20-25 for a Cortex M4F with a fairly rich assortment of peripherals, a 2nd micro configured as a programmer/in system debugger on one end of the board, easy-to-interface male AND female headers on a bunch of broken out pins, pads to tap the USB-Serial traffic while it still looks like serial, high and low speed oscillators arbitrated by a pretty fancy clock circuit, two user buttons, and an RGB LED. Powerful enough and with enough Flash and RAM to get interesting things done, not so powerful or memory rich that you can get away with modern programming decadence, and simple enough that we can talk about the nuts and bolts of any particular feature.
We construct from "Baby's first assembly program" through "Register-direct manipulation" and finally "Controlling external devices via the HAL functions" over the course of a semester. Because of the way the degree programs are structured, we're a little more focused on "This is how computers actually work" than on embedded applications, but I'm still pretty proud of the course and the students mostly seem to appreciate it.
Not in Europe. Since FAANG level jobs aren't that numerous here compared to US so the difference between embedded and non-embedded work is close to zero. Pay is pretty similar.
Add sure, but if your only target in life is working for FAANG & Co. then every other tech job in the world pays very little.
You might as well also not want to be a doctor, teacher, lawyer, as well because hey, FAANG pays better. Everyone should abandon their passions and career dreams and become devs for FAANGs because pay is everything that matters in a career.
It's mostly a question of finding a company where the embedded software isn't an afterthought.
As opposed to the absolute perfection that is modern web, enterprise and mobile SW?
>But it's all fine as it shaves a few cents from the BOM.
Every engineering job, including SW development, works to reduce material costs and automate away other jobs. Why do you feel embedded development is somehow worse here?
Completely incomparable to web, enterprise and mobile (android and co is a part of the embedded trashfire of course). They all have their problems but are minor league compared to embedded development hell.
Embedded development takes BoM reduction to the extreme and piles all the technical debt onto software.
and a simple number is a very easy bludgeon to wield in discussions about engineering choices
EEs are IMHO underpaid in both sides of the pond though.
I worked on telephones for the hard of hearing, and we had some remote developers. No problem.
On the other hand, there are embedded systems that are for 3D printing spaceship hulls. I kind of suspect that remote isn't going to fly for working on those systems...
I work on devices bigger than a car and sure, occasionally I have to visit the 'office', but almost everything can be debugged and tested remotely.
Because of EEs in PRC and Taiwan with relatively speaking much lower salaries for about the same level of competency [who also have native-level access to the design/supply ecosystem over there].
Did you actually work in the embedded industry, or are you just venting on some bad experiences you had with some boards/phones?
You know, embedded is more than r-pi clones and android devices, right? It's auomotive, aerospace, industrial automation, healthcare, etc.
I cannot overestimate how mistaken you are but you seem to be already set in your ways, and have a bone to pick so I'll leave the conversation here to save my sanity as you can't be reasoned with nor is anyone's time worth it to convince you otherwise.
Also Linus' ARM rant for good measure: https://lkml.org/lkml/2012/7/15/133
And imagine the stuff they didn't upstream...I'm sure that's part of some magic SDK that only works on one version of glibc and kernel.
I don't consider e.g. Android phones to be embedded. A smartphone is much more like a small laptop. That being said, there is a sliding scale; e.g. car infotainment systems have properties of both embedded and non-embedded software.
The grass isn't greener on the other side of the fence.
For me my plan is to use Zephyr with RP2040.
I've been using Zephyr on an Atmel/Microchip SAMD21 for $WORK and it's been awesome.
I have an RP2040 sitting on my desk for a personal project and the plan was to use Zephyr for that as well, but it seems the WiFi is based around a binary blob and a weird interface to it that the Arduino BSP has wrappers for... It's been crunch time at work and I haven't gone back yet to see if the RP2040 port is coming along further, but on the Saturday I was looking at it, it seemed like connectivity was potentially going to be an issue for now.
ESP32 support is currently great for some chips and a WIP for other chips. I got unlucky and the one board I planned to use for a different project was pretty much completely unsupported, but I found a different one in my parts bin that only took about 4 hours to get going with the sensors I had planned on using (I2C or SPI, I don't recall), Bluetooth Central for some different sensors, and WiFi to connect it to the local network. It was really smooth!
Obviously there will always be some physical component to embedded development, but in many cases it is possible to do a lot remotely.