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

typedef-access in ISR

Hi,

I'm working on a project employing an XE164. In a ISR (CAN-RX-Interrupt) I want to fill a global variable with some values, then set a flag to signal the main program ok-to-read. The variable to fill is a structure, defined in the main program:

typedef struct {

unsigned char data[8];

unsigned char flags;

} t_data;

in main.c:

volatile t_data data;

The CAN-ISR is supposed to fill data[0..7] with the incoming bytes, then set flags to (e.g.) TRUE. The main program is supposed to look for the flag, handle the data, then reset the flag.

This works fine when I use a seperate variable. It does not always work, however, if "flags" is a member of a structure, like t_data.flags in the example above: It "mostly" works, but the main programm misses some new messages, about 10% of the time. Again, this does not occur if "flags" is a seperate variable.

Can anyone make sense of this? Could it be that read access by main to some other part of the structure also kills the ISR-write to the flags-part of the structure (or vv)?

Any help would be much apreciated.

Regs,
Alto Speckhardt

Parents
  • Hi,

    thanks for your reply.

    I'm aware of the problems of the single-buffer concept, but in this case it should be sufficient: The particular message in question (there will be others where the situation might be different) is pretty infrequent: It is a timestamp/heartbeat that occurs once each second. Therefore, I'm pretty much certain that my application will be able to keep up with it.

    It's also the reason why I can't see any read/write conflicts in this one.

    Still, every once in a while, my main program doesn't react to the message for two seconds, sometimes up to three or even four seconds.

    Regs,
    Alto Speckhardt

Reply
  • Hi,

    thanks for your reply.

    I'm aware of the problems of the single-buffer concept, but in this case it should be sufficient: The particular message in question (there will be others where the situation might be different) is pretty infrequent: It is a timestamp/heartbeat that occurs once each second. Therefore, I'm pretty much certain that my application will be able to keep up with it.

    It's also the reason why I can't see any read/write conflicts in this one.

    Still, every once in a while, my main program doesn't react to the message for two seconds, sometimes up to three or even four seconds.

    Regs,
    Alto Speckhardt

Children