In AgileEmbedded@yahoogroups.com
<mailto:AgileEmbedded%40yahoogroups.com>, James Grenning <grenning@...>
wrote:
> The intent of the MHC pattern is to allow for maximum automated
> testability; it does this by decoupling hardware from code. In MVP the
> same thing is accomplished in decoupling widgets from event handlers and
> code. If temperature normalization happens in the Hardware layer then
> the only way to unit test the normalization is to exercise the sensor
> hardware directly and use a debugger to inspect normalized values (one
> of the things we're trying to avoid). If, instead, the normalization
> code is simply a function in the Model that accepts raw A/D values, then
> the vast majority of all the code can be tested apart from the hardware
> in a unit test framework (we wrote a very small C-based framework for
> just such a purpose).
The purpose of the hardware layer is to provide the normalization. The
only way to really test it is a climate chamber. And, it took 30
minutes to stabilize to the new ambient temperature with the case off.
On a real system that I tested, the hardware layer had a wrapper
(driver) around each sensor. At power up, the init code read the board
revision and told each driver which DAC it's sensor was on or if it
existed on that board. It also told the drive what the scaling factors
were. To verify the conversion was correct a unit had to go into the
climate chamber. The conversion error that we missed was because we
didn't rerun the climate temperature test when the board was ECO'ed.
(It was considered trivial enough that we didn't even get a new board.)
An error was made implementing the ECO and the new scaling resisters
were swapped, so the scaling logic didn't match the hardware. (The
software was right. It was the hardware that was wrong. But, it
wouldn't have made the customer any happier when s/he didn't get a
message the unit was close to failure.)
All of the logic above the hardware layer was tested outside of the
chamber. I could RPC into the unit and put any driver into test mode
and give it a value to report. I could set any temperature sensor to a
specific temperature or have it report not present. I had similar
controls over all of the other sensors.
Rick Clements