Getting started with bare-board development

Getting started with bare-board development

[Adam Jensen]

Hi, I've recently began to have a serious look at Ada-2012 and
Spark-2014, and using GNAT for the development of real-time software in
embedded systems. What is a good way to get started? I am currently
reading an ebook of "Concurrent and Real-Time Programming in Ada"[1] and
I've recently ordered a paper copy of "Analysable Real-Time Systems:
Programmed in Ada"[2]; I also have the LRM and I come from a VHDL
background.

[1]:
https://www.amazon.com/Concurrent-Real-Time-Programming-Alan-Burns/dp/0521866979/
[2]:
https://www.amazon.com/Analysable-Real-Time-Systems-Programmed-Ada/dp/1530265509/

So I guess my question has more to do with sorting out the tool-chain
and a methodology than anything else. For example, would it be essential
(or especially convenient) to have a hardware development kit or is it
common to develop this kind of software using an emulator of some kind?
Adacore has an example for the STM32F4-Discovery[3], and more elaborate
documentation is available for the Nucleo[4], but both of those kits
seem to have very limited memory. How much can be done with that?

[3]:
http://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ugx/arm-elf_topics_and_tutorial.html
[4]: http://www.inspirel.com/articles/Ada_On_Cortex.html

Also, do ARM processors make sense for safety critical systems? If not,
would it make more sense to target a different platform from the beginning?

Re: Getting started with bare-board development

[Maciej Sobczak]

> Hi, I've recently began to have a serious look at Ada-2012 and
> Spark-2014, and using GNAT for the development of real-time software in
> embedded systems. What is a good way to get started?

In addition to the material that you have found already, you might also have a look at this:

http://www.inspirel.com/articles/Ada_On_Cortex.html

This tutorial presents complete examples on several popular boards, and focuses on zero-runtime, bare-board development.

> Also, do ARM processors make sense for safety critical systems? If not,
> would it make more sense to target a different platform from the beginning?

ARM processors become more and more visible and surely there will be safety critical projects using them in the future. Some of these processors are either specifically designed to target such systems or are evaluated and assessed by third-party certification companies to provide evidence for their safety values.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Getting started with bare-board development

[G.B.]

On 11.11.16 23:19, Adam Jensen wrote:
> For example, would it be essential
> (or especially convenient) to have a hardware development kit or is it
> common to develop this kind of software using an emulator of some kind?

Given your background in VHDL, this is perhaps familiar,
but I'll mention it anyway, collected from here and there:

- would timers be more real on hardware? Certainly more realistic.

- would you miss the physical experience and inspirational
   power (if any) of the real thing?

- does the simulator support sensors and actuators of the
   kind you would like to operate?

Also, if you move to a Ravenscar model of Ada, then chances
are that your RTS will be smaller. So, less memory will be
needed.  At some point, I'd want to try my programs on hardware.

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Getting started with bare-board development

[Adam Jensen]

On 11/12/2016 04:45 AM, G.B. wrote:
> On 11.11.16 23:19, Adam Jensen wrote:
>> For example, would it be essential
>> (or especially convenient) to have a hardware development kit or is it
>> common to develop this kind of software using an emulator of some kind?
> 
> Given your background in VHDL, this is perhaps familiar,
> but I'll mention it anyway, collected from here and there:
> 
> - would timers be more real on hardware? Certainly more realistic.
> 
> - would you miss the physical experience and inspirational
>   power (if any) of the real thing?
> 
> - does the simulator support sensors and actuators of the
>   kind you would like to operate?
> 
> Also, if you move to a Ravenscar model of Ada, then chances
> are that your RTS will be smaller. So, less memory will be
> needed.  At some point, I'd want to try my programs on hardware.

Hi,

Thanks for your answer. I can easily imagine that following one or both
of those tutorials[1] would be an informative an rewarding experience
but is the process outlined in those tutorials representative of a
typical design cycle for real-time, safety-critical, bare-board software
development?  For example, I suppose one could design logic for an FPGA
without the use of a simulator by synthesizing the logic, loading the
result into the hardware, then verifying the design by monitoring
various test-points during operation. From my perspective, that approach
seems a bit retarded. I am looking for the non-retarded methodology for
embedded software engineering :)

[1]: Web links to a couple tutorials were posted earlier in this thread.

The model-based engineering approach in hardware design (digital logic,
especially) enables almost omniscient visibility into a model's behavior
through simulation. In ASIC design, there is very high confidence in the
design long before the [very expensive] fabrication of prototypes. A
"first pass success" was common where an implementation would go from
prototype to production without any design changes ("a spin").

