Re: Point a beginner in the right direction? Cheap bare-board to run with a RTOS for running ADA

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 07 Jul 2013 19:27:34 +0300, Niklas Holsti wrote:

> On 13-07-07 18:00 , Dmitry A. Kazakov wrote:
>> On Sun, 7 Jul 2013 10:58:24 +0000 (UTC), Simon Clubley wrote:
>> 
>>> On 2013-07-07, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> On Sun, 7 Jul 2013 02:16:29 -0700 (PDT), Lucretia wrote:
>>>>
>>>>> Why not just buy a small SBC and just target Ada directly on the hardware.
>>>>> You don't have to have an OS at all.
>>>>
>>>> There exist heaters better than a computer performing pointless
>>>> calculations without any I/O.
>>>
>>> Sorry, Dmitry, but that's so out of touch I don't really know how to
>>> respond so I will just say you don't need a OS to provide I/O services.
>>>
>>> You create some routines around the hardware which the rest of your code
>>> can use to talk to the hardware and you structure your I/O support
>>> library so that only the modules needed by the application are actually
>>> linked in.
>> 
>> And this is what basically an OS is - a set of routines around the
>> hardware.
>> 
>> Either the application does nothing beyond integer arithmetic or else you
>> need an OS. Even most simple things like FPU or system timers would require
>> functionality attributed to an OS.
> 
> Many years ago I wrote an application for an HP2100 mini, sampling a
> voltage continuously at 1 kHz, writing the data to magnetic tape, and
> printing summaries to the console.

Many years ago almost all I/O was done through dual ported memory. These
days are long behind. BTW, RT-11 ran on 32K machines. It was an OS.

> If I take Dmitry's view, I am now entitled to put on my CV that I wrote
> my own OS for this application. Great.

It depends on the complexity. There is no sharp margin, obviously.

> Dmitry, your definition of I/O routines as "an OS" is an absurd stretch.

I only said that *modern* hardware is not so simple to access as in the
times when it was one or two memory-mapped hardware registers at fixed
addresses. Even a "small" SBC is far more complex than any old mainframe
was.

>> and
>> extremely complicated software protocols like TCP and stuff upon it.
> 
> Which are available as OS-independent libraries.

OS-independent /= OS-less.

You will need interrupts, you will need tasking you will need real-time
clock.

Of course, it would be possible to implement ad-hoc kludges to handle any
of this. But the result will be so fragile that any small changes in the
application will require redesigning the "OS". It is simply not the Ada way
(TM). Not even much the C way any more.

I just do not understand the gain. What is simpler to port the Ada RTL onto
a bare metal or onto an OS? How on earth people considering the second too
difficult are ready and willing to rush into the first? Don't tell me they
know for certain how much of the RTL they will have to implement.

>> The
>> question is only who is going to write and maintain all this stuff.
>> 
>> Just which is the ratio of he application code to "some routines around the
>> hardware"? 1:0? 1:1? 1:1000? How about complexity of both?
> 
> But the application-specific I/O should really count as "application code".

Yes, but application-specific I/O is done on top of non-specific I/O. E.g.
on top of the TCP/IP stack or on top of the FAT32 file system etc. And for
an embedded application the specific part is minimal. If not, then see
above.

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