Re: Getting started with bare-board development

[artium@nihamkin.com]

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.