Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The software fixed the hardware

jwz.org

Post reply on HN
Print view View original

21–30 of 43 posts

Re: The software fixed the hardware

#21

Post by kaib »

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 augmenting. Software has the unique benefit that it can replicated essentially free while the physical improvements need to be administered separately in each and every instance.

Re. the backwards wired motors. Storing a config table in EEPROM seems to be a simple and portable solution to this. Do it in the logical way until you hit the output pins.

Re: The software fixed the hardware

#24

Post by ramchip »

djcapelis wrote: post #16
litewulf wrote: post #15

Earlier quoted context omitted.

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

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

Re: The software fixed the hardware

#27

Post by Quarrelsome »

dkarl wrote: post #10
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…

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…

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.

Re: The software fixed the hardware

#28

Post by po »

djcapelis wrote: post #16
litewulf wrote: post #15

Earlier quoted context omitted.

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

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_…'

Re: The software fixed the hardware

#29

Post by po »

dandelany wrote: post #13
jeffbarr wrote: post #9

Can they send one to Mars to fix the rover?

They can and have! I always thought this was very cool. However, the current Mars rover problem is not a hardware problem, per se, it's a stuck-in-the-mud problem.

The bad wheel that forced them to drive backward was a hardware problem. They should have designed it with 2 axes of symmetry!
Post reply on HN