指向 volatile 结构成员的 const 指针

Question

I'm using microcontroller to make some ADC measurements. I have an issue when I try to compile following code using -O2 optimization, MCU freezes when PrintVal() function is present in code. I did some debugging and it turns out that when I add -fno-inline compiler flag, the code will run fine even with PrintVal() function.

Here is some background:

AdcIsr.c contains interrupt that is executed when ADC finishes it's job. This file also contains ISRInit() function that initializes variable that will hold value after conversion. In main loop will wait for interrupt and only then access AdcMeas.value.

AdcIsr.c
static volatile uin16_t* isrVarPtr = NULL;

ISR()
{
    uint8_t tmp = readAdc();
    *isrVarPtr = tmp;
}

void ISRInit(volatile uint16_t *var)
{
    isrVarPtr = var;
}

AdcMeas.c

typedef struct{
    uint8_t id;
    volatile uint16_t value;
}AdcMeas_t;

static AdcMeas_t AdcMeas = {0};

const AdcMeas_t* AdcMeasGetStructPtr()
{
    return &AdcMeas;
}

main.c

void PrintVal(const AdcMeas_t* data)
{
    printf("AdcMeas %d value: %d\r\n", data->id, data->value);
}

void StartMeasurement()
{
    ...
    AdcOn();
    ...
}

int main()
{
    ISRInit(AdcMeasGetStructPtr()->value);
    while(1)
    {
        StartMeasurement();
        WaitForISR();
        PrintVal(AdcMeasGetStructPtr());
        DelayMs(1000);
    }
}

Questions:

1. Is there something wrong with usage of const AdcMeas_t* data as argument of the PrintVal() function? I understand that AdcMeas.value may change inside interrupt and PrintVal() may be outdated.

2. AdcMeas contains a 'generic getter'. Is this a good practice to use this sort of function to allow read-only access to static structure? or should I implement AdcMeasGetId() and AdcMeasGetValue functions (note that this struct has only 2 members, what if it has 8 members)?

I know this code is a bit dumb (waiting for interrupt in while loop), this is just an example.

Answer 1

Some bugs:

• You have no header files, neither library include or your own ones. This means that everything is hopelessly broken until you fix that. You cannot do multiple file projects in C without header files.

• *isrVarPtr = tmp; Here you write to a variable without protection from race conditions. If the main program reads this variable in several steps, you risk getting incorrect data. You need to protect against race conditions or guarantee atomic access.

• const AdcMeasGetStructPtr() is gibberish and there is no way that the return &AdcMeas; inside it would compile with a conforming C compiler.

  If you have an old but conforming C90 compiler, the return type will get treated as int . Otherwise, if you have a modern C compiler, not even the function definition will compiler. So it would seem that something is very wrong with your compiler, which is a greater concern than this bug.

• Declaring the typedef struct in the C file and then returning a pointer to it doesn't make any sense. You need to re-design this module. You could have a getter function returning an instance to a private struct, if there is only ever going to be 1 instance of it (singleton). However, as mentioned, it needs to handle race conditions.

Stylistic concerns:

• Empty parenthesis () in a function declaration is almost always wrong in C. This is obsolete style and means "accept any parameter". C++ is different here.

• int main() doesn't make any sense at all in a microcontroller system. You should use some implementation-defined form suitable for freestanding programs. The most commonly supported form is void main (void) .

• DelayMs(1000); is highly questionable code in any embedded system. There should never be a reason why you'd want to hang up your MCU being useless, with max current consumption, for a whole second.

Overall it seems you would benefit from a "continuous conversion" ADC. ADCs that support continuous conversion just dump their latest read in the data register and you can pick it up with polling whenever you need it. Catching all ADC interrupts is really just for hard realtime systems, signal processing and similar.