4 ms·
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 lo
by 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)...