Would this be logical for embedded hardware?

Would this be logical for embedded hardware?

[Patrick]

I have come up with a design layout that I did not read about elsewhere and that worries me! Please read this and possibly save me from my own stupidity.

A little background...

I want to use Ada for several things but a key one is to design a scientific instrument. I was drawn to Ada in late 2011 because it has a rich set of features to make embedded design easier and by it's strict compiler. 

I don't think Ada is hard to develop in but I actually don't care, above all else, I want to ship as few bugs as I possibly can. I have next to no experience with embedded design and I do not have decades of experience with desktop programming either. Ada's compiler could really help someone like me.

A couple months ago I was disheartened to learn that my assumptions about Ada running on bare metal were false. GNAT does not have the ability to target all the devices GCC supports while still offering a full Ada implementation.

I have been trying to find a RTOS to partner with Ada but there is a dizzying array of them. It seems like the ones held in highest regard are closed source and expensive. I also don't have hard deadlines, near realtime is just fine. Linux would be fine but I can't imagine fitting it on a device and still having enough GPIO lines left over to do what I want with.

One of the things that appeals most to me with Ada is tasking. It seems like a good way to compartmentalize complexity. I can't visualize how to do this in C.

With those items in mind, here is what I was thinking.... 32 bit microcontrollers are dirt cheap and many come with ethernet built in and TCP/IP libraries.

If I broke the instrument down in to various modules, keypad, computer-controlled power supply, optical system, detector etc. I could assign a microcontroller to each module and program that MCU in C. The C program could pretty much do one thing only. 

I could use a Linux single board computer(maybe something like Raspberry PI) and some sort of router to communicate with the various MCU C modules. Ada Tasking on the Linux SBC would give me a logical way to control them and the bulk of the full system's logic could be in Ada,  Ada would also give me exceptions if something goes wrong.

If I used ethernet instead of SPI or CAN bus, I could control all the C MCUs using a plain Linux desktop and then add in the Linux SBC at the end.

Does this seem logical?-Patrick

Re: Would this be logical for embedded hardware?

[Jeffrey Carter]

On 06/28/2012 04:54 PM, Patrick wrote:
>
> I have been trying to find a RTOS to partner with Ada but there is a dizzying
> array of them. It seems like the ones held in highest regard are closed
> source and expensive. I also don't have hard deadlines, near realtime is just
> fine. Linux would be fine but I can't imagine fitting it on a device and
> still having enough GPIO lines left over to do what I want with.

This sounds like what was commonly heard about Ada-83 tasking: it won't be fast 
enough, or will use too much memory/CPU/whatever, so we won't use it and will 
write a cyclic executive instead. Those who actually used tasks usually found 
them that they worked fine, and resulted in a much simpler design as well. So 
don't write off something that would be "fine" without substantiation.

> With those items in mind, here is what I was thinking.... 32 bit
> microcontrollers are dirt cheap and many come with ethernet built in and
> TCP/IP libraries.
>
> If I broke the instrument down in to various modules, keypad,
> computer-controlled power supply, optical system, detector etc. I could
> assign a microcontroller to each module and program that MCU in C. The C
> program could pretty much do one thing only.

I've worked on embedded systems like this (multiple networked 32-bit 
processors), but they were all developed in Ada. I don't see why you couldn't 
use Ada for all the processors in your system, too. And you could look into 
SoftTech's compiler that generates C if you have difficulty finding an Ada 
compiler targeting your processor of choice.

-- 
Jeff Carter
"Have you gone berserk? Can't you see that that man is a ni?"
Blazing Saddles
38



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Would this be logical for embedded hardware?

[Patrick]

Hi Jeffery
> 
> This sounds like what was commonly heard about Ada-83 tasking: it won't be fast 
> enough, or will use too much memory/CPU/whatever, so we won't use it and will 
> write a cyclic executive instead. Those who actually used tasks usually found 
> them that they worked fine, and resulted in a much simpler design as well. So 
> don't write off something that would be "fine" without substantiation.
> 
I really wasn't trying to trash Ada in anyway

