Panopticon

The way I've handled this in the past is to use a separate HW timer from the QP tick timer (and QP time events) and in the ISR used POST_X Hope that makes sense

Sorry if I had more time I'd fill in all the details for you but you seem like a smart guy so hopefully this is enough... There are at least 2 ways to do this (note that I am not commenting on anything other than answering your question -- in other words, generally I don't recommend breaking encapsulation etc. but right now I'll try to answer your question...) Approach #1: You can use QASM_IS_IN() (version 8.x) or QHsm_isIn() (version 7.x and earlier) For these you are "going through the front door"...

Sorry if I had more time I'd fill in all the details for you but you seem like a smart guy so hopefully this is enough... There are at least 2 ways to do this (note that I am not commenting on anything other than answering your question -- in other words, generally I don't recommend breaking encapsulation etc. but right now I'll try to answer your question...) Approach #1: You can use QASM_IS_IN() (version 8.x) or QHsm_isIn() (version 7.x and earlier) For these you are "going through the front door"...

You are welcome Sebastian. I actually expected the problem was maybe that the constructor was being called (of course, right?!?!) but that the object's data was being corrupted in the short window between object construction and starting. Glad that you realized the object was never even being constructed... Another thing Miro often says: "Nothing works until everything works" I'm glad you are moving forward again.

I don't see any issues with what I copied, but perhaps I'm mistaken. I also don't see any issues. And the fact that you started with a working example (Miro Samek Rule #1) is always giving yourself the best possible chance of success. As you can imagine, debugging through discussing can always be tricky. There many things (some of which have nothing to do w/ QP) that could eventually explain something like this, but a couple questions: Do you have, or could you add, another simple AO (different class...

I don't see any issues with what I copied, but perhaps I'm mistaken. I also don't see any issues. And the fact that you started with a working example (Miro Samek Rule #1) is always giving yourself the best possible chance of success. As you can imagine, debugging through discussing can always be tricky. There many things (some of which have nothing to do w/ QP) that could eventually explain something like this, but a couple questions: Do you have, or could you add, another simple AO (different class...

I don't see any issues with what I copied, but perhaps I'm mistaken. I also don't see any issues. And the fact that you started with a working example (Miro Samek Rule #1) is always giving yourself the best possible chance of success. As you can imagine, debugging through discussing can always be tricky. There many things (some of which have nothing to do w/ QP) that could eventually explain something like this, but a couple questions: Do you have, or could you add, another simple AO? Even one that...

Did you initialize the active object before you started it? (Edit: you mentioned C++, so your AO's subclass constructor is guaranteed to run -- but did you remember to construct the AO in your constructor initializer list? Some users of the C version of the framework forget to construct/initialize the AO before they start it. Shouldn't be the case for you. In your contructor just make sure you're setting a valid topmost initial transition, I believe this is the 1st param to the AO's constructor)...