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] [December 2014 Threads]
Hello everybody.
After much effort a release candidate for FreeRTOS V8.2.0 has been made available for download. It is still in test, but in the mean time all comments and feedback will be greatly appreciated.
A change history is available, and the new direct to task notification mechanism is of particular note.
Regards.
Hi all,
- Where has FreeRTOS-Plus-TCP gone ?
Some people may wonder why the FreeRTOS V8.2.0 release only contains the earlier UDP library:
~~~~~
FreeRTOSV8.1.2/FreeRTOS-Plus/Source/FreeRTOS-Plus-UDP
~~~~~
and not +TCP? Whereas FreeRTOS-Plus-TCP is also a "Plus" product?
That is because +TCP is still in the Labs. Several users are helping us to test +TCP on several platforms. We have been testing it on Zynq, LPC18xx, and UC3A/SAM4E, and in the Windows' RTOSDemo.
In January we'll give extra attention to +TCP drivers for STM32F boards. Any updates of the drivers will be announced in this list and appear on:
http://www.freertos.org/tcp
Of course +TCP also includes other protocols like ARP
, ICMP
, UDP
, and some higher protocols like DHCP
, DNS
, LLMNR
, and NBNS
.
- Some people will remember the earlier post
FreeRTOS eating memory
:
https://sourceforge.net/p/freertos/discussion/382005/thread/945c8766
In fact FreeRTOS wasn't eating memory, but for some situations the implementation of queues and semaphores was maybe "over complete".
FreeRTOS' queues and semaphores can have many givers and many receivers. Their behaviour is deterministic (and therefore predictable) under all circumstances. That is all great but it makes them more expensive than other mechanisms / implementations.
It was around that time that the idea for the "task notification mechanism" was born. It has a single receiver and it may still have multiple givers. Beside being deterministic, the mechanism is fast and very economic.
I think that many semaphores can actually be replaced by "task notification".
E.g. an SPI interrupt can call vTaskNotifyGiveFromISR() to wake up the task waiting for SPI.
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.