> 
> I've worked on embedded systems like this (multiple networked 32-bit 
> processors), but they were all developed in Ada. I don't see why you couldn't 
> use Ada for all the processors in your system, too. And you could look into 
> SoftTech's compiler that generates C if you have difficulty finding an Ada 
> compiler targeting your processor of choice.

I couldn't actually find a company called SoftTech that had compilers. This  name is used by many companies.

Could you point me to their site?

Thanks for the feedback-Patrick

Re: Would this be logical for embedded hardware?

[Niklas Holsti]

On 12-06-29 18:37 , Patrick wrote:
> Hi Jeffery
>>
>> This sounds like what was commonly heard about Ada-83 tasking: it won't be fast
>> enough, or will use too much memory/CPU/whatever, so we won't use it and will
>> write a cyclic executive instead. Those who actually used tasks usually found
>> them that they worked fine, and resulted in a much simpler design as well. So
>> don't write off something that would be "fine" without substantiation.
>>
> I really wasn't trying to trash Ada in anyway
>
>>
>> I've worked on embedded systems like this (multiple networked 32-bit
>> processors), but they were all developed in Ada. I don't see why you couldn't
>> use Ada for all the processors in your system, too. And you could look into
>> SoftTech's compiler that generates C if you have difficulty finding an Ada
>> compiler targeting your processor of choice.
>
> I couldn't actually find a company called SoftTech that had compilers. This  name is used by many companies.
>
> Could you point me to their site?

It's SofCheck, but they merged with AdaCore recently. The compiler is, 
or was, AdaMagic, http://en.wikipedia.org/wiki/AdaMagic. Hopefully it is 
still available...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Would this be logical for embedded hardware?

[Jeffrey Carter]

On 06/29/2012 08:37 AM, Patrick wrote:
>>
> I really wasn't trying to trash Ada in anyway

I was referring to rejecting Linux out of hand.

> I couldn't actually find a company called SoftTech that had compilers. This  name is used by many companies.

That's because I made an error; they were called SofCheck. Earlier this year 
they merged with AdaCore.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail
23



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Would this be logical for embedded hardware?

[Jacob Sparre Andersen]

Niklas Holsti wrote:

> It's SofCheck, but they merged with AdaCore recently. The compiler is,
> or was, AdaMagic, http://en.wikipedia.org/wiki/AdaMagic. Hopefully it
> is still available...

According to my sources it is still available.

Greetings,

Jacob
-- 
"Reality is that which, when you stop believing in it, 
 doesn't go away."

Re: Would this be logical for embedded hardware?

[Austin Obyrne]

On Friday, June 29, 2012 12:54:25 AM UTC+1, Patrick wrote:
> I have come up with a design layout that I did not read about elsewhere and that worries me! Please read this and possibly save me from my own stupidity.
> 
> A little background...
> 
> I want to use Ada for several things but a key one is to design a scientific instrument. I was drawn to Ada in late 2011 because it has a rich set of features to make embedded design easier and by it's strict compiler. 
> 
> I don't think Ada is hard to develop in but I actually don't care, above all else, I want to ship as few bugs as I possibly can. I have next to no experience with embedded design and I do not have decades of experience with desktop programming either. Ada's compiler could really help someone like me.
> 
> A couple months ago I was disheartened to learn that my assumptions about Ada running on bare metal were false. GNAT does not have the ability to target all the devices GCC supports while still offering a full Ada implementation.
> 
> I have been trying to find a RTOS to partner with Ada but there is a dizzying array of them. It seems like the ones held in highest regard are closed source and expensive. I also don't have hard deadlines, near realtime is just fine. Linux would be fine but I can't imagine fitting it on a device and still having enough GPIO lines left over to do what I want with.
> 
> One of the things that appeals most to me with Ada is tasking. It seems like a good way to compartmentalize complexity. I can't visualize how to do this in C.
> 
> With those items in mind, here is what I was thinking.... 32 bit microcontrollers are dirt cheap and many come with ethernet built in and TCP/IP libraries.
> 
> If I broke the instrument down in to various modules, keypad, computer-controlled power supply, optical system, detector etc. I could assign a microcontroller to each module and program that MCU in C. The C program could pretty much do one thing only. 
> 
> I could use a Linux single board computer(maybe something like Raspberry PI) and some sort of router to communicate with the various MCU C modules. Ada Tasking on the Linux SBC would give me a logical way to control them and the bulk of the full system's logic could be in Ada,  Ada would also give me exceptions if something goes wrong.
> 
> If I used ethernet instead of SPI or CAN bus, I could control all the C MCUs using a plain Linux desktop and then add in the Linux SBC at the end.
> 
> Does this seem logical?-Patrick

