From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Getting started with bare-board development Date: Sat, 12 Nov 2016 21:01:36 -0700 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 13 Nov 2016 04:01:10 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="09e61aea82dc7fb95595da9aad5c117c"; logging-data="12036"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/1N5KW4CLx3AUVUd7ybsaFswbT7PxiLR8=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 In-Reply-To: Cancel-Lock: sha1:DfE8QCl5nazo7t7B1QZ/7fPpfwc= Xref: news.eternal-september.org comp.lang.ada:32297 Date: 2016-11-12T21:01:36-07:00 List-Id: 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