How is it done in embedded software engineering? (Links and/or
references are very welcome)!

I also have many other questions, like:

* How does one develop and verify a Board Support Package (device
drivers, bootloader, etc.)?

* Do the various typical embedded platform profiles (e.g., Ravenscar)
require any Run-Time System implementation or extension?

* Is the BSP and RTS the kind of software that might/should be
implemented in Spark?

I am trying to get a realistic view of the most successful techniques
that are used by professional engineers to build high-integrity and
safety-critical real-time embedded software systems. Again, any links,
references, discussion, etc. will be very appreciated!

Re: Getting started with bare-board development

[artium]

On Saturday, November 12, 2016 at 6:14:49 PM UTC+2, Adam Jensen wrote:
> On 11/12/2016 04:45 AM, G.B. wrote:
> > On 11.11.16 23:19, Adam Jensen wrote:
> >> For example, would it be essential
> >> (or especially convenient) to have a hardware development kit or is it
> >> common to develop this kind of software using an emulator of some kind?
> > 
> > Given your background in VHDL, this is perhaps familiar,
> > but I'll mention it anyway, collected from here and there:
> > 
> > - would timers be more real on hardware? Certainly more realistic.
> > 
> > - would you miss the physical experience and inspirational
> >   power (if any) of the real thing?
> > 
> > - does the simulator support sensors and actuators of the
> >   kind you would like to operate?
> > 
> > Also, if you move to a Ravenscar model of Ada, then chances
> > are that your RTS will be smaller. So, less memory will be
> > needed.  At some point, I'd want to try my programs on hardware.
> 
> Hi,
> 
> Thanks for your answer. I can easily imagine that following one or both
> of those tutorials[1] would be an informative an rewarding experience
> but is the process outlined in those tutorials representative of a
> typical design cycle for real-time, safety-critical, bare-board software
> development?  For example, I suppose one could design logic for an FPGA
> without the use of a simulator by synthesizing the logic, loading the
> result into the hardware, then verifying the design by monitoring
> various test-points during operation. From my perspective, that approach
> seems a bit retarded. I am looking for the non-retarded methodology for
> embedded software engineering :)
> 
> [1]: Web links to a couple tutorials were posted earlier in this thread.
> 
> The model-based engineering approach in hardware design (digital logic,
> especially) enables almost omniscient visibility into a model's behavior
> through simulation. In ASIC design, there is very high confidence in the
> design long before the [very expensive] fabrication of prototypes. A
> "first pass success" was common where an implementation would go from
> prototype to production without any design changes ("a spin").
> 
> How is it done in embedded software engineering? (Links and/or
> references are very welcome)!
> 
> I also have many other questions, like:
> 
> * How does one develop and verify a Board Support Package (device
> drivers, bootloader, etc.)?
> 
> * Do the various typical embedded platform profiles (e.g., Ravenscar)
> require any Run-Time System implementation or extension?
> 
> * Is the BSP and RTS the kind of software that might/should be
> implemented in Spark?
> 
> I am trying to get a realistic view of the most successful techniques
> that are used by professional engineers to build high-integrity and
> safety-critical real-time embedded software systems. Again, any links,
> references, discussion, etc. will be very appreciated!

Using a hardware emulator is not cost efficient. 

If you are developing for an microcontroller (eg BSP, HAL, drivers etc), you usually begin with an evaluation board that resembles the final design the best, and move to the custom hardware when it is ready (which will be derived from the evaluation board). This is a "board for each developer" approach[1].

If you are developing high level code for expensive hardware, you usually encapsulate the applicative part and compile it for your PC architecture[2]. The environment will be simulated using models of real hardware pieces. 

For example you are developing a mission computer for an aircraft, using this approach you will need to write a simulation of the Inertial Navigation System, but you will not need to write a simulation of the ethernet chip that allows communication with said systems. You simulate communication using sockets or shared memory, simulate flash with a file operations etc.

[1] For example, Texas Instruments stopped supporting simulators in their flagship IDE (http://processors.wiki.ti.com/index.php/CCSv6_Changes#Simulation)
[2] That is where using Ada helps a lot. It allows moving between hardwares with relative ease. 

Re: Getting started with bare-board development

[Adam Jensen]

Hi! Thanks for weighing in. A faint, fuzzy vision of the situation is
beginning to coalesce.

On 11/12/2016 02:15 PM, artium@nihamkin.com wrote:
> Using a hardware emulator is not cost efficient. 

By "hardware emulator", in this context, is it safe to assume that you
mean something like a hosted hypervisor that performs hardware
virtualization (e.g., QEMU[1])?

[1]: http://wiki.qemu.org/

One scenario using that approach might be:

A) GNAT can generate ARM-ELF for the Cortex-A9 processor series and
Run-Time support is available for the Xilinx Zynq-7000[2].

