Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Would love to see a roadmap added for embedded development or system level programming etc. There is a huge emphasis on "the web" when it comes to software engineering, that people forget (especially college students figuring out a career path), that there are many jobs in defence, hardware companies, etc. that develop software without using any web technologies at all.


I could condense that down to a single task that will get you 90% of the way there: Learn how to bit-bang a serial interface on two different microcontroller platforms.


Claiming a serial interface task will equip you with 90% of Embedded Systems is the biggest disrespect of a profession I've ever encountered. To outsiders, the field might be regarded to be just a microcontroller playground. But the spectrum of hardware design and programming in the field is at an unprecedented levels. PCB design, power supply, SoCs, SBCs, FPGAs, peripheral interfaces, Embedded C and Linux software development...to mention but a few; are some of the skills a modern embedded system engineer needs at the lower level.


Well, yes and no. Depends a lot on whether you want to do the "full stack" or not there. Lots of bigger companies have EEs to do the PCB, power supply, pinmux, etc stuff, and then embedded software people to write the code that runs on it. An embedded software developer probably should be comfortable using an oscilloscope/logic analyzer in a pinch, but all of the hardware design tasks aren't necessarily required for doing embedded software work.

I say this all as a "full stack" embedded guy. I'd love to have someone else take on part of it, but I'm a solo consultant right now :). Did both EE and CS in school, and more than happy to do whole projects end-to-end, but I also don't expect EEs to be fantastic programmers, or embedded software people to be fantastic hardware designers.


I interpreted the parent comment as do all of the parts yourself. Pick microcontrollers, design the PCB with power supply, find the right toolchain for both microcontrollers and implement serial communication. Which is almost 90% percent of the job.

Also, does FPGA come to mind when embedded is mentioned? I always assume that FPGA is a whole another subject (only FPGA not the board part).


> always assume that FPGA is a whole another subject

This has been my assumption as well. I looked a while back at learning FPGA development because it seemed rather interesting, but quickly decided to go another route after seeing and talking to some FPGA guys. From what I saw it does not in any way resemble what I'm used to as a software developer


This is an overreaction, and really not a very nice way to interact with people.

I was talking about embedded development which doesn't really have anything to do with PCB design, power, FPGA, etc. You don't need those things to be a programmer working on embedded systems or microcontrollers.

Implementing a serial interface in software flipping GPIOs up and down will expose you to a whole lot of the necessary ecosystem and if you can do it, you're well past the point where you should be able to get paid to do it and the point where you need a roadmap to tell you where to expand your skills. I didn't say doing it would get you a senior level position or a masters degree in EE.


What exactly qualifies as a web technology? Isn't anything on an IP address a web technology?


Web != internet.

HTTP, HTML, CSS, JavaScript, etc are web technologies.

TCP/IP (among other things) are internet technologies.

Web tech builds upon internet tech.


Yeah, in my OP I was meaning the WWW specifically, so the things developed for use with the WWW (HTML, CSS, HTTP, etc.) Networking (TCP/IP, UDP, etc.) are not WWW specific.

Now having said that, sure I've seen some defence projects that make use of HTTP or have internal "web"sites for managing interfaces. It's even a trend for embedded hardware to have web management interfaces (your internet router/modem is a great example).

But when I say "web", of course I was really meaning user-facing/world facing websites. That seems to be the implication behind "front end developer". Not "I make front ends for building automation systems" but "I make front ends for websites hosted on the WWW". Requires a slightly different set of knowledge imo. One is tailored for looks and UX, the other is a trade-off between minimalism, efficiency, and usability (if only this was applied more to the major sites you see on the WWW now!).


Semantics, but JavaScript itself is not a "web technology" - despite being conceived for the purpose of web scripting the original publication for version 1 even calls out that the language can be used on a variety of host environments (not limited to browsers). This can largely be seen in host environments like Node.js where it acts like any other similar language.


By that logic, CSS is not a web technology because it can also be used in GUI toolkits like GTK[1]. HTML is used in ePUB files[2], so I guess it's not a web technology either...

Would protocols that use HTTP for transport like gRPC[3] mean that HTTP is not a web technology either? I don't know what is a web technology anymore...

[1] https://developer.gnome.org/gtk3/stable/chap-css-overview.ht...

[2] https://en.wikipedia.org/wiki/EPUB

[3] https://en.wikipedia.org/wiki/GRPC


Only if it’s also using the Web.


Disagree. Electron apps are built w/ web tech regardless of how they're distributed or connected at runtime.


The assertion was that IP address = Web.


IMAP, SMTP, FTP, NFS, IRC, and lots of other networking protocols use IP addresses but aren't web technologies.


I am interested in this too. I am trying actually to start embedded development for a specific platform, but it's hard to understand where is a good starting point even as experienced software developer.


This is a generalized 2cents, but: Go around online looking for any and every job post you can find in that space. Tally up what is most common to what is least common. Bonus points for profiling into subgroups of common requirements.

As someone who has quite a bit of experience as a systems level engineer, who has written code for custom hardware, but is not a firmware engineer (in other words, grain of salt here): Knowing C (or C++) well enough to be able to write threaded code is super important, for not all but many jobs. (Or at least know the concepts, eg the different kinds of atomics.) Knowing I²C or similar is a good idea. Knowing or dipping your toes into DSP can be helpful. Know at least mean squared error, and how to do a bandpass. And bonus points (though very few people in the embedded space know it) is learn Rust. It will teach you good programming practices that most firmware engineers do not know. Many of them are stuck bug testing run time errors day in and day out, instead of letting the compiler do it for them. (Again, 2 cents on all of this. Best to get actual requirements from job posts.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: