4 ms·

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 comfo

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.

dragontamer 4y ago
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.
- ghostpepper 4y ago
  "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.
- InitialLastName 4y ago
  > 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.
azalemeth 4y ago
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)...

dragontamer 4y ago

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.

ghostpepper 4y ago
"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.
InitialLastName 4y ago
> 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.

azalemeth 4y ago

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)...