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: Adam Jensen <hanzer@riseup.net>
Newsgroups: comp.lang.ada
Subject: Re: Getting started with bare-board development
Date: Tue, 15 Nov 2016 12:32:55 -0500
Organization: A noiseless patient Spider
Message-ID: <o0fgra$fm2$1@dont-email.me>
References: <o05g4n$q11$1@dont-email.me> <o06obm$u1b$1@dont-email.me>
 <o07f4o$9r4$1@dont-email.me> <o08oi5$bo4$1@dont-email.me>
 <o0agtr$2gg$1@dont-email.me> <o0akh0$fp4$1@dont-email.me>
 <o0anol$qna$1@dont-email.me> <o0bump$1lph$1@gioia.aioe.org>
 <o0dhnh$pbs$1@dont-email.me> <o0ehht$1l0c$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 15 Nov 2016 17:32:27 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="9f32be05ceed8ab4eea6b0c0b258b397";
	logging-data="16066"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18seAVcqCC1hWewHvxqrVu4"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
In-Reply-To: <o0ehht$1l0c$1@gioia.aioe.org>
Cancel-Lock: sha1:vMj0ehr5od0Y/vM+pPTZl6KT2tI=
Xref: news.eternal-september.org comp.lang.ada:32325
Date: 2016-11-15T12:32:55-05:00
List-Id: <comp.lang.ada>

On 11/15/2016 03:38 AM, Dmitry A. Kazakov wrote:
> Typical developing process stages, at least in my area, is like this
> 
> 1. Workstation    Simulation time
>    Application
>    [HAL]
>    Mock actuators/sensors
> 
> 2. Workstation    Hardware-in-the-loop, real-time
>    Application
>    [HAL]
>    Real/Mock actuators/sensors
> 
> 3. Embedded       Target platform
>    Application
>    [HAL]
>    Real/Mock actuators/sensors
> 
> Most of developing is done in #1 or #2. Most of testing in #2. #3 is
> limited to final integration tests.

I think I am beginning to understand this perspective. (Thanks for your
patience).

> QEMU et al is not used, because it makes no sense to emulate
> computational hardware when you have Ada, unless you are an OS
> developer. So long the application is really an application you don't
> need that sort of emulators.

"unless you are an OS developer" might be a key issue here. I have been
thinking very much about device driver and run time kernel development
for custom hardware. Ideally, what I am looking for (or trying to sort
out) is a development methodology and tool-chain that fits into and
extends the hardware development process.

It still seems to me that the ability to compartmentalize the
emulated/simulated/HIL environment from the workstation's environment
would be helpful, if not essential, at various stages of development and
verification.

Does this make sense or is my view still somewhat askew?

> Whatever OS/platform-dependent parts requiring test under an emulator,
> they are quite minuscule or non-existent if an OS is used. Which is also
> the reason why bare-board targets should be avoided where possible.

I can appreciate how it might be desirable for the workstation and the
embedded target to provide the same OS/RTS environmental abstractions
(for a software application developer's convenience), but the class of
embedded software that I have in mind probably needs to have deep
integration with the hardware, and the hardware definitely will have
very deep traction with reality.