Interruption Handling using zfp compilation flag

Interruption Handling using zfp compilation flag

[Vinícius Franchini]

Hi guys,
 my name is Vinícius and I'm doing a master degree. My thesis is a simplified on-board computer for an satellite. I must implement some scheduling and package analysis functions. As I need to work with a real time system, I'm using the zfp flag for compilation. I tried to implement some interruptions using sentences like this:

   procedure Receive_USART;

   -- Address the interruption handler		
   pragma Machine_Attribute (Entity => Receive_USART,
                             Attribute_Name => "signal");

   pragma Export (Convention    => C,
                  Entity        => Receive_USART,
                  External_Name => "__vector_26");    --USART0_RXC

Using Proteus (ISIS Professional 6.7 SP2), I'm debugging the algorithm. The initialization of the interruption is right, but when the interruption occur, it isn't handling to the procedure. 

Do I need to do something more to handle the procedure when the interruption occur ? Do you fellows have any other simple way to handle interruptions ?

Thanks very much for your help....

Re: Interruption Handling using zfp compilation flag

[Rolf]

On Friday, December 7, 2012 1:41:34 AM UTC+1, Vinícius Franchini wrote:
> Hi guys, my name is Vinícius and I'm doing a master degree. My thesis is a simplified on-board computer for an satellite. I must implement some scheduling and package analysis functions. As I need to work with a real time system, I'm using the zfp flag for compilation. I tried to implement some interruptions using sentences like this: procedure Receive_USART; -- Address the interruption handler pragma Machine_Attribute (Entity => Receive_USART, Attribute_Name => "signal"); pragma Export (Convention => C, Entity => Receive_USART, External_Name => "__vector_26"); --USART0_RXC Using Proteus (ISIS Professional 6.7 SP2), I'm debugging the algorithm. The initialization of the interruption is right, but when the interruption occur, it isn't handling to the procedure. Do I need to do something more to handle the procedure when the interruption occur ? Do you fellows have any other simple way to handle interruptions ? Thanks very much for your help....



On Friday, December 7, 2012 1:41:34 AM UTC+1, Vinícius Franchini wrote:
> Hi guys, my name is Vinícius and I'm doing a master degree. My thesis is a simplified on-board computer for an satellite. I must implement some scheduling and package analysis functions. As I need to work with a real time system, I'm using the zfp flag for compilation. I tried to implement some interruptions using sentences like this: procedure Receive_USART; -- Address the interruption handler pragma Machine_Attribute (Entity => Receive_USART, Attribute_Name => "signal"); pragma Export (Convention => C, Entity => Receive_USART, External_Name => "__vector_26"); --USART0_RXC Using Proteus (ISIS Professional 6.7 SP2), I'm debugging the algorithm. The initialization of the interruption is right, but when the interruption occur, it isn't handling to the procedure. Do I need to do something more to handle the procedure when the interruption occur ? Do you fellows have any other simple way to handle interruptions ? Thanks very much for your help....



The syntax that you show is very specific for AVR microcontrollers. If that's really the case have a look at

http://sourceforge.net/p/avr-ada/wiki/Interrupts/

and at the data sheet of your controller. Consider also asking on the AVR-Ada-devel mailing list.

HTH
    Rolf

Re: Interruption Handling using zfp compilation flag

[Vinícius Franchini]

