comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Getting started with bare-board development
Date: Tue, 15 Nov 2016 09:38:21 +0100
Date: 2016-11-15T09:38:21+01:00	[thread overview]
Message-ID: <o0ehht$1l0c$1@gioia.aioe.org> (raw)
In-Reply-To: o0dhnh$pbs$1@dont-email.me

On 15/11/2016 00:35, Adam Jensen wrote:
> On 11/14/2016 04:04 AM, Dmitry A. Kazakov wrote:
>> I think you are confusing things a bit. If you have computing hardware
>> mocked you are doing simulation and the time is simulation time. If the
>> peripheral hardware is real or partially real it is hardware-in-the-loop
>> simulation (HIL). HIL is usually real-time because. What people are
>> saying is that HIL is much more cost efficient developing platform than
>> some embedded board. Furthermore Ada is ideal for HIL because Ada
>> software is portable. So you can develop almost everything on the PC and
>> test almost everything in the loop. Then if some hardware (except the
>> board itself) is too expensive or difficult to use, it can be simulated
>> (mocked) in turn. Which is especially important when you want to test
>> some catastrophic or improbable scenarios.
>
> Yeah, I can imagine this stack (basic):
>  workstation's hardware - operating system - run-time system - program
>
> And this stack:
>  embedded hardware - embedded run-time system - RT-program
>
> And this stack:
>  RT-program
>  embedded run-time system
>  emulator (Qemu)
>  operating system
>  workstation
>
> But this setup is confusing:
>  RT-program
>  embedded target run-time system
>  simulated hardware
>  native run-time system
>  operating system
>  workstation

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.

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.

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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

  reply	other threads:[~2016-11-15  8:38 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
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 [this message]
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