Ada.Interrpts.Names

Ada.Interrpts.Names

[lyttlec]

Under Ubuntu Linux kill -l lists interrupts including SIGRTMIN and
SIGRTMAX. However, gnat a-intnam.ads does not have these, nor does the
Ada ARM toolchain. Is there a way to use these interrupts?

Re: Ada.Interrpts.Names

[Simon Wright]

lyttlec <lyttlec@removegmail.com> writes:

> Under Ubuntu Linux kill -l lists interrupts including SIGRTMIN and
> SIGRTMAX. However, gnat a-intnam.ads does not have these, nor does the
> Ada ARM toolchain. Is there a way to use these interrupts?

Looks as though Interrupt_ID is visibly a numeric type, so you could
just use the number (so long as it's less than (what on Darwin is)
System.OS_Interface.Max_Interrupt). Whether the RTS will actually
respond to the signal in a useful way is another matter. Again,
System.OS_Interface should offer a clue.

Re: Ada.Interrpts.Names

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> lyttlec <lyttlec@removegmail.com> writes:
>
>> Under Ubuntu Linux kill -l lists interrupts including SIGRTMIN and
>> SIGRTMAX. However, gnat a-intnam.ads does not have these, nor does the
>> Ada ARM toolchain. Is there a way to use these interrupts?
>
> Looks as though Interrupt_ID is visibly a numeric type, so you could
> just use the number (so long as it's less than (what on Darwin is)
> System.OS_Interface.Max_Interrupt). Whether the RTS will actually
> respond to the signal in a useful way is another matter. Again,
> System.OS_Interface should offer a clue.

Via mail (better to use the newsgroup!) you said

> I tried that and the program in Chap.4 of "Building Parallel,
> Embedded, and Real-Time Applications with Ada" compiles.  The question
> is whether or not that is the only thing required to get a meaningful
> response?
> The "C" process is quiet complex.
> In Ada it looks like it might be as simple as editing a-intnam.ads,
> s-osinte.ads, and s-linux.ads. Or a lot more complex, like the methods
> for AVR-Ada.

I don't know, because I don't run Linux as my main development
environment.

Your best bet, I'd've thought, would be to write a very simple program
just to catch that signal (i.e. a PO interrupt handler) using the raw
integer and see if it works. If it doesn't, you'd probably have a long
row to hoe. If it does, you can consider whether it's worth the pain of
editing Ada.Interrupts.Names, otherwise, in your code, (e.g.)

   SIGRTMIN : constant Ada.Interrupts.Interrupt_ID := 42; -- or whatever

Re: Ada.Interrpts.Names

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Your best bet, I'd've thought, would be to write a very simple program
> just to catch that signal (i.e. a PO interrupt handler) using the raw
> integer and see if it works. If it doesn't, you'd probably have a long
> row to hoe. If it does, you can consider whether it's worth the pain of
> editing Ada.Interrupts.Names, otherwise, in your code, (e.g.)
>
>    SIGRTMIN : constant Ada.Interrupts.Interrupt_ID := 42; -- or whatever

There may, of course, be some interaction of these signals with the Ada
RTS that explains why they're omitted from Ada.Interrupts.Names.

Re: Ada.Interrpts.Names

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

>> I tried that and the program in Chap.4 of "Building Parallel,
>> Embedded, and Real-Time Applications with Ada" compiles.

That's one expensive book! £80 or thereabouts.

Re: Ada.Interrpts.Names

[lyttlec]

On 1/29/19 9:32 AM, Simon Wright wrote:
> Simon Wright <simon@pushface.org> writes:
> 
>>> I tried that and the program in Chap.4 of "Building Parallel,
>>> Embedded, and Real-Time Applications with Ada" compiles.
> 
> That's one expensive book! £80 or thereabouts.
> 
So far it has been worth it. On the plus side, the examples are usually
easy to turn into running programs; and it does have a lot of good
hints. But it does stop just short of what is needed to develop a real
program. E.G., it needs a specific chapter on targeting systems with no OS.

Re: Ada.Interrpts.Names

[Dennis Lee Bieber]

On Wed, 30 Jan 2019 09:29:08 -0500, lyttlec <lyttlec@removegmail.com>
declaimed the following:

>On 1/29/19 9:32 AM, Simon Wright wrote:
>> Simon Wright <simon@pushface.org> writes:
>> 
>>>> I tried that and the program in Chap.4 of "Building Parallel,
>>>> Embedded, and Real-Time Applications with Ada" compiles.
>> 
>> That's one expensive book! £80 or thereabouts.
>> 
>So far it has been worth it. On the plus side, the examples are usually
>easy to turn into running programs; and it does have a lot of good
>hints. But it does stop just short of what is needed to develop a real
>program. E.G., it needs a specific chapter on targeting systems with no OS.

	Given how that is so processor/board specific that subject may be
better met using "Ada and SPARK on ARM Cortex-M" -- even though that is
focused on ARM processors (Arduino Due and some Nucleo boards. {Note: if
buying the Lulu print-on-demand copy, be advised that [based on my copy]
many of the diagrams didn't transfer -- I still need to cut and paste
figures 4, 5, and 6}. {I'd love to see the TIVA C launchpads included}


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/ 

Re: Ada.Interrpts.Names

[lyttlec]

On 1/30/19 3:43 PM, Dennis Lee Bieber wrote:
> On Wed, 30 Jan 2019 09:29:08 -0500, lyttlec <lyttlec@removegmail.com>
> declaimed the following:
> 
>> On 1/29/19 9:32 AM, Simon Wright wrote:
>>> Simon Wright <simon@pushface.org> writes:
>>>
>>>>> I tried that and the program in Chap.4 of "Building Parallel,
>>>>> Embedded, and Real-Time Applications with Ada" compiles.
>>>
>>> That's one expensive book! £80 or thereabouts.
>>>
>> So far it has been worth it. On the plus side, the examples are usually
>> easy to turn into running programs; and it does have a lot of good
>> hints. But it does stop just short of what is needed to develop a real
>> program. E.G., it needs a specific chapter on targeting systems with no OS.
> 
> 	Given how that is so processor/board specific that subject may be
> better met using "Ada and SPARK on ARM Cortex-M" -- even though that is
> focused on ARM processors (Arduino Due and some Nucleo boards. {Note: if
> buying the Lulu print-on-demand copy, be advised that [based on my copy]
> many of the diagrams didn't transfer -- I still need to cut and paste
> figures 4, 5, and 6}. {I'd love to see the TIVA C launchpads included}
> 
> 
Thanks for the tip. The web version looks handy. So far it seems that
the techniques used by  Sobczak for Arm are similar to those used on
Intel and AMD based PCs, and on other mpu. I'm pretty sure on the PC
side there is also a .vectors table to be modified.