On Friday, December 7, 2012 5:45:51 AM UTC-2, Rolf wrote:
> On Friday, December 7, 2012 1:41:34 AM UTC+1, Vinícius Franchini wrote:
> 
> > Hi guys, my name is Vinícius and I'm doing a master degree. My thesis is a simplified on-board computer for an satellite. I must implement some scheduling and package analysis functions. As I need to work with a real time system, I'm using the zfp flag for compilation. I tried to implement some interruptions using sentences like this: procedure Receive_USART; -- Address the interruption handler pragma Machine_Attribute (Entity => Receive_USART, Attribute_Name => "signal"); pragma Export (Convention => C, Entity => Receive_USART, External_Name => "__vector_26"); --USART0_RXC Using Proteus (ISIS Professional 6.7 SP2), I'm debugging the algorithm. The initialization of the interruption is right, but when the interruption occur, it isn't handling to the procedure. Do I need to do something more to handle the procedure when the interruption occur ? Do you fellows have any other simple way to handle interruptions ? Thanks very much for your help....
> 
> 
> 
> 
> 
> 
> 
> On Friday, December 7, 2012 1:41:34 AM UTC+1, Vinícius Franchini wrote:
> 
> > Hi guys, my name is Vinícius and I'm doing a master degree. My thesis is a simplified on-board computer for an satellite. I must implement some scheduling and package analysis functions. As I need to work with a real time system, I'm using the zfp flag for compilation. I tried to implement some interruptions using sentences like this: procedure Receive_USART; -- Address the interruption handler pragma Machine_Attribute (Entity => Receive_USART, Attribute_Name => "signal"); pragma Export (Convention => C, Entity => Receive_USART, External_Name => "__vector_26"); --USART0_RXC Using Proteus (ISIS Professional 6.7 SP2), I'm debugging the algorithm. The initialization of the interruption is right, but when the interruption occur, it isn't handling to the procedure. Do I need to do something more to handle the procedure when the interruption occur ? Do you fellows have any other simple way to handle interruptions ? Thanks very much for your help....
> 
> 
> 
> 
> 
> 
> 
> The syntax that you show is very specific for AVR microcontrollers. If that's really the case have a look at
> 
> 
> 
> http://sourceforge.net/p/avr-ada/wiki/Interrupts/
> 
> 
> 
> and at the data sheet of your controller. Consider also asking on the AVR-Ada-devel mailing list.
> 
> 
> 
> HTH
> 
>     Rolf

 Thanks for your advice and sorry for incomplete information.

 I'm using an AVR ATMega 2560. I'm not using the avr-ada lib. The way I'm doing the interruptions is just like the link you sent. The interruption is ok, the used vector is in accordance with the enabled interrupt, as I saw in my debug. The problem is: the handled procedure is not called when the interruption ocur.

As I tried to summarize, this is my question...

Re: Interruption Handling using zfp compilation flag

[Rolf]

On Friday, December 7, 2012 9:24:38 PM UTC+1, Vinícius Franchini wrote:
> On Friday, December 7, 2012 5:45:51 AM UTC-2, Rolf wrote:
> 
> > On Friday, December 7, 2012 1:41:34 AM UTC+1, Vinícius Franchini wrote:
> 
> > 
> 
> > > Hi guys, my name is Vinícius and I'm doing a master degree. My thesis is a simplified on-board computer for an satellite. I must implement some scheduling and package analysis functions. As I need to work with a real time system, I'm using the zfp flag for compilation. I tried to implement some interruptions using sentences like this: procedure Receive_USART; -- Address the interruption handler pragma Machine_Attribute (Entity => Receive_USART, Attribute_Name => "signal"); pragma Export (Convention => C, Entity => Receive_USART, External_Name => "__vector_26"); --USART0_RXC Using Proteus (ISIS Professional 6.7 SP2), I'm debugging the algorithm. The initialization of the interruption is right, but when the interruption occur, it isn't handling to the procedure. Do I need to do something more to handle the procedure when the interruption occur ? Do you fellows have any other simple way to handle interruptions ? Thanks very much for your help....
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > On Friday, December 7, 2012 1:41:34 AM UTC+1, Vinícius Franchini wrote:
> 
> > 
> 
> > > Hi guys, my name is Vinícius and I'm doing a master degree. My thesis is a simplified on-board computer for an satellite. I must implement some scheduling and package analysis functions. As I need to work with a real time system, I'm using the zfp flag for compilation. I tried to implement some interruptions using sentences like this: procedure Receive_USART; -- Address the interruption handler pragma Machine_Attribute (Entity => Receive_USART, Attribute_Name => "signal"); pragma Export (Convention => C, Entity => Receive_USART, External_Name => "__vector_26"); --USART0_RXC Using Proteus (ISIS Professional 6.7 SP2), I'm debugging the algorithm. The initialization of the interruption is right, but when the interruption occur, it isn't handling to the procedure. Do I need to do something more to handle the procedure when the interruption occur ? Do you fellows have any other simple way to handle interruptions ? Thanks very much for your help....
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > The syntax that you show is very specific for AVR microcontrollers. If that's really the case have a look at
> 
> > 
> 
> > 
> 
> > 
> 
> > http://sourceforge.net/p/avr-ada/wiki/Interrupts/
> 
> > 
> 
> > 
> 
> > 
> 
> > and at the data sheet of your controller. Consider also asking on the AVR-Ada-devel mailing list.
> 
> > 
> 
> > 
> 
> > 
> 
> > HTH
> 
> > 
> 
> >     Rolf
> 
> 
> 
>  Thanks for your advice and sorry for incomplete information.
> 
> 
> 
>  I'm using an AVR ATMega 2560. I'm not using the avr-ada lib. The way I'm doing the interruptions is just like the link you sent. The interruption is ok, the used vector is in accordance with the enabled interrupt, as I saw in my debug. The problem is: the handled procedure is not called when the interruption ocur.
> 
> 
> 
> As I tried to summarize, this is my question...


