search

QuantumLeaps / qpc

QP/C Real-Time Embedded Framework/RTOS based on asynchronous, event-driven Active Objects (Actors) and Hierarchical State Machines
https://www.state-machine.com/products/qp
980 stars 250 forks source link

problem with nesting more than 3 level with stm32f103+freertos #8

Closed AhmadBan closed 4 years ago

AhmadBan commented 4 years ago

I simulate a HSM system using visual studio and I wanted to port it with STM32f103 and freeRTOS and mail Queue to dispatch events.(the reason for that was I could not manage to use qk and qep Queue) It was working for states up to 2 level of nesting but when I enter the third level of nesting in any state the function QHSM_DISPATCH(&act->super, e) seems not working correctly though everythings works correctly in VS simulation. there are 5 keys in my hardware that send event bottem,down , ok, left and right. I can send you values related to assembly

quantum-leaps commented 4 years ago

The use of FreeRTOS is quite complicated, because FreeRTOS uses completely different APIs in the ISRs (the "FromISR" API) than at the task level (the "regular" API). For that reason, it is non-trivial to use any third-party software with FreeRTOS. For example, if you wish to post a QP event from an ISR to a QP active object, you have to use a special "FromISR" version of event posting. Not only this. If the event is dynamic, you'll have to use the special "FromISR" version of Q_NEW_FROM_ISR(), and so on...

(The obvious question why people use such a bad design like FreeRTOS is beyond the scope of this comment...)

So, to work around all these complexities, you need to use the existing QP port to FreeRTOS. This port is located in the qpc\ports\freertos directory and some examples of using it are located in qpc\examples\freertos directory. But even so, you need to be very careful to always use the correct APIs: "FromISR" API in the ISRs and callbacks invoked from ISRs and the "regular" API in the task level.

So, assuming that you are doing all this correctly, you need to check if you don't overflow the stack(s). Please remember that FreeRTOS uses multiple stacks, one for each task. Overflowing any of these stacks is bad.

--MMS

stefanschober commented 4 years ago

Hi AhmadBan, I can assure you from own experience, that the QP framework has absolutely no problem with hiararchical SMs with more than 3 levels of hierarchical nesting. I created a system using quite a number of state machines which have 3 to 4 levels of hierarchy. This system runs with a simulation BSP under Windows or Linux. It runs in simulation mode on a Raspberry Pi. On the Raspberry we also created a hardware extension (HAT), so that it is able to connect the real world HW to this rapid prototyping system. And finally it also runs perfectly on the real life HW, which uses a small ARM Cortex M0 powered SoC from Infineon (TLE984x). All implementations use the preemptive non-blocking QK kernel. My advice is, you study the examples provided with QP/C and QP/C++ and build up your own system step-by-step following the examples and the excellent documentation provided by MMS.

Regards Stefan

AhmadBan commented 4 years ago

After 5 days I found out that I am writing out of memory allocated in static memory the reason this problem shows itself in 3rd nested was I wrote out of memory in these states this issue came to exist since my simulation was with an LCD 4x16 character then in hardware port it is replaced with 4x20 and somewhere in code I wrote more than 16 character in buffer without already allocating it. That was silly mistake .

AhmadBan commented 4 years ago

Hi AhmadBan, I can assure you from own experience, that the QP framework has absolutely no problem with hiararchical SMs with more than 3 levels of hierarchical nesting. I created a system using quite a number of state machines which have 3 to 4 levels of hierarchy. This system runs with a simulation BSP under Windows or Linux. It runs in simulation mode on a Raspberry Pi. On the Raspberry we also created a hardware extension (HAT), so that it is able to connect the real world HW to this rapid prototyping system. And finally it also runs perfectly on the real life HW, which uses a small ARM Cortex M0 powered SoC from Infineon (TLE984x). All implementations use the preemptive non-blocking QK kernel. My advice is, you study the examples provided with QP/C and QP/C++ and build up your own system step-by-step following the examples and the excellent documentation provided by MMS.

Regards Stefan

I have no doubt QEP works correctly because QEP layer is completely independent of RTOS Layer and I tested it with VS2019