FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [April 2017 Threads] Side-effects of using semaphore without creatingPosted by gpathak on April 6, 2017 Hello Experts,
I am using FreeRTOS version 8.1.2 on Realtek Ameba board. I have written a code where I am using xSemaphoreGive() and xSemaphoreTake() without creating the semaphore.
I want to know what can be the issue of calling these functions without creating a semaphore.
Side-effects of using semaphore without creatingPosted by heinbali01 on April 6, 2017 Very often you will find out that FreeRTOS is lean: in many cases it assumes that parameters have been checked by you.
The functions xSemaphoreGive() and xSemaphoreTake() must be called with a valid semaphore handle.
If you want to let a task just block, you can use e.g. vTaskDelay() .
Side-effects of using semaphore without creatingPosted by gpathak on April 6, 2017 Thanks for your reply @Hein Tibosch.
I am not looking for Delaying and blocking a task.
I just want to know the pitfalls, can it cause a hardfalut or crash if xSemaphoreGive() and xSemaphoreTake() is called without creating a semaphore?
Side-effects of using semaphore without creatingPosted by richard_damon on April 6, 2017 Yes, calling any FreeRTOS function with an uninitialize handle has put your proogram into an undefined state and virtually anything can happen. If you are lucky, the call will fault and crash.
My general policy is to create ALL of my Queue, Semaphore and Mutexes that the program will need prior to starting the scheduler, so that it makes it much harder to have that problem.
An alternative is to make sure the handles are zeroed at startup and check the handle prior to making the call, skipping the call or creating the item if it is zero.
Side-effects of using semaphore without creatingPosted by rtel on April 6, 2017
Very often you will find out that FreeRTOS is lean: in many cases it
assumes that parameters have been checked by you.
FreeRTOS is designed to keep the code size down. While you are
developing checking is performed using configASSERT() (although it
assumes things are zero'ed out), then when your code is ready for
production, you define configASSERT() away and get smaller faster code -
at which point you should make sure all your tests are still working.
SafeRTOS on the other hand has explicit validity checks in C, so
everything is checked, all the time.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|