The above mentioned wiki page explicitely mentions that the names of the interrupt vectors are off by one compared to the data sheet.  The data sheet of the ATmega2560 shows that the USART0 receive complete interrupt is at address 26, that results in the name of the vector "__vector_25".

You should really consider using AVR-Ada.  Then you could simply use 
AVR.MCU.Sig_USART0_RX_String which would have saved you two days of searching. You wouldn't even have to write your own serial interface routines as they are already included (AVR.UART) and tested.

   Rolf

Re: Interruption Handling using zfp compilation flag

[Vinícius Franchini]

Thanks Rolf. I let the "Off by one" go. 

I tried to use the Avr-Ada, but the size of the .hex increase very much. Maybe this happened because I did something wrong when including the lib. So I decided to "translate" my C routines into Ada. I know I'm reinventing the wheel, but this is aiding me to learn Ada. 

Att,

Re: Interruption Handling using zfp compilation flag

[R R]

On Dec 9, 2:08 am, Vinícius Franchini <viniciu...@gmail.com> wrote:
> Thanks Rolf. I let the "Off by one" go.
>
> I tried to use the Avr-Ada, but the size of the .hex increase very much. Maybe this happened because I did something wrong when including the lib. So I decided to "translate" my C routines into Ada. I know I'm reinventing the wheel, but this is aiding me to learn Ada.
>
> Att,

Executable size is paramount on little microcontrollers. Just guessing
on your environment I can imagine two possible causes:

1. You use your own build environment without the gpr-files from AVR-
Ada.  You then might miss stripping off all unused routines and data
at link time (--gc-sections)

2. avr-uart.adb requires manual setting of a boolean constant.  If
not, the code for polled and interrupt driven UART communication ends
up in the hex file

Please send me direct email to rolf dot ebert dot gcc at gmx dot de

Re: Interruption Handling using zfp compilation flag

[Brian Drummond]

On Sat, 08 Dec 2012 17:08:58 -0800, Vinícius Franchini wrote:

> Thanks Rolf. I let the "Off by one" go.
> 
> I tried to use the Avr-Ada, but the size of the .hex increase very much.
> Maybe this happened because I did something wrong when including the
> lib. So I decided to "translate" my C routines into Ada. I know I'm
> reinventing the wheel, but this is aiding me to learn Ada.

Be aware that AVR-Ada 1.2 includes options to select between interrupt 
driven and polling (SW delay) UART - 1.1 only had the polling UART and 
(when using RS232) gave smaller executables than 1.2. (about 1.2k in my 
case versus 1.6k)

I believe that the polling UART option in 1.2  would bring the executable 
size back down but have not yet tried it...

- Brian