ESP8266 Community Forum

- Thu Jun 11, 2015 7:52 pm #20211 Hi vic,

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.

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 git@github.com/... (same problem with the link in the readme), and the esp-open-sdk must be built with STANDALONE=n.

Both fixed, thanks!

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.

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

- Tue Jun 16, 2015 5:02 pm #20635

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.

There's now a 'newlib' branch on github that uses newlib as a libc (via esp-open-sdk/crosstool-ng). Much easier memory management! Still experimental but it should be merged to
'master' soon, I just need to figure out a couple of things to make it easier to set up.

If you want to use it as-is at the moment then you'll need my fork of jcmvbkbc's crosstool, here:
https://github.com/projectgus/crosstool-NG/

... but you also need to build it from esp-open-sdk so you get the 'libcirom' variant (hence the part about it needing to made simpler to set up!)

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

This is done now in master, (hopefully) no more divergent FreeRTOSConfig headers in the examples!


Angus

- Mon Jan 02, 2017 4:17 pm #60284 Hi,

I just started using esp-open-rtos for building sensors committing data to an influx-db using TLS 1.2 (HTTPS). Thank you for providing this amazing project.

I have a few questions I could not find answers by now. Maybe someone here can help me. I miss some functions in esp-open-rtos I can find in esp-rtos-sdk (and I used before in my NON-SDK code).

These are for example:

sint8 wifi_station_get_rssi(void);
bool wifi_station_set_hostname(char *name);

Is there any chance to get them also in esp-open-rtos? Can anybody point me in the right direction what to do?

I tried to use the esp-open-rtos mailinglist on google groups. But it seems to be very quiet. Is there another channel to communicate with the esp-open-rtos community?

Or is esp-open-rtos a dead path? I also thought about using esp-rtos-sdk but the build system drives me mad and actually I like the open-approach of esp-open-sdk and esp-open-rtos.

Thank you.