views:

25

answers:

2

Being a softie, I'm currently fighting some hardware techies on a hardware detection mechanism.

I feel like it should be possible to build a detection/discovery mechanism that is 'future proof', in a way that the detection software, built today, will be able to recognize a limited set of properties of all hardware versions developed in the future.

The argument against: the current (dsp) chip may become obsolete in the near future; hence, we cannot guarantee that future boards will be compatible with the current discovery protocol.

How is this done for e.g. USB, PnP, and are there other examples?

+1  A: 

The key to the answer is in the protocol, just as you are hinting at. It may not always be pretty, and sometimes you are locking yourself into a design.

However, the PC architecture itself is proof of feasibility of forward detection.

It is often entirely possible to boot a Linux kernel compiled in say, 1996 on a system purchased today. The Linux system may not be able to use much of the hardware in that system, but it will find whatever subset is still the same.

It requires however, either a very wise hardware detection scheme or a willingness to live with kludges (see the line A20 setup on PCs, originally using the keyboard controller) or both at the same time. (Like how almost all PCs today both has the old ISA bus internally for things like PS/2 keyboard support, but also have the PCI protocol.)

For work, I designed an ID ROM format for daughter boards. They had a compact, binary XML or Lisp-like structure with a few mandatory fields, several optional, and a version number. Any completely new hardware can increment the version number and add any data necessary for new software, while still telling old software whatever appropriate in the old fields.

So that at the very least, the old software can detect the board ID, purpose, and then give up. This is much how USB devices work. All old software can enumerate new devices, but it is far from certain that the old software can drive the new hardware in any meaningful way. Exceptions are keyboards, mice and memory sticks, where everybody sticks to the old "application level, so to speak" protocols.

Amigable Clark Kant
+1  A: 

There is a configurable Vendor ID and Device ID that is transmitted to the OS in a standard way. The driver responsible for it recognizes the hardware this way. So if you know in the driver the device id then you will know if it is compatible. If the device ID remains the same then you should use some memory mapped registers that can be read out to contain some extra information (which is recommended!) like the hardware design version, etc.

Anyway the driver MUST know what hardware it is talking to and react accordingly. It is a matter of design to have some standard way to detect the hardware correctly. So agree on some addresses where this info is stored and stick to it. Also design it in a way it can be extended in the future.

jdehaan