Depends on what you’re doing I guess. I finished writing my first Linux driver recently. A character device that interfaces with an FPGA via PCIe. No assembly language required. The Linux Device Driver book gave more than enough of an overview of PCI to understand what to do without reading the PCIe spec. Like anything you have to do deep dives when needed. I ended up having to learn a bit about the encoding and overhead of data sent on the PCIe bus when we were trying to understand some bandwidth issues we were having. I’ve done a decent bit of embedded work. You’re more likely to have the data sheets for the device you’re working on printed out and marked up than you are the spec for whatever bus the device uses.
> The Linux Device Driver book gave more than enough of an overview of PCI to understand what to do without reading the PCIe spec.
This book comes up a lot for the topic but is it still good? My understanding is that it’s for a rather old kernel version. And I’ve had drivers that couldn’t even compile between minor version differences in the target vs the kernel I was on.
I work on software for a product used mainly on fighter jets. I just fell into the industry.
The main barrier to entry is to know C. I don't mean that you've written a few basic programs in it, or had a one semester class with it. You need to know C front and back. Be able to identify undefined behavior, complete large programs unsupervised. Several people I work with keep copies of the ISO standard at their desk.
Most of the people I work with have an education in computer engineering, but my background is in CS and math.
Embedded programming isn't really difficult as long as you're using it appropriately. I wouldn't want to use a micro-controller to do a bunch of heavy math, but they're easy to work with basic peripherals that communicate over I2C and SPI. It's actually fairly fun to work on that stuff.
As far as your dream of working on software checked for correctness. I don't know what industry that would be. Military software doesn't have to meet the requirements set by the FAA (civilian stuff). Most do require you to code "towards" DO-178, but there's no CA.
MISRA and JPL guidelines are things that can mostly be checked by PC-Lint and the like. They will help you catch corner cases of writing bad C code. They won't make the code correct.
DO-178 tends to remind me of ISO-9001. They do mandate a few programming practices, but largely you write a set of documents about how you intend to write software, and you make sure you produce artifacts showing you followed your procedures. It doesn't actually verify the correctness of code.
The one thing that I have been amazed about is traceability. It's the one thing mandated by DO-178 that appears to work, and work incredibly well. I think more than any other aspect it traceability explains the excellent track record of avionics software.
We of course do everything we can to make sure the code is correct. I think more than anything, working in this industry creates a company culture of safety. That culture allows for schedules with a proper chunk of time put in for making sure the software is quality.
My advice for getting into the industry would be to learn C really well. Demonstrably well. Grab an dev board for a micro and do a basic project. Then apply to jobs at all the major defense industry contractors. You might not be working on aerospace the first few years, but it'll be a stepping stone to getting your foot in the door.
I'd suggest reading a book on writing safety-critical software before you go too far. Just to make sure it's something you really want to do. I think you'll find the book spends much more time explaining how to write required CYA documents than it does giving you advice on how to write highly-reliable software.
I was happy reading your points about C. C is the language I feel the most at home with. In fact, I was working with C for most of my career - I only moved to higher level languages in the past 3 years of my career. So the things you mentioned I should be familiar with, like undefined behavior, are - or were :( - my arena.
I'm surprised that apparently the rigor applied to this kind of software doesn't seem as hard as I had imagined. I had always pictured code in the defense industry being heavily scrutinized, proved and whatnot. But I'm still excited about the idea of having to conform to certain standards.
> That culture allows for schedules with a proper chunk of time put in for making sure the software is quality.
