arduino to IDF newbie help managing mulitple apps inline

[mtraven]

I have a project, it was all built in an arduino framework. It gets info from child boards via ESP now & displays it on a screen. I was nearly done, when I decided I wanted a clock on the screen. Between the display & espNow, I dont have enough DRAM to add the WIFI to get an update on the clock. I tried to do the clock update in setup(), but no matter what tried (every deinit & stop command I could find), I couldn’t get the memory to release…ands its a lot, like 56,000 bytes in a standard station mode. I dont need, or want it to be connected to wifi past it getting the time.

So now I’ve graduated to a native IDF framework. spent a few days setting up IDF for both vscode & platformIO. So far I like the PIO-IDF system better(except for menuconfig!), but I can use either if needed.

so what I would like to do is something like:
startup (bootloader app ?)
app1();
kill app1 completely
app2();

then I’ll schedule a restart once a day triggering the time to sync.

I have a basic understanding of task scheduling and I have studied the startup file in freeRTOS that links to the main app. I’m just not clear on how to implement a second app…or really what to search for on that subject. Please advice!

If there is a better general strategy towards doing this, I’m all ears.

PS
on a separate but related note: the NPT example in IDF is EXACTLY what that first app should be. There are notes in there that the “example_connect” function is simplified & should not be used in real work applications. How serious should I take that note? This isn’t a commercial product or anything & the clock is not super critical, can I get away with just using the example as is? I ask because, every time I try to add NTP to a working WIFI init & connect, it refuses to connect. Also, where is the actual code behind "example_connect" ? all I can find is the prototype.

PSS-- for a newb like me, do yall recommend I limit things to 1 core? Thats my understanding of how arduino was running it & without wifi, it handled it just fine. Seems people do that, at least at the beginning?

[liaifat85]

You can create separate components or FreeRTOS tasks for different functionalities, such as one for fetching data from child boards via ESP-NOW, one for displaying information on the screen, and another for managing the clock.

[MicroController]

Between the display & espNow, I dont have enough DRAM to add the WIFI to get an update on the clock

That sounds strange. Even with WiFi running, you should have a couple of hundred KB of heap available for the other stuff.
How big is your display (pixels)?

but no matter what tried (every deinit & stop command I could find), I couldn’t get the memory to release…ands its a lot, like 56,000 bytes in a standard station mode.

Reasonable approach. But 56k remaining unrecoverable even after de-initing everything WiFi related feels excessive; there may be something still lurking in the background you haven't yet caught/de-inited.

so what I would like to do is something like:
startup (bootloader app ?)
app1();
kill app1 completely
app2();
...
If there is a better general strategy towards doing this, I’m all ears.

An easier method may be to store a flag (with some kind of checksum) in RTC RAM after network time was acquired, then restart.
In app_main, you'd then do

Code: Select all

if( flagInRtcIsSet() ) {
// run normal app
} else {
// Aquire time from network, set flag in RTC, reboot.
}

You could also use the RTC time itself as a flag:

Code: Select all

if( currentYear() >= 2024 ) {
// run normal app
// then, once a day, 'clear' the current time to '0' (1970, or anything else), or subtract 50 years to be able to restore the old time if needed, reboot
} else {
// Aquire time from network, reboot.
}

There are notes in there that the “example_connect” function is simplified & should not be used in real work applications. How serious should I take that note? This isn’t a commercial product or anything & the clock is not super critical, can I get away with just using the example as is?

Look at the code (see below)
It's just 'example' code and not actually 'robust' w.r.t. recovery from errors/problems. If you can live e.g. with the chip rebooting upon error, or hanging 'forever' waiting for an IP address, or having the SSID+PW hardcoded in the program you could use the code as-is. Better copy the relevant parts from the example and adapt them as needed in your own app.

Also, where is the actual code behind "example_connect" ?

https://github.com/espressif/esp-idf/tr ... les_common

PSS-- for a newb like me, do yall recommend I limit things to 1 core? Thats my understanding of how arduino was running it & without wifi, it handled it just fine. Seems people do that, at least at the beginning?

