(no subject)
Sep. 18th, 2018 08:20 pmMy manager's in China, so I can be productive my way rather than his, and I don't feel like lighting myself on fire in front of the building.
We have a complicated test system to test a complicated chip. Among the problems: I wrote the interface software, and that took a while. It took us a while to figure out how to power up the interface, even. (The documentation said you plug in one cable, program it, unplug that, plug in the other cable, and off you go, but it turns out you have to unplug everything then plug in both cables because of an error in the circuit board hardware, that I was apparently the first person to discover. This kind of problem is a perfect prototype for the whole imbroglio.)
The main test system has some hardware problems. Those took a long time to figure out, and a lot of rewiring with fine wire to fix. The instrumentation that interfaces with it is fussy, with lots of hidden settings that have dramatic effects if they're not right, and the instrumentation interface software is full of bugs. The software package we use has funny rules for registering software functions with the overall package, and when we're rewriting broken drivers that still don't run, it's not obvious whether we fixed the driver but didn't register it right, or whether the driver is still broken. It gets worse when my manager tries to fix things in a hurry and mistakenly overwrites working drivers with ones that are broken in new and subtle ways, or when I manage to physically break one of the rework wires so suddenly nothing works. Oh, it's worse than just not working: our chip has what we politely call a poorly defined specification, where if it powers up but doesn't receive communications, it jams all the communication interface lines to ground, and the aforementioned interface board, trying to drive those lines, fries its outputs silently so it appears to still be working, but nothing's talking anymore. Since we have multiple chips in the system, I have to get them all powered up and talking in a short window of time, a fraction of a second, or else one or another of them will ground the communication lines and burn everyone else out. We learned today that rapidly varying the load on the chip will cause it to reboot, and that's right back into the same morass of burning out everything else connected to it. Same with rapidly varying the input voltage. I'm trying to write stuff that cushions the loads, but we're still not sure what the critical loads are, so I'm burning up a lot of stuff. The whole project makes me feel sick to my stomach, and I've been working a fair amount of extra hours, working in the evenings at home, and not sleeping so well as a result.
I drove the Spitfire to the hardware store the other day, to buy caulk for redoing the tub surround, because it was gross. When I came back out and tried to start the car, it went 'click' and nothing more. Generally that means either the battery is low or the starter solenoid is dying. The traditional treatment for the latter is whacking it with something robust, at which point it'll run another ten times or so, and repeating that with the revive interval getting shorter each time. Since the Spitfire's going to be my primary transport next week, when my usual car is in the shop for new head gaskets, I ordered a replacement starter solenoid today. But! one of the lovely things about that weird little car is that I didn't even have to open the hood to get home. I popped it out of gear, pushed it back into the parking lot, which has about a 1% slope, turned the steering wheel to point down, hopped in, and oh so slowly started rolling, then snapped the clutch in third, the car fired up, and I drove home. I went without a functional starter motor on the Subaru for about a week once upon a time, but it was a drag so this time I'm trying to be proactive about fixing the Spitfire BEFORE I need it.
We have a complicated test system to test a complicated chip. Among the problems: I wrote the interface software, and that took a while. It took us a while to figure out how to power up the interface, even. (The documentation said you plug in one cable, program it, unplug that, plug in the other cable, and off you go, but it turns out you have to unplug everything then plug in both cables because of an error in the circuit board hardware, that I was apparently the first person to discover. This kind of problem is a perfect prototype for the whole imbroglio.)
The main test system has some hardware problems. Those took a long time to figure out, and a lot of rewiring with fine wire to fix. The instrumentation that interfaces with it is fussy, with lots of hidden settings that have dramatic effects if they're not right, and the instrumentation interface software is full of bugs. The software package we use has funny rules for registering software functions with the overall package, and when we're rewriting broken drivers that still don't run, it's not obvious whether we fixed the driver but didn't register it right, or whether the driver is still broken. It gets worse when my manager tries to fix things in a hurry and mistakenly overwrites working drivers with ones that are broken in new and subtle ways, or when I manage to physically break one of the rework wires so suddenly nothing works. Oh, it's worse than just not working: our chip has what we politely call a poorly defined specification, where if it powers up but doesn't receive communications, it jams all the communication interface lines to ground, and the aforementioned interface board, trying to drive those lines, fries its outputs silently so it appears to still be working, but nothing's talking anymore. Since we have multiple chips in the system, I have to get them all powered up and talking in a short window of time, a fraction of a second, or else one or another of them will ground the communication lines and burn everyone else out. We learned today that rapidly varying the load on the chip will cause it to reboot, and that's right back into the same morass of burning out everything else connected to it. Same with rapidly varying the input voltage. I'm trying to write stuff that cushions the loads, but we're still not sure what the critical loads are, so I'm burning up a lot of stuff. The whole project makes me feel sick to my stomach, and I've been working a fair amount of extra hours, working in the evenings at home, and not sleeping so well as a result.
I drove the Spitfire to the hardware store the other day, to buy caulk for redoing the tub surround, because it was gross. When I came back out and tried to start the car, it went 'click' and nothing more. Generally that means either the battery is low or the starter solenoid is dying. The traditional treatment for the latter is whacking it with something robust, at which point it'll run another ten times or so, and repeating that with the revive interval getting shorter each time. Since the Spitfire's going to be my primary transport next week, when my usual car is in the shop for new head gaskets, I ordered a replacement starter solenoid today. But! one of the lovely things about that weird little car is that I didn't even have to open the hood to get home. I popped it out of gear, pushed it back into the parking lot, which has about a 1% slope, turned the steering wheel to point down, hopped in, and oh so slowly started rolling, then snapped the clutch in third, the car fired up, and I drove home. I went without a functional starter motor on the Subaru for about a week once upon a time, but it was a drag so this time I'm trying to be proactive about fixing the Spitfire BEFORE I need it.