Sorry for the slow reply, I had a busy couple of days. I'm glad it's working for you, and thanks for pointing out these things.
vic wrote:I only hit two minor snags : the git submodules don't use the public github addresses, recursive fetch won't work without a github certificate, it should be https://github/com/... instead of email@example.com/... (same problem with the link in the readme), and the esp-open-sdk must be built with STANDALONE=n.
Both fixed, thanks!
vic wrote:I also have a question, I tried to use a source C file in a subfolder but it wasn't picked by the make script. I took a look at the Makefile but I'm not sure how to fix this. They are strange and capricious things
I don't think this was actually possible before, at least in any simple way. So thank you for the feature request, I just implemented it.
The new options give you a few ways to do it. They're documented on the wiki here:
https://github.com/SuperHouse/esp-open- ... ld-Process
I also renamed "TARGET" to "PROGRAM" all through the makefiles, as "TARGET" was a bit ambiguous. So you'll need to change your Makefile too.
vic wrote:The example projects have different heap sizes configured in the FreeRTOSConfig.h file, some have 32k and some have 18k. With 18k the remaining heap after startup, as reported by xPortGetFreeHeapSize(), is only 3880 bytes, which seems really low. With 32k it is 18216 bytes which is more manageable. How do you determine the correct value ?
Yeah, good catch! I don't have a satisfactory answer for this yet.
At the moment heap is managed the "FreeRTOS way" where there is a fixed heap size, as you've seen. The potential maximum size for the fixed size heap is whatever is free in DRAM after all static rodata/bss allocations are done, with a small amount of headroom for the stack use of user_init/main/etc (FreeRTOS task stacks are allocated from inside the heap not outside). At the moment there's a lot of space taken up in DRAM by .rodata, as it contains all the constant string literals. There's an open issue discussing ways around that.
So for the examples I set the value by just finding the highest value I could set that didn't lead to an error at link time, minus some headroom. You can get clues by examining the 'make size' output. You should be able to bump the heap size up yourself until you hit this point, but you'll need to shrink it if you add more strings to your project! This is not a great solution, I realise.
The esp_iot_rtos_sdk doesn't use a fixed heap size and just uses whatever is free after rodata/bss for the whole heap. This is probably a better approach for nearly all use cases, unless you're really serious about controlling dynamic memory usage.
I'm in the process of adding in newlib for a libc, and as part of that I'll probably move from FreeRTOS' heap functions (malloc/free/etc) to newlib's ones, and from a fixed heap size back to a dynamic "everything that's left over" heap size.
Short answer: Bump it as high as you can without an error for now, and it will hopefully not be an issue soon!!
There's a related issue to this, which is that I want to make a single FreeRTOSConfig.h file with defaults and the examples just override any bits that they need to override. I haven't done this yet either, but I just opened an issue as a reminder (pull requests welcome!!)
Regarding initialization, some functions like wifi_station_scan need to be called after complete initialization (that's after user_init is called), but the system_init_done_cb function does not seem to be available. I'm just waiting 2 seconds instead and it works, but is there something to use instead?
Hmm, I had not tried this function and didn't realise it was broken. Do you know if it works in any versions of the esp_iot_rtos_sdk?
At the moment that's all handled in the binary libmain.a, but it should be replaced with open sourced code eventually as part of the "open source down the MAC layer" goal. It is possible that it's breaking just in esp-open-rtos for some reason, though... Maybe the IP stack is supposed to trigger the callback somehow.
Sorry for all the questions .
Not at all, please ask away! Really happy to see people using the framework!!