Nope. For a limited set of 'advanced' use cases (e.g. 'manually' allocating interrupts) you may need to ensure some code runs on a specific core. Everything else is transparent to the application w.r.t. CPU cores. - The implication is that it doesn't matter if two tasks run on the same or different cores when it comes to interactions between tasks. Interactions must be properly synchronized; and FreeRTOS's synchronization primitives completely abstract away from cores for you.

[mtraven]

thanks for your thoughtful response.

my display runs at 640x 480 using the "double line" / fixed color palette method to half the memory (fabGL is the library). There is also a mouse & key board, whose tasks I've yet to find in the arduino version. I think the whole package bites off ~150k and when espNOW kicks in, its another 40k(on top of the 56k wifi that is still using) and then there is the actual program....i THINK i've accounted for most of the big stuff, but memory tracking is new to me. But you might be right, maybe I'm missing something...big reason why I got out of the arduino framework, so I'd have control & access to everything. but with that, comes a great deal of required learning.

While I was waiting for responses, I got the clock set via NPT, killed the task and started a new one where the clock time is still there! I know thats super basic, but it feels good to get it right in this new environment, kinda like your first "hello world". I used something like your last example, checking to see if the time was past year 2000.

The only reason I'm trying to get away with the simpleConnect is, the example connect to wifi(full) works by itself, but as soon as I add the code for the NPT server (not even call it), the connect will no longer connect. I'll give it another try, but the reality is, for my uses, the downsides you described really wont matter. and so far, I've not had an issues connecting, though occasionally it wont sync the time, despite being connected...it still moves on to my main program after failing, I just wont have a clock until restart again--no biggie.

oh and thanks for that link to the code for connect, I couldn't seem to find it anything, though I was only looking locally.

[MicroController]

Careful with deleting tasks:
https://esp32.com/viewtopic.php?f=13&t=38177#p127220
https://esp32.com/viewtopic.php?f=13&t=38378

TL;DR: Never pass anything other than NULL to vTaskDelete(...).

[mtraven]

I understand being careful with delete. I dont understand the rule about only passing null through it?
In what I have working, I'm using handles & checking that aren't NULL before deletion. Really new to this type of programing, so I'm just following tutorials at this point. I think I've got enough knowledge to start playing around with tasks. Unfortunately, I'm hung up trying to get the graphics library I was using, working in and IDF project. it claims to be compatible with ESP-IDF, though version is unspecified and I think there have been major changes since whatever it was made compatible with.

its looking like I'm going to have to abandon this entire endeavor. a shame really, I was excited to unlock all the behind the scenes stuff, just bit off more than I can chew.

[chegewara]

TL;DR: Never pass anything other than NULL to vTaskDelete(...).

Just ignore posts like this. It makes completely no sense.

Now your issue.
I would focus on code optimization rather than having few "apps" inside your firmware.
There is plenty option to "steal" some memory here and there. Some are "hidden" in menuconfig, like wifi buffers number.
Using dynamic allocations whenever you can, instead of global arrays, tasks stack etc.

Making big and complicated firmware on esp32, especially with wifi, ble and lvgl, is a challenge, but its doable.
https://docs.espressif.com/projects/esp ... usage.html
https://blog.espressif.com/esp32-memory ... cc75fe5431

Dont give up.

[MicroController]

TL;DR: Never pass anything other than NULL to vTaskDelete(...).

Just ignore posts like this. It makes completely no sense.

Quoting a forum member:

I am suggesting to answer in topics you know.

- or at least read the info I linked to before advising others to ignore things you don't understand.

[MicroController]

I understand being careful with delete. I dont understand the rule about only passing null through it?

As I explained in the linked posts, deleting a task from outside that task itself (other task, ISR) is 1) dangerous and 2) not trivial to do right. vTaskDelete(NULL) deletes the current task, and is inherently more safe than deleting another task, because, without employing further measures for synchronization/coordination, the current task is the only one who 'knows' when it is safe to be deleted.

[MicroController]

P.S.:
Dear Ché, let's not go there. I'd rather try and find the best solutions for people in a cooperative way than diminishing others. I'm not here to take anything away from anyone. I guess we could come up with excellent ideas by leveraging each other's experience.