I am designing a driver for DS18B20 temperature sensor based on Active Object under QP. I have created a 1 microsecond interrupt using timer in order to produce interval events for processing data of the sensor. I am using STM32F7 microcontroller with CPU clock being configured to 180MHz.
I have been facing difficulty in allocating memory size of AO's event queue since the system constantly asserts in qf_qact 110. I searched in the forum and found your answer which indicated that assertion related to event rate.
I wonder how to properly use QP features to design such a system. I am adopting QP. It is such a perfect toolbox for designing embedded software.
Thank you in advance.
Tuyen
Last edit: tuyentm 2024-04-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Tuyen,
A system clock tick rate of 1kHz (1ms ticks) is not at all outrages or uncommon in QP, even for slower CPUs. In this respect, QP is no different from a traditional RTOS, where also 1kHz ticks are common.
It all depends how much CPU is required to process the events. But, my gut feeling is that something else must be going on in your system that causes the assertion.
BTW, which version of QP are you running? Did you perhaps mean assertion in qf_actq?
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Last edit: Panopticon 2024-04-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The DS18B20 requires bit - wise processing in microseconds . I attached a timing diagram in this answer. A simple, blocking approach for processing data from this sensor is synchronously delaying in some microseconds.
I have designed a driver which basically counts ticks in timer interrupt happens 1 microsecond interval, then feeds the value of ticks into a simple switch - case state machine to process, and it is working flawlessly.
Since I am adopting QP into my design, my idea is basically feeding 1 microseconds interval events to my existing process.
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 usec but it cannot be shorter. And the recovery time doesn't have to be 1 usec, it can be 500 usec or even 1msec or longer.
Unfortunately I don't have more time to discuss reading a data sheet but I would encourage you to read it carefully and then re-consider the impossible (and unnecessary) timings you're trying to meet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your answer.
My system simply includes temperature sensor reading for demonstration. My desire event producing frequency is 1MHz.
I am using QP/C++ version 6.9.3 and the toolchain for STM32F7 (Cortex M7) port is GNU. The assertion happens when I provoked start() on my active object instance. And the assertion locates in qf/qf_qact.cpp, function QActive::register_()
Regards,
Tuyen
Last edit: tuyentm 2024-04-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Tuyen,
I'm sorry for confusing the orders of magnitude in my earlier response. This is because interrupt rate of 1MHz is so absurd that it didn't even cross my mind that it could be actually used. Most CPUs aren't capable of being interrupted so often. But if your super-performat CPU is capable, it would spend vast majority of of its time entering and exiting the interrupt (this is sometimes called "thrashing").
Anyway: no system can work with 1MHz clock tick. And I can say this for sure.
Regarding your timing diagram, it does NOT mean that the particular peripheral requires servicing avery 1microsecond. (1 microsecond is just one of many numbers in the timing diagram). You must be mixing simething here.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Miro,
I am designing a driver for DS18B20 temperature sensor based on Active Object under QP. I have created a 1 microsecond interrupt using timer in order to produce interval events for processing data of the sensor. I am using STM32F7 microcontroller with CPU clock being configured to 180MHz.
I have been facing difficulty in allocating memory size of AO's event queue since the system constantly asserts in qf_qact 110. I searched in the forum and found your answer which indicated that assertion related to event rate.
I wonder how to properly use QP features to design such a system. I am adopting QP. It is such a perfect toolbox for designing embedded software.
Thank you in advance.
Tuyen
Last edit: tuyentm 2024-04-13
Hi Tuyen,
A system clock tick rate of 1kHz (1ms ticks) is not at all outrages or uncommon in QP, even for slower CPUs. In this respect, QP is no different from a traditional RTOS, where also 1kHz ticks are common.
It all depends how much CPU is required to process the events. But, my gut feeling is that something else must be going on in your system that causes the assertion.
BTW, which version of QP are you running? Did you perhaps mean assertion in
qf_actq?--MMS
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.
Last edit: Panopticon 2024-04-13
Hi Panopticon,
The DS18B20 requires bit - wise processing in microseconds . I attached a timing diagram in this answer. A simple, blocking approach for processing data from this sensor is synchronously delaying in some microseconds.
I have designed a driver which basically counts ticks in timer interrupt happens 1 microsecond interval, then feeds the value of ticks into a simple switch - case state machine to process, and it is working flawlessly.
Since I am adopting QP into my design, my idea is basically feeding 1 microseconds interval events to my existing process.
Regards,
Tuyen
Last edit: tuyentm 2024-04-14
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:
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 usec but it cannot be shorter. And the recovery time doesn't have to be 1 usec, it can be 500 usec or even 1msec or longer.
Unfortunately I don't have more time to discuss reading a data sheet but I would encourage you to read it carefully and then re-consider the impossible (and unnecessary) timings you're trying to meet.
Hi Miro,
Thank you for your answer.
My system simply includes temperature sensor reading for demonstration. My desire event producing frequency is 1MHz.
I am using QP/C++ version 6.9.3 and the toolchain for STM32F7 (Cortex M7) port is GNU. The assertion happens when I provoked start() on my active object instance. And the assertion locates in qf/qf_qact.cpp, function QActive::register_()
Regards,
Tuyen
Last edit: tuyentm 2024-04-14
Hi Tuyen,
I'm sorry for confusing the orders of magnitude in my earlier response. This is because interrupt rate of 1MHz is so absurd that it didn't even cross my mind that it could be actually used. Most CPUs aren't capable of being interrupted so often. But if your super-performat CPU is capable, it would spend vast majority of of its time entering and exiting the interrupt (this is sometimes called "thrashing").
Anyway: no system can work with 1MHz clock tick. And I can say this for sure.
Regarding your timing diagram, it does NOT mean that the particular peripheral requires servicing avery 1microsecond. (1 microsecond is just one of many numbers in the timing diagram). You must be mixing simething here.
--MMS
Hi Miro and Panopticon,
Thank you all for your answers. I will reconsider my approach.
Regards,