These are chat archives for SmingHub/Sming

13th
Jul 2016
hreintke
@hreintke
Jul 13 2016 10:22
Yes, I have a preliminary/first/trial version locally which compiles "non rboot" applications.
Needs works, and will only be available with SmingRTOS
robotiko
@robotiko
Jul 13 2016 10:24
hi @hreintke, is it in a branch?
hreintke
@hreintke
Jul 13 2016 10:25
Hi, no not a branch. It is completely platformio (for now)
frankdownunder
@frankdownunder
Jul 13 2016 12:00

Here is what I have found regarding my problem "DelegateTask"(stack_size = 2,task handle = 3fff3548) overflow the heap_size.
I dug into the code of RTOS to find anything which might shed light on it, and saw
that "DelegateTask" is an RTOS task created inside the HardwareSerial class constructor, and is responsible for receiving characters. I can see that there is a check on the stack which happens on each context switch.
taskFIRST_CHECK_FOR_STACK_OVERFLOW();
I am not creating any RTOS tasks myself, nor am I calling anything to get characters from the serial port,
but I do expect RTOS to switch to the DelegateTask and block on xQueueReceive, just once.
When it does so, I get my error message - "DelegateTask"(stack_size = 2,task handle = 3fff3548) overflow the heap_size.

Being new to RTOS and fairly new to ESP8266 means I'm guessing a fair bit here.

So now I know I have overwritten memory somehow. If there are techniques anyone uses to find memory overwrites etc, pls share them.
In the end I resorted to removing functionality bit by bit until the error went away.
By doing so, the finger is firmly pointed at the prettyPrintTo function. After commenting out this code:
const uint16_t ConfigFileBufferSize = 3048;
char buf[ConfigFileBufferSize];
root.prettyPrintTo(buf, sizeof(buf));
fileSetContent(CONFIG_FILE, buf);
my memory corruption error message is gone.

hreintke
@hreintke
Jul 13 2016 14:00

@frankdownunder :
The issue is not in the prettyPrintTo function but in the way you make the call.
By using char buf[3048] you are taking 3048 bytes of stack which is way to high.
If you update to

char* buf = new char[3048];
root.prettyPrintTo(buf,3048);
...
...
delete(buf);

You will most probably have fixed your issue.
RTOS is sensitive on using stacksize. In your application you should only be using the char buf[..] for small values;

robotiko
@robotiko
Jul 13 2016 16:25
@hreintke > no not a branch. It is completely platformio (for now) do you mean it is already available in platformio?
Albert Moravec
@albru123
Jul 13 2016 17:18
Is it possible to replace the SDK PWM lib with this replacement one, so I could use it with HardwarePWM? https://github.com/StefanBruens/ESP8266_new_pwm
hreintke
@hreintke
Jul 13 2016 21:23
@albru123 : Not sure what you mean with " so I could use it with HardwarePWM"
HardwarePWM is a full implementation without need of anything else.
It is available within SmingRTOS.
I have currently no intention to add/change the implementation within SmingNONOS as new functionality will only be available within SmingRTOS.
@robotiko : No not available from platformio. It is a combination of platformio development version, Sming specific updates for that from pio team and local updates to make it work.
Albert Moravec
@albru123
Jul 13 2016 21:29
@hreintke So I should check-out SmingRTOS? I'm currently using SmingNONOS... I ignored RTOS because it seemed like a side-project
Btw that lib I posted is an optimized SDK replacement for libpwm.a
Albert Moravec
@albru123
Jul 13 2016 21:34
Well, not just optimized, you can find everything in the description
hreintke
@hreintke
Jul 13 2016 21:34
Yes, you should use SmingRTOS, it is full functional and has already features not present within SmingNONOS.
Did not check the full details but the lib provides a HardwarePWM which is already present in the Espressif RTOS SDK and which is used within SmingRTOS
Albert Moravec
@albru123
Jul 13 2016 21:38
Thanks, will definitely check that out!
frankdownunder
@frankdownunder
Jul 13 2016 22:24
@hreintke OK, thanks for that. I followed the example in ..\Sming\samples\Basic_WebSkeletonApp\app\configuration.cpp(44) which used the stack rather than the heap. Might be an idea to change the samples to encourage people in the right direction?