Hacker News Reader

Comment by dkarl | Hacker News Reader

it always feels a bit wrong

It helps to think of it as "don't care" code rather than "error compensation" code. Which way should the engine be wired? It's cool; the software doesn't care. Just wire it up however. What order should I start these services? It's cool; they don't care. Just start them up however. As soon as your users stop caring about the stuff you can take care of, they'll have time to care about something else that's more important.

View on HN

Well, the values actually sent out to the PWM were backwards. Thankfully I could just invert it at the last step in the code where it got sent and so while writing the actual code I could pretend everything was correct. It's hard to think of -127 going forward and 127 going backwards as anything but a dirty hack.

While the underlying electronics thankfully didn't care, the digitized values set up certain expectations.

Typically I get around this by having each motor's direction defined separately. Since you very often need to define the logic of a sensor ('1' can mean either ON or OFF depending on the sensor type) on a sensor-by-sensor basis, it makes sense to do this for motors as well.

And in this case, don't forget to do a #define INVERSE_MOTOR_POLARITY 1 or similar, so that the hack is clear and doesn't bite you when porting to another platform.

It's not a bug, it's a customizable feature :)

You're in trouble though when the front motors are wired one way and the rear ones another, or one particular motor is miswired. Imagine #define FRONT_MID_SECTION_MINI_MOTOR_POLARITY (...)

Typically more like:

  #DEFINE MOTOR_0_WIRED_WRONG_BY_#$@#$_ELECTRICAL_TEAM
  #DEFINE MOTOR_1_WIRED_WRONG_BY_#$@#$_ELECTRICAL_TEAM
  ...

That said, the notion of portable embedded code when we're talking about the types of systems where these types of hacks thrive is pretty funny. These are not the type of routines people port or reuse and most of these hacks are very specific behavioral stuff to match specific pieces of hardware.

Hopefully you're not putting in hacks in the parts of the system you might actually reuse that's supposed to be more independent!

Code re-use is a principle that's often struggled outside of embedded systems. Inside embedded systems code it's downright scarce.

I think it's getting more common in the hobby community though. Just look at all the code and modules ready to use on AVRs, Stamps, etc.

It's only a shame that a lot of it is fairly unreliable C code. The situation for embedded C reminds me of PHP. You can find snippets for anything, but most of them won't be written by experienced library authors and can have an 'interesting' behaviour...

In my previous job we had several KLUDGE_TABLES as a way for our DBA to remind people that they were asking him to add a dirty hack that they promised to remove once the 'crisis' was gone. Five years later, they were still in there. At least the person querying it still had to type 'SELECT * FROM KLUDGE_…'

It can get a bit mad sometimes though. The main issue is that if a hardware fault is found it is sometimes too late to rectify without a massive cost.

My management was recently trying to convince me to rewrite a FAT file system in high level code due to issues with power management, corruption and the disk we store our most precious data on.

I work in the safety critical/life-saving realm of embedded systems, and it has definitely been an eye-opener to see just how many bugs are 'forgiven' just because there is a software layer on top to make things work as expected instead of as designed ..

Reply on news.ycombinator.com