Giulio Dalla Vecchia

Hi, thank you so much for the detailed explanation! I have to say, I really liked the “dining philosophers” analogy — I hadn’t even thought about applying the DPP pattern to my scenario, but it actually makes perfect sense here! Definitely a clever way to coordinate access to the shared resource. Thanks a lot for the insight and for pointing me in the right direction! 🙌 Giulio

Hi everyone, I’d like your advice on an architectural issue. I have 40 “sensors” connected over an RS‑485 bus. For each sensor I have an orthogonal state machine inside a dedicated AO (let’s call it SensorManager). I also have a separate AO responsible for managing the RS‑485 serial interface. The problem: Each of the 40 sensor state machines may need to send a Modbus request, which means they would post an event to the AO that handles the serial line. However, I cannot allow all 40 sensors to request...

Hi everyone, I’d like to share an example of an I2C driver based on an NXP MCXA MCU. The repository is available here: In the folder /libraries/drivers/BSP/src you’ll find two files: bsp_i2c.c bsp_stwlc_driver.c The bsp_i2c.c file provides an example of an interrupt-driven I2C driver and shows how a peripheral can be managed using the QPC framework. The driver is designed as an orthogonal component and is used by the active object implemented in bsp_stwlc_driver.c. Please note that the driver has...

Hi Matteo, I haven’t worked with TZ yet (I'll be starting a project involving it in the coming months), so forgive me if this is a naive question — but have you checked whether the interrupt vector table is correctly positioned for your application? Just a thought that might help. Best regards, GDV

Hi Miro, could you explain better (with an example) what do you intend when you say "transition to History"? Thanks a lot in advance! Giulio

Hi Miro, Is simply putting the Python script to sleep for a certain period before checking the expectations from the target enough to achieve what Matteo wants?

Hi all, I'm working on building the QUTest blinky example for a real target (STM32H7 board) using CMake. However, I believe there might be an issue with the CMakeLists.txt file. When compiling with QUTest, you're not supposed to set any kernel (QV, QK, QXK). If you don't explicitly define QPC_CFG_KERNEL, the variable defaults to 'QV', which leads to the qv.c file being compiled, inevitably causing errors. Does anyone else see this issue?

Hi everyone, Thanks for the replies. I was not referring on the blocking sockets. If I need to run two library, that is already able to get the most out using the non-blocking socket, is it better to isolate the TCP/IP stack using a dedicated AO creating some events for opening/closing/sending/receiving or is it better to manage the libraries in a dedicated othogonal region of the main AO that manage also the TCP/IP stack?