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: Sun, 13 Nov 2016 17:00:19 -0500
Organization: A noiseless patient Spider
Message-ID: <o0anol$qna$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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 13 Nov 2016 21:59:50 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="886269296a8927a8e422a267cc77681a";
	logging-data="27370"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX187BPLL+mJ7X/ekXfDp5FNg"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
In-Reply-To: <o0akh0$fp4$1@dont-email.me>
Cancel-Lock: sha1:tGd7D9zEy/U+kgZHPojXaMhEeSk=
Xref: news.eternal-september.org comp.lang.ada:32301
Date: 2016-11-13T17:00:19-05:00
List-Id: <comp.lang.ada>

On 11/13/2016 04:04 PM, Jeffrey R. Carter wrote:
> You seem to be thinking at too low a level. There isn't any "mocked
> H/W", only mocked behavior. The H/W simulation bodies give the
> information or have the effect expected of the devices given the state
> of the reality modeled in the environment pkg, but they need have no
> similarity to the real bodies, and usually don't. The device may be
> memory mapped, but there's no reason for the simulation to be. If access
> the device takes appreciable time, that's usually simulated using a
> delay. There's usually no reason to limit these parts of the S/W to the
> constraints of the target run time.

I suppose software developers might be accustomed to ignoring time, the
Turing machine/model-of-computation having no explicit representation of
time. But you are correct, I very much retain the perspective of an
electrical engineer and I most definitely think about the machine as
something that exists in time.

Doesn't the Real Time Annex related parts of the run-time support system
expect timing information from the hardware? (I am almost entirely
guessing about this, I haven't yet finished reading the basic
introductory materials on real-time programming).

It would probably help a lot to see a very basic little ("Hello,
Real-Time World") example of [your development approach to] real-time
software with a mocked hardware interface that can be executed directly
on a workstation. I suppose the hardware could be as simple as a clock
and maybe a counter or two. Maybe there could be some interrupts and two
or three tasks that do something very simple. And maybe all of this
could take place under the Ravenscar profile. Would that be a lot of
effort to write and post?