From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Subject: Re: Getting started with bare-board development
Date: Sat, 12 Nov 2016 21:01:36 -0700
Date: 2016-11-12T21:01:36-07:00 [thread overview]
Message-ID: <o08oi5$bo4$1@dont-email.me> (raw)
In-Reply-To: <o07f4o$9r4$1@dont-email.me>
On 11/12/2016 09:14 AM, Adam Jensen wrote:
>
> How is it done in embedded software engineering? (Links and/or
> references are very welcome)!
Typically embedded S/W has to interface to various H/W devices (sensors and
actuators). Frequently such S/W is designed around the capabilities and features
of the intended H/W. This is not a good idea. When the intended H/W changes (as
it does frequently on the projects I've been involved in) the entire design has
to be revised.
What I have done when designing such S/W is to 1st design the core S/W without
regard to the capabilities and features of the intended H/W. I create the
simplest and clearest design, and this identifies the kind of information the
S/W needs to obtain and the kind of external actions it needs to take.
Next, for each piece of external information the S/W needs to obtain, I write a
pkg spec for a S/W-leaning interface. This keeps the S/W simple and clear by
providing just the kind of I/F it needs.
Then, for each intended H/W device, I write a pkg spec for a H/W-leaning
interface. This reflects the capabilities and features of the device.
Then I write bodies for each of the S/W I/F pkgs that use the H/W I/F pkgs.
Now comes the fun part. I write an environment pkg that simulates reality, and
write simulation bodies for the H/W I/F pkgs that read or modify that simulated
reality. The body can take do things to make its behavior realistic; for
example, if a sensor is noisy, the body would add noise to the real value.
This lets you play with your S/W and see if it behaves reasonably.
When it's time to run the S/W on the real system, you eliminate the environment
pkg and replace the H/W I/F bodies with ones that actually I/F with the H/W.
Note that the only differences between the simulated and actual systems are
those bodies.
This approach has a number of benefits:
* Changing a device only affects a S/W I/F body and a H/W I/F pkg.
* Often the simplest and clearest design for the core S/W wants to access
information or take action in a way the intended H/W doesn't support. The S/W
I/F pkg provides a single place to convert between the 2 views, keeping the core
S/W uncoupled. For example, in the ubiquitous cruise-control problem, the best
approach for the core S/W might be for it to decide when it obtains the car's
speed, but a common design for the speed sensor is something that generates an
interrupt every time something rotates a certain amount.
* While there is usually a 1:1 correspondence between S/W and H/W I/F pkgs,
there need not be. I've seen sensors that returned multiple, unrelated values.
The design had multiple S/W I/F pkgs interacting with a single H/W I/F pkg.
* I've worked on projects where the whole point was to create a simulation to
see if the approach is viable, with no idea what the H/W devices would be like
in a real system. By using this approach, when it was decided to go ahead with a
real system, only the H/W I/F pkgs and the S/W I/F bodies had to be rewritten.
When I present such a design, coders usually start whining about "efficiency".
In my decades of experience, such a design has never been responsible for a
system not meeting its timing requirements.
--
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57
next prev parent reply other threads:[~2016-11-13 4:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-11 22:19 Getting started with bare-board development Adam Jensen
2016-11-11 22:43 ` Maciej Sobczak
2016-11-12 9:45 ` G.B.
2016-11-12 16:14 ` Adam Jensen
2016-11-12 19:15 ` artium
2016-11-12 21:37 ` Adam Jensen
2016-11-13 4:01 ` Jeffrey R. Carter [this message]
2016-11-13 20:03 ` Adam Jensen
2016-11-13 21:04 ` Jeffrey R. Carter
2016-11-13 22:00 ` Adam Jensen
2016-11-14 8:11 ` Paul Rubin
2016-11-14 23:03 ` Adam Jensen
2016-11-14 9:04 ` Dmitry A. Kazakov
2016-11-14 23:35 ` Adam Jensen
2016-11-15 8:38 ` Dmitry A. Kazakov
2016-11-15 9:58 ` Niklas Holsti
2016-11-15 17:32 ` Adam Jensen
2016-11-16 9:30 ` Dmitry A. Kazakov
2016-11-15 0:06 ` Jeffrey R. Carter
2016-11-14 18:17 ` Simon Wright
2016-11-14 22:52 ` Adam Jensen
2016-11-12 20:59 ` Brian Drummond
2016-11-15 1:14 ` antispam
2016-11-15 4:20 ` Adam Jensen
2016-11-19 22:46 ` antispam
2016-11-15 19:34 ` Robert Eachus
2016-11-15 22:07 ` Adam Jensen
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox