From: Adam Jensen <hanzer@riseup.net>
Subject: Re: Getting started with bare-board development
Date: Tue, 15 Nov 2016 12:32:55 -0500
Date: 2016-11-15T12:32:55-05:00 [thread overview]
Message-ID: <o0fgra$fm2$1@dont-email.me> (raw)
In-Reply-To: <o0ehht$1l0c$1@gioia.aioe.org>
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.
next prev parent reply other threads:[~2016-11-15 17:32 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
2016-11-15 9:58 ` Niklas Holsti
2016-11-15 17:32 ` Adam Jensen [this message]
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