BIG (but easy and simple) REQUEST !!!

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 !!!

Consider it done.

BIG (but easy and simple) REQUEST !!!

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 !!!

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 !!!

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 !!!

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 !!!

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 !!!

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 !!!

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 !!!

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 !!!

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