Hi Michal, Yes — this is the expected behavior of the basic event allocator in QP. As you suspected, it is notoriously difficult to make an allocator (and memory alignment in particular) fully platform‑agnostic. In QP, the minimal alignment must match void, and the minimum block size must be 2sizeof(void*). This is exactly what the QF_MPOOL_EL() macro is designed to enforce. Another important requirement is that QP event pools must use different block sizes, and the size differences must exceed sizeof(void*)...
Hi Michal, Yes — this is the expected behavior of the basic event allocator in QP. As you suspected, it is notoriously difficult to make an allocator (and memory alignment in particular) fully platform‑agnostic. In QP, the minimal alignment must match void, and the minimum block size must be 2sizeof(void*). This is exactly what the QF_MPOOL_EL() macro is designed to enforce. Another important requirement is that QP event pools must use different block sizes, and the size differences must exceed sizeof(void*)...
Hi Pete, Thanks so much for your interest in the "Modern Embedded Systems Programming" video course on YouTube. The Tiva‑C LaunchPad had an amazing run — it stayed in continuous production for over 13 years — but all good things eventually come to an end, and the board is now approaching EOL. In anticipation of this, the project downloads to the video course now include support for the STM32 NUCELO-C031C6 (ARM Cortex‑M0+). I recommend picking up that board going forward. The older lessons won’t translate...
Hi Harry, I'm not sure if you're talking about stopping an Active Object (AO) or a passive component (HSM). If you mean AOs, you can configure QP/C++ for stopping AOs by uncommenting #define QACTIVE_CAN_STOP in qp_config.hpp. Then you can call QActive::stop() when you wish to get rid of the AO. However, you as the application developer are responsible to make sure that the application will not post events to that AO. If the AO must be also destroyed, you must enable the virtual destructor by uncommenting...
Hi Joel, Got it. Thank you for pointing this out. The issue has been corrected in QTools 8.1.5 (see also the attached screenshot). --MMS
Hi Joel, Got it. Thank you for pointing this out. The issue has been corrected in QTools 8.1.5 (see the attached screenshot). --MMS
Hi Gene, It seems that you might be messing up the namespace nesting (e.g., your code snippet closes the unnamed namespace twice). But specifically QP/C++ project and STM32Cube, you might want to take a look at the existing example, located in qpcpp\examples\stm32cube\blinky_nucleo-u545re. Now I don't remember specifically, but there was something extra needed to cleanly build C++ in STM32Cube. The blinky QP/C++ project shows how to do it. (I would open it and build even if you don't have the NUCLEO-U545RE...
Hi Jason, The communication between the target and the QSPY host application—the “back‑end”—is fundamentally stream‑oriented. The QS data protocol is designed so the target can emit data in arbitrary chunks, without regard for individual trace‑record boundaries. That model aligns directly with what TCP provides. (And on smaller MCUs, this same stream behavior is achieved over a UART rather than TCP.) In contrast, the communication between the QSPY back‑end and the various front‑ends—such as QUTest...