[2]:
http://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ugx/arm-elf_topics_and_tutorial.html

B) QEMU can emulate the Xilinx Cortex A9-based Zynq SoC including models
for many of its peripherals[3].

[3]: https://en.wikipedia.org/wiki/Qemu#ARM

On the surface, that seems like it could potentially be a viable
approach. More practically, that's a lot of software to validate and
models to verify; it seems like there are a lot of opportunities for
things to go wrong. Mostly, the software (and hardware) seems a bit
hokey (and tawdry).

Is that what you mean by "not cost efficient"?

> If you are developing for an microcontroller (eg BSP, HAL, drivers etc), you usually begin with an evaluation board that resembles the final design the best, and move to the custom hardware when it is ready (which will be derived from the evaluation board). This is a "board for each developer" approach[1].

Forgive my naivety but is it generally expected/required by software
developers that there will be some kind of "On-Chip Debug" or
"In-Circuit Emulation" capability in the hardware?

If the hardware has integrated instrumentation such that the behavior of
the software can be analyzed without any probe effect, I could see how
that might be simpler than the simulation/virtualization approach. On
the other hand, the software is being validated on hardware that is
running in a special, atypical (debug) mode of operation.

Is this the typical method/approach for high-assurance systems design?

> If you are developing high level code for expensive hardware, you usually encapsulate the applicative part and compile it for your PC architecture[2]. The environment will be simulated using models of real hardware pieces. 

Does that hold true for real-time software?

