> What about a friend method? There must be a way of specifying the ISR
> as a
> friend to the CTimer0 class, allowing it access to the private data.
> 
> - Dean

Yes, making the interrupt a friend works exactly as I want. It solves the
problem of an interrupt not having a this pointer. The overhead seems
reasonable. The below uses my awkward de-mangler macro to produce the
interrupt declaration:

extern "C" void __vector_16(void)
__attribute__((alias("_ZN16CTimer0Interrupt11__vector_16Ev")));
void CTimer0Interrupt::__vector_16(void)
{

I will try tomorrow using Dean's much simpler macro.

Ron 


//--------------------------------
class CTimer0
{
    friend class CTimer0Interrupt;
public:
    CTimer0();
    ~CTimer0();
    bool GetOverflowFlag(void);

private:
    void SetOverflowFlag(void);

private:
    volatile bool       mOverflowFlag;
    CTimer0Interrupt    mTimer0Interrupt;
};

//--------------------------------
class CTimer0Interrupt
{
public:
    CTimer0Interrupt();
    ~CTimer0Interrupt();

private:
    void TIMER0_OVF_vect(void) __attribute__ ((signal, __INTR_ATTRS));
};

The actual interrupt in the instance of CTimer0Interrupt is:

//---------------------------------------------------------------CLASS_ISR(C
Timer0Interrupt, 16, TIMER0_OVF_vect, 11)
{
    TCNT0 = TIMER0_TIMEOUT;     // restart the timeout
    Timer0.SetOverflowFlag();   // tell our friend
}

The associated methods in the CTimer0 class are below. All this example
class had to do was provide an indication of an overflow event when
interrogated. Ie:

        if (Timer0.GetOverflowFlag())
        {


//---------------------------------------------------------------
bool CTimer0::GetOverflowFlag(void)    // this is public
{
    cli();
    bool tempFlag = mOverflowFlag;
    mOverflowFlag = false;
    sei();
    return tempFlag;
}

//---------------------------------------------------------------
void CTimer0::SetOverflowFlag(void)    // this is private
{
    mOverflowFlag = true;
}

The mOverflowFlag is of course volatile.





_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Reply via email to