4 ms·
Yeah, the lack of hardware interlocks are part of what makes it a (literal!) textbook case for software engineering ethics. I remember talking about it several
by Espressosaurus 1mo ago
Yeah, the lack of hardware interlocks are part of what makes it a (literal!) textbook case for software engineering ethics.
I remember talking about it several times over my college career, and for good reason.
To this day when people start talking about software in the loop in a safety context I get extremely twitchy. I don't let that shit happen on my watch.
- milesvp 1mo agoI had an interview once for a firmware position dealing with (relatively) high wattage transmitters. They wanted to know how I’d deal with some conditions where I’d need to turn off the power quickly. After talking a bit about my experience with hard real time deadlines, I sheepishly asked why they didn’t have diodes to mitigate the problem. I think it was one of the questions that got me an offer. Apparently having firmware engineers with even minor EE background and will think about analogue design is a little uncommon. Today, I’d ask about more ways to push the responsibility away from the firmware to stop catastrophic failures. If the debugger pauses the CPU you can’t use the CPU to regulate things. I’ve worked on things where the failure mode can be explosive and it makes dev really harrowing if you can’t rely on hardware interlocks.
- yuye 1mo ago>Apparently having firmware engineers with even minor EE background and will think about analogue design is a little uncommon. They often don't have to know how the nitty-gritty of the HW works. HALs are used everywhere, and some of them abstract a lot away. I've interviewed embedded SWEs that couldn't explain how the tri-state buffers work within GPIO.