Matthew Eshleman

Hi Lucca, For my QP/C++ approach to this, check out: https://github.com/covemountainsoftware/cpputest-for-qpcpp/blob/master/cpputest-for-qpcpp-lib/include/cmsOrthogonalContainer.hpp and https://github.com/covemountainsoftware/cpputest-for-qpcpp/blob/master/cpputest-for-qpcpp-lib/include/cmsOrthogonalComponent.hpp In this case, the container is generic and manages N components. An individual component must be dervied from the above and implement the required interface. One requirement I imposed on...

I'm assuming that the OK, ERROR, and other responses are converted to events outside the Modem active object." That is a key point from Samek. Create a parser module. That module can run within the modem/cell AO if you like (the UART Rx ISR could send a character at a time to the AO in events), or run within the UART Tx ISR itself, POSTing output events. But the key point is the parser module would handle all the incoming bytes/characters until a single completed AT message is received. Then it would...

The fact that you are aware of the unsolicited responses is already a big positive. I had to rewrite some firmware some years ago because of this. That client would not pay for QP, so I had to re-invent the wheel, but I did implement using the active object pattern. Here is the starting point for some of my observations on this issue: https://covemountainsoftware.com/2020/07/18/extreme-asynchronous-firmware-design/

Sounds a bit like a design challenge. Instead of hard coding the active object directly to a particular I2C bus, consider using a dependency injection pattern with associated interfaces for a generic I2C bus. Then you could create a new AO and inject the concrete appropriate I2C bus as a constructor argument. Which means you could create multiple AOs, one for each bus, each with a unique concrete I2C bus driver/reference. FWIW, you can use a template to define your AO, but I have only done this in...

Interesting use case and idea, I've considered this before as well. Ultimately ended up using MQTT, which normally requires a TCP connection. Does the RF Mesh network support a full TCP/IP stack? https://en.wikipedia.org/wiki/MQTT

Interesting use case and idea, I've considered this before as well. Ultimately ended up using MQTT, which normally requires a TCP connection. Do the RF Mesh network support a full TCP/IP stack? https://en.wikipedia.org/wiki/MQTT

I spent almost a year re-writing some firmware that used that blocking approach. In some cases, the product in question would "freeze up" for up to two minutes due to the many sequences of blocking code. I wrote an article on my experience too, which is more or less in-line with Samek's note above too: https://covemountainsoftware.com/2020/07/18/extreme-asynchronous-firmware-design/ Hope that is useful. Matthew

Greetings! I am a long time QP/C++ user (first major product using QP/C++ released in 2004), and wanted to announce and solicit feedback on two new support packages for QP that I recently released into the wild. These packages combine my favorites when creating embedded software: event driven active objects and host based unit testing using CppUTest. I would be interested in any feedback or questions on these packages, either directly or via this forum. To learn more, start here: https://covemountainsoftware.com/products/...