In this case, the suggestion given below of putting some flash memory on
the device itself is critical. Consider the following scenario: the
customer buys the board, which has been calibrated at the factory, as part
of a system. Being a customer, they see the board as interchangeable to
any other box that supports its bus, and expect to be able to move the
board around. It is useless to store the calibration data on the
motherboard; if the mothboard fries, and they buy a replacement
motherboard, they’re screwed, because all the calibration data has been
lost.
And, strictly speaking, the sensor calibration data is part of the
/sensor/, not its controller board, and as such, the calibration data
should be uploaded to the sensor, not kept on a controller board.
I would imagine that any sensor that requires calibration is not cheap.
So we have external sensors, a controller board, and a platform that hosts
these. It strikes me that the controller board and the platform are
completely irrelevant here. The sensor calibration becomes part of the
sensor. So if I disconnect sensor A from platform A’ and plug it into
platform B’, its calibration data has to move with it. That says to me
that it belongs in the sensor itself. It most certainly does not belong
on the motherboard, or even the controller board. If you put it on the
controller board, you have to provide a way to upload and download the
individual sensor calibration data so the sensors could be moved
platform-to-platform, or, more critically, that a totally-fried platform
can be swapped in and everything keeps working correctly.
I’d try to explain this to managers using very short and simple words.
“This idea sucks” is the condensed version of that information.
joe
> But once again: if the device really needs to persist some info across
> disk
wipes (and if this is not a figment of imagination of some moronic manager
who
does not know his clients well) - then having NVRAM on the device itself
is
the best idea.
The requirement is to store Sensors Calibration data in a Platform. The
calibration data are device, Platform and also System Specific.
Calibration data are added to System during Assembly by ODM and augmented
during its working by some SW (Driver or App). And it is NOT OS specific.
As it is done during Factory Assembly, it is not possible for user to
recalibrate it accurately at home. And it is a fact that a user will not
appreciate loss of Platform calibration on new OS reinstallation.
Current Platforms are deploying Extra Micro Controller to store
calibration data. So we are exploring option to remove this
Microcontroller and store the data in standard storage locations.
There is a MSFT spec available at
http://msdn.microsoft.com/en-us/library/windows/hardware/ jj159304.aspx
for reference. I am looking at Non-Microcontroller Sensor Systems
(Driver-Based) section, on page 7. “Having NVRAM in the device itself” is
existing solution and we are looking at alternatives.
Now do we have any specific suggestion how to implement it?
>I thought the point was to use disk INSTEAD of ACPI/UEFI magic. Weren’t
you just looking for a way for the driver to store information that
would survive a reinstall? You’d read and write it from your driver,
not from the BIOS. You wouldn’t survive a reformat, of course, but
that would be an issue with your concept, too.
I am looking to survive the OS reinstallation. Using Registry or file will
not survive OS reinstallation, but using UEFI/ACPI will survive. Though
this will not survive BIOS change or Disk change. Having access to BIOS
NVRAM will survive these also.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
