Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

BIG (but easy and simple) REQUEST !!!

Posted by ammaree on January 5, 2017

I suspect a new version of FreeRTOS is in the making and, just before it arrives as a very pleasant NY gift, I have a request.

Is there any chance to implement the task names for "IDLE" and Tmr Svc" a macro such as configTASKNAMETIMER and configTASKNAMEIDLE (or something similar) to enable names to be specified in the FreeRTOSConfig.h file.

The reason for my request is as follows: 1. We are trying to use the taskname directly as a parameter in syslog functionality as the ProcID field. 2. But, with the space in "Tmr Svc" it becomes seen as 2 different fields as per the RFC5424 3. The Tmr" portion becomes the ProcID and the "Svc" portion becomes the Msg ID field.

We currently change the name used in the source code but it would make life a bit more standard/simple if existence of the macros could be checked and if not there, the default is defined in FreeRTOS.h to the current names

Thanks


BIG (but easy and simple) REQUEST !!!

Posted by rtel on January 5, 2017

Consider it done.


BIG (but easy and simple) REQUEST !!!

Posted by ammaree on January 5, 2017

Thanks, as always much appreciated...

Now just a long shot, any chance of a close integration of FreeRTOS+TCP with the ESP32.

The use of FreeRTOS is already there and, based on discussions I have seen on the NuttX forum is appears as if EspressIf is planning to be very relaxed on the integration of their wireless (and other) firmware into differently licensed products.

Maybe have a look at: https://beta.groups.yahoo.com/neo/groups/nuttx/conversations/messages/13295

https://beta.groups.yahoo.com/neo/groups/nuttx/conversations/messages/14063

Similar to the ESP32 firmware integration into NuttX and it's TCP "stack" I believe an equivalent FreeRTOS and FreeRTOS+TCP integration will be magic.

And maybe a look at the SMP work already done with FreeRTOS is also worth it...

https://github.com/espressif/esp-idf/blob/master/components/freertos/readme_smp.txt

At the price point, considering the overall balance of 2x MCU @ 240Mhz, RAM, FLASH and peripherals, I think this device is going to become a killer..

Regards

Andre


BIG (but easy and simple) REQUEST !!!

Posted by rtel on January 6, 2017

Now just a long shot, any chance of a close integration of FreeRTOS+TCP with the ESP32.

I take it from your post the integration you have in mind is more than just a network interface for this device. What form of integration are you suggesting (I'm aware of the device, but not studied it).


BIG (but easy and simple) REQUEST !!!

Posted by ammaree on January 6, 2017

Essentially, making the ESP32 a perfect FreeRTOS platform requires: a) network interface to make FreeRTOS + TCP a clean replacement for current FreeRTOS + LwIP b) SMP support as EspressIf have developed to be finished and integrated.


BIG (but easy and simple) REQUEST !!!

Posted by heinbali01 on January 6, 2017

Hi André, thanks for letting know these great developments. I hadn't seen it yet.

Earlier, I played with a ESP8266 for its WiFi, but all I had was a closed-source library that implemented TCP sockets. It communicated through a serial (rs232) bus with AT-commands. The WiFi itself worked without a problem, but the throughput was very limited.

The ESP32 looks like a suitable device for using FreeRTOS+TCP. Does it also have a EMAC for LAN?

SMP:

What I do not know is what has to be done to make +TCP work for both cores. As you know, the stack runs a dedicated IP-task that handles all requests. It uses queues to send messages to the IP-task, and event groups for synchronisation purposes. The IP-task also handles some timers: check for re-transmissions, DNS- and ARP-look-ups, DHCP progress.

With the implementation of SMP and running on multiple cores, what is the use of a critical section (taskENTER_CRITICAL())? Is the task on the other core temporarily suspended? In other cases, only task switching is temporarily disabled (vTaskSuspendAll()), where interrupts are still allowed. Will the task running on the other core also be suspended?

Anyway, if anyone wants to implement a +TCP port for the ESP32, we'll be happy to give support for that.


BIG (but easy and simple) REQUEST !!!

Posted by heinbali01 on January 6, 2017

The ESP32 looks like a suitable device for using FreeRTOS+TCP. Does it also have a EMAC for LAN?

Answering my own question: yes it does: "an IEEE-802.3-2008-compliant Media Access Controller (MAC) is provided for Ethernet LAN communications"

The current public release of +TCP can only handle a single interface (NIC) with a single IP-address.

A new release +TCP/multi is now being tested which can handle multiple IP-addresses per interfaces, and it also allows (drivers for) multiple interfaces.


BIG (but easy and simple) REQUEST !!!

Posted by ammaree on March 24, 2017

Hi Hein,

Sorry for the long delay, was off on another project. Have just come back to the ESP32, hence some feedback.

The LWIP seems to be integrated fairly well and very much out of site, so unlikely to be a priority from our side to work on FreeRTOS+TCP port.

Having both wired and wireless working/active at same time, not a need for us although have read some comments on the forum trying to do that with LwIP.

In the process of trying to understand and profile the tasks created by ESP-IDF I found what "might" be a FreeRTOS inconsistency.

When uxTaskGetSystemState() is called it calls vTaskSuspendAll() which effectively suspends the task that called uxTaskGetSystemState(), hence the status of the calling task is not returned as eRunning which (strictly speaking) it was at the time of uxTaskGetSystemState() being called.

Andre


BIG (but easy and simple) REQUEST !!!

Posted by rtel on March 24, 2017

When uxTaskGetSystemState() is called it calls vTaskSuspendAll() which effectively suspends the task that called uxTaskGetSystemState(), hence the status of the calling task is not returned as eRunning which (strictly speaking) it was at the time of uxTaskGetSystemState() being called.

Hmm, interesting. As far as I recall vTaskSuspendAll() just sets a flag to say no context switches should occur. It doesn't change the state of any tasks, it does change the state of the scheduler. Therefore it is a badly named function. This has been recognised for a while, which is why in SafeRTOS it is called vTaskSuspendScheduler() - a more accurately descriptive name. So I would be surprised if what you report above was actually the case, but I would have to set up the scenario to be sure.


BIG (but easy and simple) REQUEST !!!

Posted by ammaree on March 24, 2017

Just had a check and you are correct. But the eCurrentState result returned for the running task that calls uxTaskGetSystemState() is definitely eReady (ie pending) and same as IDLE task...

So possibly the eCurrentState not updated to eRunning when the task is switched in?


BIG (but easy and simple) REQUEST !!!

Posted by rtel on March 24, 2017

I've just tried this and confirm the behaviour you report. Is has been fixed. Thanks for bringing it to our attention.


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




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists