Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

task not running contiously

Posted by ehtane on February 28, 2019

hi ,

i have created three task with the priority as high ,normal and normal task once execute once


task not running contiously

Posted by rtel on February 28, 2019

I'm afraid without more information nobody will be able to assist: https://www.freertos.org/FAQ-how-to-use-the-FreeRTOS-support-forum.html

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by ehtane on March 1, 2019

hi ,

sorry for inconvienience I am using STM32F429 discovery board with free RTOS

i have created two task ,one task which need to trasnmit the data as received data interrupt ,so i have created binary semaphore and it will wait forever and if received interrupt generated it release the task . Second task is the sd card write task which should write the data every after 15 min and in this i have implemented if(xSemaphoreTake(semHandle, 1000 )) and it enter after 1 sec and increase the counter and when the counter reaches 900 it will write the data .

but this not happen so can you please guide me for the same

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by rtel on March 1, 2019

Please share a little of the code so we can see how the semaphore is created, 'given' and 'received'.

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by ehtane on March 1, 2019

hi,

please refer the attached code

Attachments

main_01-03-2019____.c (29374 bytes)

task not running contiously

Posted by ehtane on March 1, 2019

hi,

please refer the attached code

Attachments

main_01-03-2019____.c (29374 bytes)

task not running contiously

Posted by ehtane on March 4, 2019

hi waiting for your reply

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by richarddamon on March 4, 2019

One big question looking at the code, does HALUARTTransmit return before the messge is sent, or does it just spin wait for the completion. If it spin waits (as seems common in the HAL code) then that task will hog the CPU.

I have found that much of the HAL code isn't very friendly to the RTOS environment.

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by ehtane on March 5, 2019

hi richard ,

thanks for the respone i think it just spin and wait for the complletion so what is the best option instead of hal_code

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by ehtane on March 5, 2019

hi waiting for your reply . One more query 1 .if one task is running and if interrupt occur and do some action ,the task does not resume again how do that ,sorry if i have some mistaken as i am new to freeRTOS

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by richarddamon on March 5, 2019

In my experiance, many manufactures 'HAL' type drivers aren't designed well for use in real time OSes, as they will tend to use things like spin wait. Also they tend to be designed to make your program portable only between processors of that manufacturer, not over a wider set of processors. What I find works the best for me is to first design an device agnostic API for using such devices, and then writing a device specific driver that implements it. This driver might use the HAL code if it is suitable, or another low level driver, or one you self write based on looking at the supplied drivers. In my experiance, many serial drivers are based on you give them a message, that message is printed and the you can give a new message (but only after the first is sent), while I prefer a model where you give the driver a message, it is added to an internal queue, and starts printing it, and more characters can be added as you go. The first is an easier driver to write, the second is an easier driver to use, and tends to not block the task printing as much, which is good in an RTOS based application.

As to your second question, when an interrupt occurs, the processor will jump into the ISR for the interrupt, which should do some short action to handle the interrupt and then return. If done correctly, FreeRTOS will continue to run the highest priority task that is ready to run, and and if the ISR caused a higher priority task to become ready it will run, and continue to run until it blocks for something again. The issue with your program is that the serial task was higher priority, but because it was just spin waiting for the serial port, it continued to be ready to run for the whole time, so never blocked. When it got back to the Semaphore Take, the semaphore had been given by the message being done, so it just continued. If the serial driver properly used interrupt to send the message, as opposed to spin waiting for the port, then the serial task would block, and let your lower priority task run.

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by ehtane on March 6, 2019

thanks for the reply i will try to implement as per your comment

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by ehtane on March 6, 2019

hi ,

  1. i have written one task want to be sure that semaphore will enter only after 1 sec ?? below is the code plz advice if it is correct void taskWrite(void const * argument) { /* USER CODE BEGIN taskFlashWrite */

    uint8t tickcount = 0; const TickTypet xPeriod = pdMSTOTICKS( 1000 ); //1000 ms

/* Infinite loop */ for(;;) { if(xSemaphoreTake(semFlashHandle, xPeriod )) {

      }
      xSemaphoreGive(semFlashHandle);
      osDelay(1);
  }

}

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by richarddamon on March 6, 2019

xSemaphhoreTake(handle, period) will return after the SHORTER of period ticks or when the semaphore is given. Not positive about osDelay (as that isn't part of FreeRTOS) but that will probably be a delay of 1 system 'tick' or maybe 1 ms (which may round down to 0 ticks).

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by ehtane on March 15, 2019

hi richard instead of xSemaphhoreTake(handle, period) i am generating freeRtos software timer using cubeMx but it is not working i have made sure that /* Software timer definitions. */ 1. ##define configUSETIMERS 1** 1. ##define configTIMERTASKPRIORITY ( 2 ) 1. ##define configTIMERQUEUELENGTH 10 1. ##define configTIMERTASKSTACKDEPTH 256**

osTimerStart(myTimerFWriteHandle, 60000); has been written before osKernelStart(); it get stuck somewhere and oskernelstart() does not get called . but if i put manually the timer code it works???

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by rtel on March 15, 2019

osTimerStart(myTimerFWriteHandle, 60000); has been written before osKernelStart(); it get stuck somewhere and oskernelstart() does not get called .

If you are not getting as far as starting the kernel then it should be easy for you to step through the code in the debugger and see where you end up. Probably in an assert. Debugging before mutli-threading starts is much simpler.

but if i put manually the timer code it works???

Sorry, not sure what that means.

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by ehtane on March 18, 2019

but if i put manually the timer code it works???

Without using cubeMx if i create the timer and start it ,it works ??

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by ehtane on March 18, 2019

hi richard,

below is the code when i debug it goes upto oskernel start(),and i put the breakpoint in timercallback01() it does not goes into it ?? plz if you can help me out int main(void) { /* USER CODE BEGIN 1 */

/* USER CODE END 1 */

/* MCU Configuration----------------------------------------------------------*/

/* Reset of all peripherals, Initializes the Flash interface and the Systick. */ HAL_Init();

/* USER CODE BEGIN Init */

/* USER CODE END Init */

/* Configure the system clock */ SystemClock_Config();

/* USER CODE BEGIN SysInit */

/* USER CODE END SysInit */

/* Initialize all configured peripherals / MXGPIOInit(); MXDMAInit(); MXUSART1UARTInit(); MXSPI1Init(); MXI2C3Init(); MXADC1Init(); MXRTCInit(); MXTIM1Init(); MXUSART3UARTInit(); MXUSART2UARTInit(); MXIWDG_Init(); / USER CODE BEGIN 2 */

/* Enable Uart1 Interrupt*/ _HALUARTENABLEIT(&huart1, UARTITRXNE); // enable idle line interrupt _HALUARTENABLEIT(&huart1, UARTITTC); // enable idle line interrupt HALUARTReceiveIT(&huart1, (uint8t *)&Usart1byte, sizeof(Usart1byte));

/* Enable Uart2 Interrupt*/ _HALUARTENABLEIT(&huart2, UARTITRXNE); _HALUARTENABLEIT(&huart2, UARTITTC); HALUARTReceiveIT(&huart2,(uint8t *)&gsmbyte, sizeof(gsmbyte));

/* Enable Uart3 Interrupt*/ _HALUARTENABLEIT(&huart3, UARTITIDLE); // enable idle line interrupt _HALDMAENABLEIT (&hdmausart3rx, DMAITTC); // enable DMA Tx cplt interrupt HALUARTReceiveDMA (&huart3, DMARXBuffer, DMARXBUFFERSIZE); hdmausart3rx.Instance->CR &= ~DMASxCRHTIE; // disable uart half tx interrupt

_HALRCCRTCENABLE(); /* USER CODE END 2 */

/* Create the mutex(es) / / definition and creation of uartMutex */ osMutexDef(uartMutex); uartMutexHandle = osMutexCreate(osMutex(uartMutex));

/* USER CODE BEGIN RTOSMUTEX / / add mutexes, ... / / USER CODE END RTOSMUTEX */

/* Create the semaphores(s) / / definition and creation of semUART1 */ osSemaphoreDef(semUART1); semUART1Handle = osSemaphoreCreate(osSemaphore(semUART1), 1);

/* definition and creation of semGSM */ osSemaphoreDef(sem02); sem02Handle = osSemaphoreCreate(osSemaphore(sem02), 1);

/* definition and creation of semFlash */ osSemaphoreDef(semFlash); semFlashHandle = osSemaphoreCreate(osSemaphore(semFlash), 1);

/* definition and creation of myCountingSem01 */ osSemaphoreDef(myCountingSem01); myCountingSem01Handle = osSemaphoreCreate(osSemaphore(myCountingSem01), 2);

/* USER CODE BEGIN RTOSSEMAPHORES / / add semaphores, ... / / USER CODE END RTOSSEMAPHORES */

/* Create the timer(s) / / definition and creation of myTimer01 */ osTimerDef(myTimer01, Callback01); myTimer01Handle = osTimerCreate(osTimer(myTimer01), osTimerPeriodic, NULL);

/* USER CODE BEGIN RTOSTIMERS */ // __HALIWDGSTART(&hiwdg); osTimerStart(myTimer01Handle, 1000); /* start timers, add new ones, ... / / USER CODE END RTOSTIMERS */

/* Create the thread(s) / / definition and creation of taskUart1 */ osThreadDef(taskUart1, taskUART, osPriorityHigh, 0, 128); taskUart1Handle = osThreadCreate(osThread(taskUart_1), NULL);

/* definition and creation of taksFlashWrite */ osThreadDef(taksFlashWrite, task_sdWrite, osPriorityNormal, 0, 128); takssdWriteHandle = osThreadCreate(osThread(takssdWrite), NULL);

/* definition and creation of myTask03 */ osThreadDef(myTask03, task_03, osPriorityBelowNormal, 0, 128); myTask03Handle = osThreadCreate(osThread(myTask03), NULL);

/* USER CODE BEGIN RTOSTHREADS / / add threads, ... / / USER CODE END RTOSTHREADS */

/* USER CODE BEGIN RTOS_QUEUES / / add queues, ... */

/* USER CODE END RTOS_QUEUES */

/* Start scheduler */ osKernelStart();

Attachments

rr2.c (27489 bytes)

task not running contiously

Posted by rtel on March 18, 2019

Unfortunately none of this is using the native FreeRTOS API, so I can't be sure of the relative priorities. It looks like taskUart_1 is the highest priority task that you create. If you put a break point in there, does it get hit? Does that have a priority above the timer task priority? If you put a break point at the start of the timer task (prvTimerTask() in FreeRTOS/source/timers.c), does that get hit?

Attachments

rr2.c (27489 bytes)


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo, Nuvoton Cortex-M23 demo & STM32H745 dual core (AMP) demo.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Mediatek

Renesas

RISC-V

SiFIve RISC-V

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner