tools

Creating some tools at work. Write a text file on a PC, translate to binary,
burn on an eeprom which is connected to a PIC 16F887 which is listening
as a slave on a two-wire RS485 bus.

Also read back and display as a text file.

The text file should be idempotent through the chain, a perfect copy
residing on the remote (and very isolated) eeprom.

Its an SPI eeprom, that's three wires, driven by the 8 bitter.

This so our client can create his own eeproms which control their instruments.
Right now, I have to edit and recompile the firmware; and the development menu lets me program a single integer into the eeprom to ID it. With this, the client will program
everyting about a given instrument which is currently part of the firmware.

Incremental development.

Medical vs. Commercial software

Commercial software is released when the marketroids say so. Medical software is released when you can defend yourself in court ---meaning testing, procedures, QA, documentation, skill, etc.

What is dangerous is when commercial software is used in life-critical apps, eg some vulnerable software is used by a contractor for a nuclear reactor.

I took classes with Dr. Nancy Leveson and roomed with Dr. Clark Savage Turner. I later read the Therac papers, worked for a defibrillator company, and later an electrosurgical instrument company. None catastrophic; though the chief scientist at the place I now work at has worked on aircraft systems, as have the two other founders.
I worked on a video kludge for some obsolete hardware there, nothing critical at all.

The defib code and the ESG / ESU code could hurt one or two people, nothing major
catastrophic, but still enough to be superuseful and somewhat or slightly dangerous.
I was not a lead, in fact, brought in fairly late, in the case of the defib; but I am
the lead on the ESU.

In a few years my software could run a tool being stuck into your inflated abdomen. I will do my best to make it do as told.