> For example you are developing a mission computer for an aircraft, using this approach you will need to write a simulation of the Inertial Navigation System, but you will not need to write a simulation of the ethernet chip that allows communication with said systems. You simulate communication using sockets or shared memory, simulate flash with a file operations etc.
> 
> [1] For example, Texas Instruments stopped supporting simulators in their flagship IDE (http://processors.wiki.ti.com/index.php/CCSv6_Changes#Simulation)
> [2] That is where using Ada helps a lot. It allows moving between hardwares with relative ease. 

Having a deeply ingrained hardware designer's mindset, I've put together
a tool-chain (and an implied methodology) for a fairly narrow class of
real-time embedded system. Maybe some readers of the news group can
comment on the costs and/or benefits of this approach.

* Freely available chip design software. Synopsys for synthesis;
ModelSim for simulation.

http://www.microsemi.com/products/fpga-soc/design-resources/design-software/libero-soc

* A flash-based FPGA (available in radiation tolerant versions) and a
development kit ($600!) with processor accessories/peripherals.
(Realistically, I would probably shop around for a board that better
fits this application or just invest the time to design one).

www.microsemi.com/products/fpga-soc/fpga/proasic3l
http://www.microsemi.com/products/fpga-soc/radtolerant-fpgas/rt-proasic3
http://www.microsemi.com/products/fpga-soc/design-resources/dev-kits/proasic3/cortex-m1-enabled-proasic3l-development-kit#overview

* The LEON3 processor - a synthesisable VHDL model of a 32-bit processor
compliant with the SPARC V8 architecture. (Also available in a
fault-tolerant version).

http://www.gaisler.com/index.php/products/processors/leon3
http://gaisler.com/index.php/products/processors/leon3ft

* The GRLIB IP Library - an integrated set of reusable IP cores,
designed for system-on-chip (SOC) development.

http://www.gaisler.com/index.php/products/ipcores/soclibrary

* GRSIM is a simulation framework for LEON3/GRLIB SOC devices.

http://www.gaisler.com/index.php/products/simulators/grsim

* GNAT Pro for LEON3

http://www.adacore.com/gnatpro/embedded/erc32

This last one is a bit confusing. I guess the Libre edition of GNAT
doesn't include support for the LEON3. I'm not sure if it is LEON3 BSP,
RTS, or ELF that is missing/excluded from the FOSS version of Adacore
GNAT. (If anyone has any information or insight into this, I would
really like to hear about it). On the other hand, in might be super cool
to write LEON3/GRLIB drivers and run-time support as open source Spark.

So is this Lovecraftian tool-chain over-the-top, just completely
demented, or fairly representative of high-assurance, real-time,
embedded software engineering?

Re: Getting started with bare-board development

[Jeffrey R. Carter]

On 11/12/2016 09:14 AM, Adam Jensen wrote:
>
> How is it done in embedded software engineering? (Links and/or
> references are very welcome)!

Typically embedded S/W has to interface to various H/W devices (sensors and 
actuators). Frequently such S/W is designed around the capabilities and features 
of the intended H/W. This is not a good idea. When the intended H/W changes (as 
it does frequently on the projects I've been involved in) the entire design has 
to be revised.

What I have done when designing such S/W is to 1st design the core S/W without 
regard to the capabilities and features of the intended H/W. I create the 
simplest and clearest design, and this identifies the kind of information the 
S/W needs to obtain and the kind of external actions it needs to take.

Next, for each piece of external information the S/W needs to obtain, I write a 
pkg spec for a S/W-leaning interface. This keeps the S/W simple and clear by 
providing just the kind of I/F it needs.

Then, for each intended H/W device, I write a pkg spec for a H/W-leaning 
interface. This reflects the capabilities and features of the device.

Then I write bodies for each of the S/W I/F pkgs that use the H/W I/F pkgs.

Now comes the fun part. I write an environment pkg that simulates reality, and 
write simulation bodies for the H/W I/F pkgs that read or modify that simulated 
reality. The body can take do things to make its behavior realistic; for 
example, if a sensor is noisy, the body would add noise to the real value.

This lets you play with your S/W and see if it behaves reasonably.

When it's time to run the S/W on the real system, you eliminate the environment 
pkg and replace the H/W I/F bodies with ones that actually I/F with the H/W. 
Note that the only differences between the simulated and actual systems are 
those bodies.

This approach has a number of benefits:

* Changing a device only affects a S/W I/F body and a H/W I/F pkg.

* Often the simplest and clearest design for the core S/W wants to access 
information or take action in a way the intended H/W doesn't support. The S/W 
I/F pkg provides a single place to convert between the 2 views, keeping the core 
S/W uncoupled. For example, in the ubiquitous cruise-control problem, the best 
approach for the core S/W might be for it to decide when it obtains the car's 
speed, but a common design for the speed sensor is something that generates an 
interrupt every time something rotates a certain amount.

* While there is usually a 1:1 correspondence between S/W and H/W I/F pkgs, 
there need not be. I've seen sensors that returned multiple, unrelated values. 
The design had multiple S/W I/F pkgs interacting with a single H/W I/F pkg.

* I've worked on projects where the whole point was to create a simulation to 
see if the approach is viable, with no idea what the H/W devices would be like 
in a real system. By using this approach, when it was decided to go ahead with a 
real system, only the H/W I/F pkgs and the S/W I/F bodies had to be rewritten.

When I present such a design, coders usually start whining about "efficiency". 
In my decades of experience, such a design has never been responsible for a 
system not meeting its timing requirements.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: Getting started with bare-board development

[Adam Jensen]

On 11/12/2016 11:01 PM, Jeffrey R. Carter wrote:
[snip]
> Then, for each intended H/W device, I write a pkg spec for a H/W-leaning
> interface. This reflects the capabilities and features of the device.
[snip]
> When it's time to run the S/W on the real system, you eliminate the
> environment pkg and replace the H/W I/F bodies with ones that actually
> I/F with the H/W. Note that the only differences between the simulated
> and actual systems are those bodies.

When writing device drivers, how do you mock the memory map of the
target hardware?

In the mocked the hardware, how is timing controlled?

When extending and mapping run-time support to the mocked hardware, how
does that fit into the run-time system for the native platform (your
workstation)?

Re: Getting started with bare-board development

[Jeffrey R. Carter]

On 11/13/2016 01:03 PM, Adam Jensen wrote:
>
> When writing device drivers, how do you mock the memory map of the
> target hardware?
>
> In the mocked the hardware, how is timing controlled?
>
> When extending and mapping run-time support to the mocked hardware, how
> does that fit into the run-time system for the native platform (your
> workstation)?

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.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Getting started with bare-board development

[Adam Jensen]

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?

Re: Getting started with bare-board development

[Paul Rubin]

Adam Jensen <hanzer@riseup.net> writes:
> 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.

If it were me, I'd set up the test harness with some kind of event queue
that would allow scheduling i/o completions, interrupts etc. to happen
at specified timestamps in the future.  Then when you run the test, only
the time ticks where something happens would get executed, without the
idle ticks causing any delays in the test.  The idea is you want your
tests to be fast even if the system being simulated is much slower.
That lets you run the tests more frequently, which is a good thing.

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

To me that sounds like a lot of work for the purpose of a news post.
You might look at some existing test framework (maybe not in Ada) and
some programs that use it.

Re: Getting started with bare-board development

[Adam Jensen]

On 11/14/2016 03:11 AM, Paul Rubin wrote:
> If it were me, I'd set up the test harness with some kind of event queue
> that would allow scheduling i/o completions, interrupts etc. to happen
> at specified timestamps in the future.  Then when you run the test, only
> the time ticks where something happens would get executed, without the
> idle ticks causing any delays in the test.  The idea is you want your
> tests to be fast even if the system being simulated is much slower.
> That lets you run the tests more frequently, which is a good thing.

Hi Paul, thanks for the hints. I'll probably need to continue my myopic
crawl through the LRM and the [(tragically) poorly written] Ada
programming textbooks before I can understand the implications and
subtleties of what you're suggesting. I think the consensus is that I
need to develop more information and understanding.

Re: Getting started with bare-board development

[Dmitry A. Kazakov]

On 13/11/2016 23:00, Adam Jensen wrote:

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

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.

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

Re: Getting started with bare-board development

[Adam Jensen]

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

Re: Getting started with bare-board development

[Dmitry A. Kazakov]

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

Re: Getting started with bare-board development

[Niklas Holsti]

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

Re: Getting started with bare-board development

[Adam Jensen]

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.

Re: Getting started with bare-board development

[Dmitry A. Kazakov]

On 2016-11-15 18:32, Adam Jensen wrote:

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

Of course it does. We use GNAT project files for this with scenario 
variables controlling the choice of the tool-chain (e.g. cross-compiler) 
and source code directories (to handle target dependencies). It works 
pretty well.

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

AdaCore did some good job abstracting basic hardware interfaces missing 
in the standard library. I mean sockets, OS basic I/O, COM ports.

Most of other things are either:

1. hardware-specific. These are a part of the developing itself. Thus we 
would likely have to mock/simulate them anyway.

2. domain-specific. These are abstracted by other means, by a middleware 
in my case. So in the end they don't hinder switching from the 
workstation to target and back.

In short, it is not that horrific or complicated as it appears.

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

Re: Getting started with bare-board development

[Jeffrey R. Carter]

On 11/13/2016 03:00 PM, Adam Jensen wrote:
>
> 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?

What you're asking for sounds like a small project in its own right; hardly 
suitable for a quick response on c.l.a. I'll see if I can come up with 
something, but don't hold your breath.

-- 
Jeff Carter
"Damn it, Jim, I'm an actor, not a doctor."
124

Re: Getting started with bare-board development

[Simon Wright]

Adam Jensen <hanzer@riseup.net> writes:

> * How does one develop and verify a Board Support Package (device
> drivers, bootloader, etc.)?

The Cortex-M4 boards developed for e.g.PixRacer[1], based on STM32F427,
support DFU[2] and JTAG.

Starting from AdaCore's STM32F429 offering, only a very few packages
need to be modified for the BSP: setting up the board's clocks to use a
24 MHz crystal rather than 8 MHz, and terminal i/o via UART7 rather than
USART1.

[1] https://pixhawk.org/modules/pixracer
[2] https://en.wikipedia.org/wiki/USB#Device_Firmware_Upgrade

> * Do the various typical embedded platform profiles (e.g., Ravenscar)
> require any Run-Time System implementation or extension?

Yes, indeed! you can see AdaCore's implementations at [3].

[3] https://github.com/AdaCore/embedded-runtimes

> * Is the BSP and RTS the kind of software that might/should be
> implemented in Spark?

AdaCore have certainly added pre- and post-conditions on a couple of the
tasking RTS components. My feeling is that it would be quite hard to
retrofit SPARK to their RTS. This may be conditioned by trying to use
SPARK to prove exception freedom for device drivers - but things like
volatility, pointers and time would be much better addressed in a
context that had budget for training and support.

Re: Getting started with bare-board development

[Adam Jensen]

Hi Simon, thanks for your input and the links.

On 11/14/2016 01:17 PM, Simon Wright wrote:
[snip]
> volatility, pointers and time would be much better addressed in a
> context that had budget for training and support.

Hey, that's a fun idea. Maybe rather than a budget for a few people to
toil at something that will have a short life, how about a more
sustainable system? First-pass desiderata for such a system:

* A method for harnessing human effort (users of the system) to
generate, maintain, and refine documentation such as:

* LRM, Rationale (writing style needs to be edited), tutorials, tech
notes, reference material, question/answer system (like Stack Exchange),
etc.

* A training system that generates meaningful programmer certifications.

* An integrated contractor system for software development projects.

* Various forms of integrated information/software review and
certification to maintain system integrity and qualify system output.

Re: Getting started with bare-board development

[Brian Drummond]

On Fri, 11 Nov 2016 17:19:33 -0500, Adam Jensen wrote:


> 
> Also, do ARM processors make sense for safety critical systems? If not,
> would it make more sense to target a different platform from the
> beginning?

Just to address this point : TI make two ARM processor families, the TI 
Hercules, aimed at safety critical applications.

They consist of dual ARMs in lockstep with comparators, (actually one 
operates 2 cycles behind the other, so that a glitch will affect 
different cycles on each) so that any difference between CPU behaviours 
will trap.

(What the trap handler does is up to your application, I presume)

One's aimed at automotive, the other at industrial, with slight 
differences in temperature range, on-chip peripherals, etc. 

There's a low cost Launchpad devboard for them.

-- Brian

Re: Getting started with bare-board development

[antispam]

Adam Jensen <hanzer@riseup.net> wrote:
> Hi, I've recently began to have a serious look at Ada-2012 and
> Spark-2014, and using GNAT for the development of real-time software in
> embedded systems.
<snip>
> Adacore has an example for the STM32F4-Discovery[3], and more elaborate
> documentation is available for the Nucleo[4], but both of those kits
> seem to have very limited memory. How much can be done with that?

Just to address this point: real time embedded systems are frequently
done with single chip microcontrollers.  Microcontroller contains
combinatorial logic (processor core, digital peripherials),
SRAM, flash and analog parts.  Having all this on single chip
brings substantial advantages.  But the drawback is that
various parts have conflicting manufacturing requirements.
So no part is as good as "pure" chip could be.  In particular,
microcontroller at lower end may have as little as 32 bytes
of RAM and at high end rarely go into megabyte range.
Basically, if you need more RAM you need to go into multi-chip
design with separate memory chip.  Then you can easily get
say 256 MB, but latency of external memory is much larger
than internal SRAM.  So while you may have plenty of
external memory program using it will run slower.  Worse,
high latency means that it is hard to give assurance
of real time behaviour.

STM32F4-Discovery contains relatively large microcontoller.
Nucleo boards have several versions containg both middle
sized and large microcontollers.

Note that flash is typically much larger than RAM, so
in fact you can have quite a lot functionalty inside
a single chip microcontroller.  When talking about
critical system I would say that modern microcontollers
give you quite a lot of space where bugs can hide.
In other words, to limit effort spent on validating
code you may wish to limit size of your system so
that in effect it fits in small device.

-- 
                              Waldek Hebisch

Re: Getting started with bare-board development

[Adam Jensen]

On 11/14/2016 08:14 PM, antispam@math.uni.wroc.pl wrote:
> Just to address this point: real time embedded systems are frequently
> done with single chip microcontrollers.  Microcontroller contains
> combinatorial logic (processor core, digital peripherials),

https://en.wikipedia.org/wiki/Combinational_logic
https://en.wikipedia.org/wiki/Combinatory_logic

> SRAM, flash and analog parts.  Having all this on single chip
> brings substantial advantages.  But the drawback is that
> various parts have conflicting manufacturing requirements.
> So no part is as good as "pure" chip could be.  In particular,

I'm inclined towards an approach that involves an FPGA such that signal
and control processing could take place in custom logic. Given that, it
might make sense [for me and my applications] to use a soft processor
core like the LEON3. With this approach, the peripheral components,
being implemented in the FPGA, could be selected and tuned specifically
for the application.

> microcontroller at lower end may have as little as 32 bytes
> of RAM and at high end rarely go into megabyte range.
> Basically, if you need more RAM you need to go into multi-chip
> design with separate memory chip.  Then you can easily get
> say 256 MB, but latency of external memory is much larger
> than internal SRAM.  So while you may have plenty of
> external memory program using it will run slower.  Worse,
> high latency means that it is hard to give assurance
> of real time behaviour.

Slow doesn't mean less deterministic, right?

> STM32F4-Discovery contains relatively large microcontoller.
> Nucleo boards have several versions containg both middle
> sized and large microcontollers.
> 
> Note that flash is typically much larger than RAM, so
> in fact you can have quite a lot functionalty inside
> a single chip microcontroller.  When talking about
> critical system I would say that modern microcontollers
> give you quite a lot of space where bugs can hide.
> In other words, to limit effort spent on validating
> code you may wish to limit size of your system so
> that in effect it fits in small device.

Do you have any estimates and/or examples of how much flash
and RAM are required/used for various run-time profiles and
programs of varying complexity?

Re: Getting started with bare-board development

[antispam]

Adam Jensen <hanzer@riseup.net> wrote:
> On 11/14/2016 08:14 PM, antispam@math.uni.wroc.pl wrote:
> > Just to address this point: real time embedded systems are frequently
> > done with single chip microcontrollers.  Microcontroller contains
> > combinatorial logic (processor core, digital peripherials),
> 
> https://en.wikipedia.org/wiki/Combinational_logic
> https://en.wikipedia.org/wiki/Combinatory_logic
> 
> > SRAM, flash and analog parts.  Having all this on single chip
> > brings substantial advantages.  But the drawback is that
> > various parts have conflicting manufacturing requirements.
> > So no part is as good as "pure" chip could be.  In particular,
> 
> I'm inclined towards an approach that involves an FPGA such that signal
> and control processing could take place in custom logic. Given that, it
> might make sense [for me and my applications] to use a soft processor
> core like the LEON3. With this approach, the peripheral components,
> being implemented in the FPGA, could be selected and tuned specifically
> for the application.

Yes, that is valid approach.  But there are also limitations.
IIUC FPGA-s have no analog parts.  Frequently (always???) flash
is external.  Prices seem to be high.  And soft processors
seem to have rather unimpressive parameters -- they are good
if you have modes need for processor power and have some
free space in FPGA that you need for other reasons.  But
if all functions could be done by existing hard processor,
then soft processor just adds cost.

> > microcontroller at lower end may have as little as 32 bytes
> > of RAM and at high end rarely go into megabyte range.
> > Basically, if you need more RAM you need to go into multi-chip
> > design with separate memory chip.  Then you can easily get
> > say 256 MB, but latency of external memory is much larger
> > than internal SRAM.  So while you may have plenty of
> > external memory program using it will run slower.  Worse,
> > high latency means that it is hard to give assurance
> > of real time behaviour.
> 
> Slow doesn't mean less deterministic, right?

Well, smallest and slowest MCU-s tend to be the most
deterministic ones.  But common DRAM timing means that you
need processor with clock significantly faster than DRAM
latency.  So usualy DRAM is used together with caches
and determinism iss lost: mostly access is quite fast
but sometimes gets much slower.

> > STM32F4-Discovery contains relatively large microcontoller.
> > Nucleo boards have several versions containg both middle
> > sized and large microcontollers.
> > 
> > Note that flash is typically much larger than RAM, so
> > in fact you can have quite a lot functionalty inside
> > a single chip microcontroller.  When talking about
> > critical system I would say that modern microcontollers
> > give you quite a lot of space where bugs can hide.
> > In other words, to limit effort spent on validating
> > code you may wish to limit size of your system so
> > that in effect it fits in small device.
> 
> Do you have any estimates and/or examples of how much flash
> and RAM are required/used for various run-time profiles and
> programs of varying complexity?

ATM I have examples in C.  On STM Cortex-M0 (STM32F030) "do nothing"
bare-bone program is about 392 bytes of flash and uses single
word (4 bytes) of stack (and no RAM otherwise) -- that basically measures
fixed overhead payed by all programs.  Blinking LED program
using 552 bytes of flash (and no RAM beside stack) when using
defult clock frequency, 1028 bytes flash and 8 bytes of RAM
when using a library to configure processor clock to 48 MHz
and 684 bytes flash when clock is configured via port access.
With extra 100 bytes of flash one gets various simple gadgets
that flash LED-s in response to button presses.  One needs
about 1000 bytes of flash to handle few digits LED display
using funky serial protocol for communication (+ 1000 bytes
of common overhead/setup).  About 400 bytes for interrupt
driven serial transmission.  About 1000 bytes to setup and
use ADC.  About 650 bytes to drive monochrome graphic LCD
via polling SPI interface, about 900 the same using DMA
chanell (that uses about 149 bytes of RAM, including
84 byte buffer for DMA transfer).  PetitFS (FAT filesystem
used on SD cards) is about 1500 bytes of flash.  RAM usage
of PetitFS is normally dominated by two 512 byte sector
buffers.  TinyOS (tasks with preemptive scheduler, ques
and semaphores -- IIUC this is more or less what Ravenscar
offers) is slightly less than 8 kB of flash.
Libmaple library (Arduino style library which contains
drivers for most devices in STM32F103) is about 20 kB.
Several devices (like fast battery charger with modes
for various kinds of batteris and a lot of user settings)
use STM32F103C8 which is 72 MHz Cortex-M3 with 20 kB of RAM
and 64kB of flash.  IIRC to send and receive Enhernet
packet via extenal Ethernet chip one need about 4 kB
of code.  To implement "full" TCP/IP stack one needs
about 80kB of code (and probaly at least 40 kB of
RAM for buffering).  If you want to add fancy GUI to
embedded system you may need copy of the screen in RAM,
which will take something between tens of kilobyte and
megabytes.  If you are building sampling osciloscope,
then you need sample buffer -- while 10-20 kB may
work you can offer extra features with large buffers
(say hundreds of megbytes or more).

Much depends on problem and strategy used for solution.  For
example, for simple messaging 16 byte serial buffer may be
enough.  OTOH to transfer large amounts of data concurrently
with higher priority tasks one may want bigger buffers, say
2kB.  If you have 8 serial ports and allocate 2kB buffer
for each serial port (which naive serial library may do)
you get 16 kB, which may be large portion of available
RAM (such thing happened on MCU with 32 kB of RAM and
8 serial ports).  On PC-s there is tendency to use very
large buffers to minimize cost of context switches.
MCU-s tend to have smaller context and fast context swiches,
so buffers may be smaller.  Also, control messages
frequently are small.

-- 
                              Waldek Hebisch

Re: Getting started with bare-board development

[Robert Eachus]

On Friday, November 11, 2016 at 5:19:35 PM UTC-5, Adam Jensen wrote:
> Hi, I've recently began to have a serious look at Ada-2012 and
> Spark-2014, and using GNAT for the development of real-time software in
> embedded systems. What is a good way to get started?
... 
> Also, do ARM processors make sense for safety critical systems? If not,
> would it make more sense to target a different platform from the beginning?

Just a couple of reminders that you may want to put on your screen saver, or a plaque above your desk:

Make it run, then make it right, then make it fast [Kent Beck]

Premature optimization is the root of all evil [Donald Knuth]

Moving from hardware to software, or mixing them together, it is sometimes hard to remember this key to software development. With Ada you are best off pulling any interface or (software) algorithm into a package.  Sometimes a package you create this way will be implemented by interfacing to a library package, from the Ada RM, the device manufacturer, or a code repository.  Let the compiler do the hard work of eliminating unused code, call throughs, and inlining a short procedures and functions. You will be amazed at the small ratio between lines of source code (SLOC) and the size in bytes of the resulting hardware module.  (Don't forget to strip out the debugging support, enumeration literals, etc., before measuring. ;-)

Re: Getting started with bare-board development

[Adam Jensen]

On 11/15/2016 02:34 PM, Robert Eachus wrote:
> Just a couple of reminders that you may want to put on your screen saver, or a plaque above your desk:
> 
> Make it run, then make it right, then make it fast [Kent Beck]
> 
> Premature optimization is the root of all evil [Donald Knuth]
> 
> Moving from hardware to software, or mixing them together, it is sometimes hard to remember this key to software development. With Ada you are best off pulling any interface or (software) algorithm into a package.  Sometimes a package you create this way will be implemented by interfacing to a library package, from the Ada RM, the device manufacturer, or a code repository.  Let the compiler do the hard work of eliminating unused code, call throughs, and inlining a short procedures and functions. You will be amazed at the small ratio between lines of source code (SLOC) and the size in bytes of the resulting hardware module.  (Don't forget to strip out the debugging support, enumeration literals, etc., before measuring. ;-)

I am well steeped in the Tao of Unix[1..4], but I don't think I would
apply a bottom-up approach to high assurance system development if I
didn't have to [5]; and for the system I have in mind, I don't have to
[6] <smirk>.

[1]: http://recycle.lbl.gov/~ldoolitt/unix.tao.txt
[2]: https://gist.github.com/wmayner/d3a0ebf059982abbe3ad
[3]: http://catb.org/~esr/writings/taoup/
[4]: http://huffman.sourceforge.net/tao/tao-of-programming.html
[5]: http://recklessabandonlabs.com/img/logo.png
[6]: https://youtu.be/gQxke0REFMA