Hacker News Reader

Comment by InitialLastName | Hacker News Reader

What is it about C that you want to work with it so badly, despite having no experience with it? It's a great language for what it does, but the difficulty level for avoiding bad decisions is so high that I would be very hesitant to hire someone with no track record to operate solely in C.

I'd have been inclined to say embedded would be essentially your only option, but without some experience and/or an EE background, you'll have a very hard time finding your feet in that world.

View on HN

> without some experience and/or an EE background, you'll have a very hard time

Yep. We hire embedded people to write C (some of the time) but the critical qualification isn't C experience or even general programming skill. It's knowing what a multimeter, oscilloscope, and logic/protocol analyzer are and not being afraid to use them.

Are pure software jobs really that uncommon in the embedded world?

There's plenty of people who know how to write software. Not as many who know how to use an oscilloscope.

As far as the skill-gap, its a lot easier to train an EE signals dude to use C programming, than to teach a C programmer how to use an oscilloscope or otherwise do circuit theory.

For us it's less about the circuit theory stuff and more about the mindset needed to deal with first-spin brand-new totally-raw hardware. Anyone who's not comfortable checking up on the hardware will not be successful here. Training that kind of attitude is impossible, so you've got to filter for it somehow.

Fair.

In my experience, embedded work really isn't about C programming at all, and is more about understanding the device drivers / manuals. You _happen_ to be programming in C, but the real skillset is reading CPU-manuals or device manuals.

Its not "void foobar(int blah){}" that's hard to write. Its knowing how many cycles IO-pin B needs to be held low for.

Just a hobbyist here with ATMega328pb stuff and various 8052 stuff + some college-level student training. Not really a professional at this. But I figure the pros do similar kinds of work. And its really not the CPU-manuals that are hard (CPU manuals are often written clearly and relatively concisely). Its the various I2C boards and SPI boards that don't always function correctly that's the issue... and struggling through some incomplete / poorly written docs on that matter. (But you got like 10 spare parts you can experiment / blow up with. So its just a matter of playing with the darn thing until it works...)

-------

Asking for a C programmer would be like asking for a journalist who has "English Writing experience". Like... yeah, that's... expected. But that's not what you ask for. The skills they need are far beyond "just" C programming.

"CPU manuals are often written clearly and relatively concisely"

Not always haha. I've seen manuals for some very widely used ARM SoCs that are just a few hundred pages of registers with poorly translated, one sentence descriptions.

> Just a hobbyist here with ATMega328pb stuff and various 8052 stuff ... (CPU manuals are often written clearly and relatively concisely)

The manuals for CPUs that are frequently used by hobbyists are written clearly and concisely (decoding the causality to be left as an exercise for the reader). For many of the others (including a quorum of those priced for use at scale), you'd be lucky to get a document that's been machine-translated from x-ese, with an errata roughly the same size.

Exactly. If you're a nice, high-level developer, you probably think that GDB (or similar) sucks in comparison. You'd be wrong, but trust me, it's a hell of a lot better than the debugger for reality, which really sucks.

A lot of embedded C code looks like (to take some from an esoteric project I can share)

    void eurotherm902s_set_xs( unsigned int xs,  struct sp_port* port_choice )
    //Set the extension status word
    {
        char buf[8];
        assert( xs <= 0xFFFF );
        sprintf( buf, "XS>%04x", xs & 0xFFB7 );
        bvt3000_send_command( buf ,port_choice);
    }

This is not interesting, nor is it intelligent, nor is it (arguably) safe. It is, however, fast and functional and directly talks to the hardware. The difficulty in doing this isn't understanding what is going on in the code. It's in working out what the <bleep> is actually happening if you see the right blips on a logic analyser and nothing comes out the other end -- and that often touches on physics as well as EE and computing. I personally really like it, but it's much, much more frustrating as far as experiences go (at least compared to Stack Exchange and "apt install $magic_package_version" to solve your immediate problem)...

I can teach a programmer the basics of how to use a scope in 10 minutes. The basics of C for a non programmer would take what - a week minimum?

Every scope made in the last 20 years has an autoconfig/autoset button...

You ever deal with an Oscilloscope with a ground-loop problem?

You're not teaching electrical theory in 10 minutes. No sir, no way. I'm going to guess that it takes you more than 10 minutes to adequately explain what a ground loop is, even if the other guy is reasonably trained in electrical theory.

