This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ST timer problems

Hello,

Could you help to install the ST timer on the AT91Rm9200? I don't know how to setup the AIC registers correct. Maybe there are more than one big mistake.

void initialize_pit()
{
        unsigned int  flag, period, irq_id, mask, oldHandler, src_type, priority;
        volatile int status;
        void *newHandler;

        //period
    Timer0->ST_PIMR = period << 5;

        AT91F_ST_SetPeriodInterval(Timer0, period);
        //state
        //status = Timer0->ST_SR;

        //enable interrupt
        flag=1;
        Timer0->ST_IER = flag;

        AT91F_ST_EnableIt( Timer0, flag);

        //enable PMC
        AT91F_PMC_EnablePeriphClock(AT91C_BASE_PMC, 1 << AT91C_ID_IRQ0);

        //config AIC
        irq_id = 0;
        oldHandler = pAic->AIC_SVR[irq_id];
        mask = 0x1 << irq_id;
        pAic->AIC_IDCR = mask ;
        pAic->AIC_SVR[irq_id] = (unsigned int) newHandler ;

        //* Store the Source Mode Register
    pAic->AIC_SMR[irq_id] = src_type | priority  ;


        AT91F_AIC_ConfigureIt(pAic, irq_id, priority, src_type, newHandler);

        //enable AIC
        AT91F_AIC_EnableIt(pAic, 1);
}

I hope somebody could help me with this problem...

best regards
johannes

Parents
  • Is it a very good and common way to write only the initialisation and the while(1) loop in the main routine, so that the processor is always in idle mode, only when a interrupt occurs?

    Almost. The usual way to write uC/DSP programs is to only use ISRs for doing the things that are absolutely necessary when an interrupt occurs, and have them use flags to signal to the main endless loop that there is further processing to be done.

    At least that's the way for programs that do not use an operating system. Things get a bit more complex when an operating system is involved and you need to deal with tasks, software interrupts, preemption and the like.

    What you should avoid is putting any longer processing (especially any loops that wait for events) into ISRs. A good rule to follow is KISS - Keep ISRs Short and Simple.

    However, sitting in a while(1); loop does not put the processor into an acutal idle (i.e. power-saving) state. How to do this can be found (as usual) in the datasheet (on page 271, to be precise).

Reply
  • Is it a very good and common way to write only the initialisation and the while(1) loop in the main routine, so that the processor is always in idle mode, only when a interrupt occurs?

    Almost. The usual way to write uC/DSP programs is to only use ISRs for doing the things that are absolutely necessary when an interrupt occurs, and have them use flags to signal to the main endless loop that there is further processing to be done.

    At least that's the way for programs that do not use an operating system. Things get a bit more complex when an operating system is involved and you need to deal with tasks, software interrupts, preemption and the like.

    What you should avoid is putting any longer processing (especially any loops that wait for events) into ISRs. A good rule to follow is KISS - Keep ISRs Short and Simple.

    However, sitting in a while(1); loop does not put the processor into an acutal idle (i.e. power-saving) state. How to do this can be found (as usual) in the datasheet (on page 271, to be precise).

Children
  •  void ST_interrupt(void) __irq
    {
    
            AT91C_BASE_AIC->AIC_EOICR = AT91C_BASE_ST->ST_SR;
    
            while( !(COM1_1->US_CSR  & AT91C_US_TXRDY) )
                        continue;
    
            AT91F_US_PutChar (COM1_1,'n');
    
        //the end of interrupt durch lesen dieses Registers - letzte Aktion
        AT91C_BASE_AIC->AIC_EOICR = 0x0;
    }
    

    It's not the best idea to read the AIC_EOICR register in the first line of the ISR, isn't it?

    Therefore is it a good solution to install a variable status and read both registers ST_SR und AIC_EOICR with status = AT91C_BASE_ST->ST_SR at the beginning of the ISR and status = AT91C_BASE_AIC->AIC_EOICR at the end of the ISR

    johannes

  • It's not the best idea to read the AIC_EOICR register in the first line of the ISR, isn't it?

    The AIC_EOICR is being written to in this line. And since the process of writing to AIC_EOICR ends the interrupt function, this line should be the last line of the ISR.

    Therefore is it a good solution to install a variable status and read both registers ST_SR und AIC_EOICR with status = AT91C_BASE_ST->ST_SR at the beginning of the ISR and status = AT91C_BASE_AIC->AIC_EOICR at the end of the ISR

    Using an intermediate variable is not necessary. AIC_EOICR needs to be written to in order to end the interrupt, and ST_SR needs to be read in order to clear the ST interrupt. The one line, placed at the end of the ISR, takes care of both.

  • and there's no problem if a interrupt occured when the processor is working in the ISR of the same typ of interrupt - but the ST_SR register is not read in the actual ISR?

    1. Interrupt1 occured
    2. ISR_interrupt1 --> second interrupt occured
    3. ST_SR interrupt1 is read

    The second interrupt is safed in a register (I don't know it by heart)- although the ST_SR is not read - and waits until the AIC_EOICR register is read.

    johannes

  • and there's no problem if a interrupt occured when the processor is working in the ISR of the same typ of interrupt - but the ST_SR register is not read in the actual ISR?

    No, you can safely wait with reading ST_SR until the last line of the ISR.

    An ISR can only be interrupted (leading to interrupt nesting) by an interrupt of higher priority. This excludes the possibility of an ISR being interrupted by its own interrupt signal.

    However, you should not create an ISR that is takes enough CPU time for the ST_SR interrupt to occur again while the ISR is still running. This would cause you to miss one "tick" of the PITS. Since the PITS runs quite slowly, any ISR that runs long enough should be considered bloated and trimmed down to an acceptable running time immediately.