Using osDelay(1) and HAL_ADC_PollForConversion with 0 timeout in FreeRTOS environment.

[bjbfj]

Hi,

I'm using the NUCLEO-64 STM32L476RG and I am aware that it is very simple to start the ADC to get a reading in an analog port. One should however wait for the conversion to complete and the HAL library has the HAL_ADC_PollForConversion() function that can be called with a timeout value.

However, HAL_ADC_PollForConversion() enters in a loop until the ADC finishes conversion; and I would like to release the CPU to perform other tasks (in FreeRTOS) while the conversion happens.

Thus, I am thinking about calling HAL_ADC_PollForConversion() with a 0 timeout value and call osDelay(1) if the return is HAL_TIMEOUT. (This would be repeated until the return is HAL_OK.)

However, I noticed in the HAL_ADC_PollForConversion code that a timeout causes the following two lines to be called:

 /* Update ADC state machine to timeout */

 SET_BIT(hadc->State, HAL_ADC_STATE_TIMEOUT);

 /* Process unlocked */

 __HAL_UNLOCK(hadc);

Would this prevent the ADC to complete the conversion process?

Would calling the HAL_ADC_PollForConversion 2 or more times (most likely 2) cause any unforeseen issues?

(Note: I could use the interrupts to receive a notification of the end of conversion; however, the reading of the analog value is not time critical.)

bjbf

[Artur IWANICKI · Accepted solution]

Hello,

It will work. In case ADC data will not be available function will return HAL_TIMEOUT (numerical 3). In case of data presence HAL_OK (numerical 0).

But calling this function one by one with 0 timeout will cost your application quite a lot of time.

I would recommend reading ADC conversions in interrupt mode. It would keep the complete process in the background and it will have small impact on your operating system timings.

In such a case important point would be a decision which interrupt priority should have ADC.

There are two options here:

- higher than OS. In this case ADC can interrupt operating system operations and you cannot execute any of OS functions from ADC interrupt procedure

- within OS group (numerically equal or higher than configMAX_SYSCALL_INTERRUPT_PRIORITY value specified in FreeRTOSConfig.h). In such a case you can use OS functions from this interrupt procedure, but from the other side it will be blocked by OS critical sections which are used in case of any OS component (task, semaphore, queue, SW timer, mutex) state modification

In both cases you will gain more time for your tasks and in case you would need those ADC data for some task, you can use semaphore to block it till ADC data will be available. 

[bjbfj]

Hi Artur,

Thanks for the complete answer. I agree.

bjbf