EDIT: Recognizing a ground-loop, understanding where it comes from (Oh, X device isn't grounded and my Y device ground is the Oscilloscope's ground right now), and finally solving it (switching to AC mode if you're cool with capacitive coupling).

And it can be rather dangerous / fire hazard / electrical hazard if you made a stupid choice (ex: connect X's ground to Y's ground. Are you sure there's no serious voltage difference here? After all, if there wasn't a voltage difference, you probably wouldn't be having a ground loop problem to begin with)

Any good references for learning how to use a scope and other equipment? I haven’t gotten around to cracking open TAoE [0], but I did pick up the “hands on lab” version [1] which looks promising. Any resources on getting familiar with test equipment would be appreciated.

This book from a parent post looks pretty good: Understanding Signals with the PropScope from the company Parallax [2] and it looks like there’s a bundled kit on Amazon.

[0] https://artofelectronics.net/

[1] https://www.cambridge.org/us/academic/subjects/physics/elect...

[2] https://www.jameco.com/Jameco/Products/ProdDS/2134871UsersMa...

If you're still at "learning to use an O-scope" stages of EE, you shouldn't be reading TAoE yet. TAoE is more about selection of proper components... such as figuring out if the 2N2222 BJT or the 2N3904 BJT is better for your particular circuit.

https://www.onsemi.com/pdf/datasheet/p2n2222a-d.pdf

https://www.mouser.com/datasheet/2/308/1/2N3904_D-1801586.pd...

They're both NPN type BJT transistors. There's a bit of knowledge you need to see the difference.

Anyway, when you're at the level where you're analyzing components like that and picking between them, that's when you're ready to read TAoE. I'd caution against jumping into it too early, there's just so much to learn before that textbook is relevant to you.

---------

I don't... really remember my 200-level classes. But there was at least one semester of rather boring, beginner level electronics. Just using OScopes, power-supplies, and shoving electricity into resistors, capacitors, inductors, diodes (etc. etc) and learning how to read / measure that stuff.

I think an older beginner book that teaches like, 555-timers and other simple circuits are what you need. As well as just a lot of lab time with an OScope + breadboard, debugging and groking, and understanding these already made designs.

Once you get a gist of how the common components work, then you are able to choose various components and make them work together yourself.

> There's plenty of people who know how to write software. Not as many who know how to use an oscilloscope.

As a software engineer who's been learning electronics in the last two years and now does know how to use an oscilloscope: Try it, it's not hard at all to get started, and very much fun.

I don't doubt it's fun. I did a Bachelors in CompSci but had a lot of fun in the few circuits / EE courses that were shared between the CompSci and CompEngg programs.

But sitting at home with an existing job, it's a lot easier to learn C than pick up an oscilloscope and some hardware to run it on. I can't exactly tear apart my home appliances as easily as I can write throwaway programs on a computer.

It's definitely more budget-intensive to muck around with hardware as a hobby, but at the same time, it's perhaps never been easier:

- Lots of used hardware on eBay/craigslist, if you're looking to acquire skills by dismantling or repairing stuff

- Good free tools (i.e. KiCAD)

- Affordable services to order PCBs from

- Lots of businesses selling parts to hobbyists

- Test gear such as scopes and DMMs are now much more affordable, with many low-budget options that are good enough - $1000-$1500 gets you a reasonably complete home lab

- Lots of 3D printing options for encasing what you make

- Large, vibrant communities full of other hobbyists to get help from (or buy used stuff from, if $1000 is above your means)

It's quite satisfying and achievable to build physical things on the side, or build complete systems with your hardware/device components involved.

Another reason it makes for a great hobby: It feels work-adjacent enough (to a software job) to be worth the time investment (i.e. you are gaining useful insights and knowledge that can inform your work as a SWE), while being different enough to feel like a change of pace.

"Embedded" means a deeper connection between the software and hardware by definition, so it might make sense for pure software to be uncommon.

Embedded means a computer is part of another product which includes satellites, spacecraft, aircraft and drones with millions of LOC. I've worked in embedded most of my career and in my experience, aside from driver developers and some middleware folks, the vast majority of embedded software engineers just work on embedded software applications.

I imagine the situation is vastly different for those working on a microcontroller, but that isn't the entirety of embedded systems.

I exclusively work on microcontroller projects, and my experience is the same. I've only worked on one project that really needed my EE experience to write some drivers. Once the drivers are there, it's all application layer for the rest of the project, which usually go on for 1-3 years for a team of 1 to 12 people.

Teams are so small. As in commonly 1 hardware and 1 software engineer.

You at least need some common vocabulary. "Hey the gpios are floating at startup and messing with the meter. Can we pull them down? Hmm no but perhaps we can reset the meter after startup to a known state." That sort of thing.

Counterpoint: in the space/aerospace world, having embedded systems running tens of millions of lines of code is common.

These have many large software teams working together. Most software engineers on these embedded programs are just that: software engineers. I've worked in embedded for a long time and have never "physically" debugged or otherwise physically touched the hardware I work on. There's a lot to embedded systems outside of microcontrollers.

Depends on the embedded system. I've only worked in mid-sized companies, and most of my projects were teams of 4 to 12 SWE-type with 1 to 3 EE for the project. Typically light ARM4 or weaker microcontrollers will have smaller teams, or no team, while anything beefier, like embedded Linux projects or anything with a UI, will have bigger ones.

Depends on the project. Most of the teams I've been on were 4-12 SWE for 1-3 EEs. These were usually mid-range microcontrollers with GUIs. It's typically only weaker, single-purpose embedded without an RTOS (like sensors or whatnot) that has 1 to 1 unless the company wants the project to drag on for half a decade.

Not that uncommon in my experience. Depends on the kind of microcontrollers/embedded computers. Weaker ones are closer to the bare metal and need some EE during development. More complex ones with a GUI or that run Linux are mostly application level work. And for mid-level microcontrollers (the kind I work on), once the drivers are there, it's all application work.

The problem for switching from pure software to embedded is that companies like you to have EE experience, even if the job doesn't require it at the moment, so you can use it if you need it. Of all my embedded coworkers, only one was a pure CompSci major. The rest were CompE or EE.

Personally I consider myself more SWE than EE, and half of my job titles have been "Software Engineer" instead of "Firmware Engineer" or "Embedded Engineer".

In the embedded world, running a multimeter, oscilloscope, or logic analyzer can be part of a pure software job. You're close to the hardware, and the hardware responds to what you do. For some bugs, the fastest route to debugging is to see what happened with the hardware.

Some embedded devices have robust OSes between you and the hardware; some don't. (This isn't a sign of bad engineering on the devices that don't, by the way.) The ones that don't, you need to get to know the hardware fairly well.

The only reason to use C in the first place is if you're doing something "impure": i.e. you're very dependent on memory layout, poking bytes directly into hardware, predictable timing properties, and so on.

100% this!

When i started learning Embedded Systems (lots of C/C++ Programming experience but without an Electronics background) it was understanding the needed Electronics and how to interface/debug the Hardware-Software interface where i had the most difficulty.

I found the following helpful in my education and hopefully people with a Software-only background who want to get into Embedded Systems will also find these useful;

* Designing Embedded Hardware by John Catsoulis - Very good introduction to relevant practical Electronics without drowning you in nitty-gritty details.

* Patterns for Time-Triggered Embedded Systems by Michael Pont (free pdf available at his company SafeTTy website) - Full of C code showing how to interface to hardware and do stuff.

* Practical Electronics for Inventors by Paul Scherz, Simon Monk - Reference for when you need more Electronics knowledge.

* Understanding Signals with the PropScope from the company Parallax (search for free pdfs online) - Practical lab book showing how to use PropScope(a USB based Oscilloscope) to study Signals on circuits built using the Parallax BASIC Stamp MCU board. You can use any other MCU/Oscilloscope combination (eg. Arduino with Analog Discovery 2 aka AD2) to build the same circuits and do the lessons. Digilent also has a lot of lessons on using the AD2 at its website.

* Introduction to Embedded Systems: Using Microcontrollers and the MSP430 by Manuel Jimenez et al. - Excellent and nicely illustrated textbook to learn Embedded Systems from. The MSP430 MCU is used as a case study but everything is presented in a general way.

> but the difficulty level for avoiding bad decisions is so high that I would be very hesitant to hire someone with no track record to operate solely in C.

People make bad decisions in high level languages all the time...

Absolutely. C lets you make all of those bad decisions too, then adds a whole new list of foot-guns on top. You can literally write bad code that will cause a different part of your program to segfault with no obvious connection between the two. So care must be taken.

Reply on news.ycombinator.com