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!feeder.eternal-september.org!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Getting started with bare-board development
Date: Tue, 15 Nov 2016 11:58:58 +0200
Organization: Tidorum Ltd
Message-ID: <e904j2Fss0iU1@mid.individual.net>
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; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net mpU8BOqkc9lNYGw92cX1tweZnJHkiCkRxrpfwFvY+PZNw6WLVv
Cancel-Lock: sha1:g5Uo8tbEqDqQfjujolll0WRr40c=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0)
 Gecko/20100101 Thunderbird/45.4.0
In-Reply-To: <o0ehht$1l0c$1@gioia.aioe.org>
Xref: news.eternal-september.org comp.lang.ada:32321
Date: 2016-11-15T11:58:58+02:00
List-Id: <comp.lang.ada>

On 16-11-15 10:38 , 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.

In my domain (subcontractor for embedded SW in spacecraft) we typically 
use only one of the stages 1 and 2, not both. But otherwise our work is 
very similar.

> 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.

Or unless you worry about compiler bugs being different in the native 
and cross compilers, or about platform-dependencies introduced by 
mistake in the Ada application. Endian-dependency is easily introduced 
by mistake if the application does a lot of communication with HW. Our 
targets are usually big-endian SPARCs, but workstations are 
little-endian PCs.

Typically we do the final unit-testing runs both on workstations and on 
a target emulator, to settle such worries.

> Whatever OS/platform-dependent parts requiring test under an emulator,
> they are quite minuscule or non-existent if an OS is used.

We rarely (well, never) use an OS in embedded systems. Ravenscar or 
bare-board (zero runtime) is the norm for us. Though, there is a trend 
to have application-independent but domain-specific "execution platform" 
SW components which are like domain-specific OSs and can support various 
applications in this domain.

-- 
Niklas Holsti
Tidorum Ltd, working for SSF
niklas holsti tidorum fi
       .      @       .