Can I slap my soul on the table here and say I am not at all sure what an embedded system really means - as an engineer I immediately envisage some piece of equipment that is triggered into action by a controlling signal that then runs the equipment according to the embedded sytem algorithm.  The most dramatic one I can think of is say putting down the landing gear of an aircraft (that I happen to be on) just when it is needed and the extremme case also of launching a nuclear weapon say.

But there is another instance also that I am not at all sure about and that is an embedded program within a piece of software written in the same language or even a different language - is this just a figment of my imagination or does it exist - even under another name = like say a task package?

Your help would be greatly appreciated.

I see myself as an amateur programmer only.

Austin O'Byrne

Re: Would this be logical for embedded hardware?

[Simon Wright]

Austin Obyrne <austin.obyrne@hotmail.com> writes:

> Can I slap my soul on the table here and say I am not at all sure what
> an embedded system really means - as an engineer I immediately
> envisage some piece of equipment that is triggered into action by a
> controlling signal that then runs the equipment according to the
> embedded sytem algorithm.  The most dramatic one I can think of is say
> putting down the landing gear of an aircraft (that I happen to be on)
> just when it is needed and the extremme case also of launching a
> nuclear weapon say.

In an Ada context, "embedded system" would almost always mean this sort
of system.

> But there is another instance also that I am not at all sure about and
> that is an embedded program within a piece of software written in the
> same language or even a different language - is this just a figment of
> my imagination or does it exist - even under another name = like say a
> task package?

This too is possible, though less common.

As an example, TclAdaShell[1] allows you to embed a Tcl interpreter in
an Ada program. 

I've used this to provide a functional testbed; I made the
software-under-tests's services and dependencies visible from Ada, and
the test scripts were written in Tcl. This was highly cost-effective.

Another use might be to use Tk to implement the GUI of an Ada program.

I would never refer to this kind of system as "embedded", though.

[1] http://tcladashell.sf.net

Re: Would this be logical for embedded hardware?

[Austin Obyrne]

On Monday, July 2, 2012 12:19:36 PM UTC+1, Simon Wright wrote:
> Austin Obyrne <austin.obyrne@hotmail.com> writes:
> 
> > Can I slap my soul on the table here and say I am not at all sure what
> > an embedded system really means - as an engineer I immediately
> > envisage some piece of equipment that is triggered into action by a
> > controlling signal that then runs the equipment according to the
> > embedded sytem algorithm.  The most dramatic one I can think of is say
> > putting down the landing gear of an aircraft (that I happen to be on)
> > just when it is needed and the extremme case also of launching a
> > nuclear weapon say.
> 
> In an Ada context, "embedded system" would almost always mean this sort
> of system.
> 
> > But there is another instance also that I am not at all sure about and
> > that is an embedded program within a piece of software written in the
> > same language or even a different language - is this just a figment of
> > my imagination or does it exist - even under another name = like say a
> > task package?
> 
> This too is possible, though less common.
> 
> As an example, TclAdaShell[1] allows you to embed a Tcl interpreter in
> an Ada program. 
> 
> I've used this to provide a functional testbed; I made the
> software-under-tests's services and dependencies visible from Ada, and
> the test scripts were written in Tcl. This was highly cost-effective.
> 
> Another use might be to use Tk to implement the GUI of an Ada program.
> 
> I would never refer to this kind of system as "embedded", though.
> 
> [1] http://tcladashell.sf.net

Many Thanks - Austin