Search the web
Sign In
New User? Sign Up
AgileEmbedded · Agile Embedded
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Want to share photos of your group with the world? Add a group photo to Flickr.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
Understanding Model-Conductor-Hardware pattern   Message List  
Reply | Forward Message #144 of 464 |
Re:Understanding Model-Conductor-Hardware pattern

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



Sat Jan 13, 2007 8:01 pm

rick_clements
Offline Offline
Send Email Send Email

Forward
Message #144 of 464 |
Expand Messages Author Sort by Date

I just joined this group after seeing a message on comp.software-eng by Mike Karlesky. I followed some links he provided and found an interesting article,...
Thad Smith
thadsmith3
Offline Send Email
Jan 10, 2007
6:22 am

Thad, I'll try to answer your questions as well as I can. We're pretty excited that there's some discussion starting on this topic. Pardon the length of what...
Michael Karlesky
mkarlesky
Offline Send Email
Jan 11, 2007
4:11 pm

... I think the something (Hardware or Conductor) might want to hide the hardware a little more by normalizing the temperature. so the model deals with...
James Grenning
jwgrenning
Offline Send Email
Jan 11, 2007
5:14 pm

... 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...
mkarlesky
Offline Send Email
Jan 12, 2007
3:50 am

I like the comparison of MHC to MVP and have found that analogy useful before. I agree that you want a very thin layer covering the hardware. I also think...
James Grenning
jwgrenning
Offline Send Email
Jan 12, 2007
4:55 am

... from current website: » Unity – embedded unit test framework for C (released 2008) http://sourceforge.net/projects/embunity/ Doesn't seem to have any...
marktxx
Offline Send Email
Apr 27, 2008
6:51 pm

... » Unity – embedded unit test framework for C (released 2008) http://sourceforge.net/projects/embunity/ Follow the link above and select the 'Code' menu...
Greg Williams
willi297
Offline Send Email
Apr 28, 2008
3:36 am

... That makes sense. ... I can understand that benefit to creating a Presenter in MVP. ... So do two separate modules, business and hardware. ... So do two...
Thad Smith
thadsmith3
Offline Send Email
Jan 12, 2007
2:22 am

... logic ... I think I understand what you mean when you say two separate modules, but perhaps I don't. We think the value of three modules (Model, Conductor,...
mkarlesky
Offline Send Email
Jan 13, 2007
12:48 am

... A thin hardware interface layer, the same, I think, as you use for the H layer, plus the rest in the business layer / application logic. ... I understand...
Thad Smith
thadsmith3
Offline Send Email
Jan 13, 2007
6:47 pm

... the ... understand ... Yes. This is the case. Separating M and C makes things easier to test. The separation ensures that there's no coupling between the...
mkarlesky
Offline Send Email
Jan 21, 2007
3:12 am

In AgileEmbedded@yahoogroups.com <mailto:AgileEmbedded%40yahoogroups.com>, James Grenning <grenning@...> ... The purpose of the hardware layer is to provide...
Rick
rick_clements
Offline Send Email
Jan 13, 2007
8:06 pm

... board.) ... Rick, what you're describing is what we would call unit tests, system tests, and acceptance tests. The MCH pattern makes it possible to unit ...
mkarlesky
Offline Send Email
Jan 21, 2007
3:53 am
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help