Panopticon

Jim, I should confess I should go back and re-read your original post, but can it be accomplished with something like this: whoever knows the SPI AO should be paused (maybe it's the SPI AO itself) does a LIFO post saying "Pause yourself", SPI AO goes to PAUSE state, while in PAUSE state other events are deferred until TX COMPLETE interrrupt, which posts UNPAUSE to SPI AO, then SPI AO resumes. I know there are probably some corner cases and concerns about event ordering, but I've often found the framework...

Unfortunately this isn't correct. Each bit (0 or 1) must be held for a minimum of 60 usec; the 1 usec time you see is the minimum recovery time in between bits. The datasheet says: All write time slots must be a minimum of 60µs in duration with a minimum of a 1µs recovery time between individual write slots. Like almost all I2C / SPI / 1-wire devices, you can always run the device slower than the max speed, but you can't run it faster. In other words, your write time slot can be 1ms instead of 60...

Miro -- the original poster has a 1 MHz tick rate (1 microsecond tick period). My jaw hit the floor when I read this... Tuyen -- I'm pretty sure you can't read the temperature sensor that quickly, and also from a physics perspective and the sensor bandwidth what sampling rate makes sense -- maybe 100 Hz? I could imagine 1 kHz (I know somebody who used the QP in a real-time closed loop temperature control system who did this) but any faster doesn't make sense to me.

Miro -- the original poster has a 1 MHz tick rate (1 microsecond tick period). My jaw hit the floor when I read this...

if (defer(&cmdQueue, e)) // If we don't add above check then will queue will get over written or crash due to boundary cross?? I am ok for queue over written.. If the queue is full and you attempt to defer into the full queue, the framework will assert. It will not "crash" (it will enter Q_onAssert() if you are running before 7.3.0) and it will not overwrite one of the elements. I'm assuming you understand that the framework asserts when you do something that won't work. This is one of those cas...

Sorry for thread-hijacking but this reminds me of the quote: "The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year's model." (Andrew Tanenbaum) When I worked at a big company that everybody's heard of (2 decades ago), everyone was drinking the POSIX Kool Aid until it turned out to be a clown show. And then on the ops side, Java promised "write once, run everywhere" (particularly with GUI apps) and that...

I see what's going on here... sometimes "peeking behind the curtains" can be dangerous. the Q_RET_ENTRY & Q_RET_EXIT are used for the QMSM class -- this is always generated code by the modeling tool. It seems you are hand-coding, or hand-modifying, code that was generated by the modeling tool? If you're using the QHsm base class, the Q_HANDLED() return is the right choice (which just turns into Q_RET_HANDLED, but you should always use the macros because they might do other things behind the scene)....

I've been using QP for 20 years (almost exactly to the day) and I've never seen Q_RET_EXIT. These are probably internal definitions that aren't intended to be user-facing. (But in C there is no concept of namespaces and access specifiers) Entry and Exit actions should finish with Q_HANDLED().