The software fixed the hardware • Hacker News Board

Re: The software fixed the hardware

#41

Post by HeyLaughingBoy » Tue, Jan 05, 2010, 10:13 PM UTC

djcapelis wrote: post #14

dkarl wrote: post #10

Earlier quoted context omitted.

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 somet…

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.

Re: The software fixed the hardware

#42

Post by HeyLaughingBoy » Tue, Jan 05, 2010, 10:17 PM UTC

kaib wrote: post #21

djcapelis wrote: post #3

This type of thing happens all the time with embedded platforms. Software fixes for hardware defects are common. When we were building robots invariably the electronics team would always wire some motor backwards. Since the motors had similar power in both directions they would always ask me to just write the code to run motors they wired the wrong way backwards. It was simple enough to do, but it always feels a bit…

I just recently wrote some code to do pcb milling with pretty close tolerances. The actual milling table wasn't straight however, so when the substrate was clamped down it would have Z variations 3x larger than the desired cutting depth. A 5 minute touch probe run and a simple 2D compensation table removed the need for a time consuming tramming operations and expensive clamping hardware. This wasn't so much fixing as…

Do it in the logical way until you hit the output pins.

Ding, ding, ding!!! We have a winner. This is exactly correct: write your code the way everything should be in a perfect world, BUT have a hardware abstraction layer to separate that from reality. The upper layer code should just know that when the end sensor is reached, the hydraulic ram should be reversed. The HAL knows what state the end sensor must be in when it's triggered, and what polarity to send to the valve controlling the hydraulic ram.

Even in small embedded systems, a properly tiered architecture can save a lot of trouble.

Re: The software fixed the hardware

#43

Post by djcapelis » Mon, Jan 11, 2010, 10:53 AM UTC

blackguardx wrote: post #38

djcapelis wrote: post #3

This type of thing happens all the time with embedded platforms. Software fixes for hardware defects are common. When we were building robots invariably the electronics team would always wire some motor backwards. Since the motors had similar power in both directions they would always ask me to just write the code to run motors they wired the wrong way backwards. It was simple enough to do, but it always feels a bit…

Don't worry, it works the other way as well. At my last job, I had to fix software defects in hardware.

I think I'd like to file a hug report...