timer callback restrictions and errors

[flexiti]

@anakod @hreintke

I think I found the reason for the appearance of # 198, I also think that the reason many other problems. #216 ? #222 ?

As soon as I corrected program in accordance with the instructions as follows problems have been resolved. For example. I measured the DS1820 in a timer callback,

also you have to be careful because:

eg Serial.println("I'm sending ...."); // IT'S 2ms Serial.println(float); // IT'S 4.2ms os_printf("Debug: %x | %x..%x (%d bytes)\n\r", 1,2,3,4); // IT'S 3 ms

also in many of the examples in the timer callback function using delay() > 10 ms

If the execution time of the timer call back is more than 500 ms, start TCP errors, and when it reaches 1500-2000 ms, the system hangs

What is your opinion ? What about threads in Sming ?

---

from SDK pdf: Notice： • Using non-OS SDK which is single-threaded, the CPU should not take long to execute tasks: ‣ If a task occupies the CPU too long, ESP8266 can't feed the dog, it will cause a watchdog reset； ‣ If interrupt is disabled, CPU can only be occupied in us range and the time should not be more than 10 us; if interrupt is not disabled, it is suggested that CPU should not be occupied more than 500 ms. • We suggest using a timer to check periodically, if users need to call os_delay_us or function while, or function for in timer callback, please do not occupy CPU more than 10 ms. • Using non-OS SDK, please do not call any function defined with ICACHE_FLASH_ATTR in the interrupt handler. • We suggest using RTOS SDK, RTOS to schedule different tasks.

---

from SDK 1.3 version info: 4.Optimize software timer to solve the ----->>>>> a connecting problem. Please do not call "os_delay_us" or "while" or "for" to occupy CPU more than 10 ms in timer callback. http://bbs.espressif.com/viewtopic.php?f=46&t=919

Please read my question in the forum bss http://bbs.espressif.com/viewtopic.php?f=66&t=1051

[flexiti]

It seems that other functions can't also be too long
(eg. connectOk (), connectFail ()). Therefore, all applications should be event driven (event not very long < 500 ms ??, Delay function < 10 ms) or .... threads

[hreintke]

@flexiti : I also noticed those remarks in release notes 1.3 and was wondering what the impact of that was for sming and the application it uses. First, I think the TCP error issues are caused by this. As far as I understand the (too long) CPU usage results in a wdt reset and that is not what is happening. Besides that they occur also already in sdk 1.2 Also for the 500ms limit, I've seen discussions on wdt resets and watchdog feed before. I don't know what the pre 1.3 limit on CPU occupation is/was but it definitely is not a new phenomenon. What worried me specificity was the limit of 10ms in timer callback. We should see what the effect of that is. Applications event driven. That's the design principle of espressifs sdk. People coming from arduino are used to the loop() and in that the use of os_delay. I am not sure/experienced in RTOS but going for threads in RTOS as suggested by espressif will not solve the limit on CPU usage in application code as is is not preemptive.

[flexiti]

@hreintke
@anakod The creation of a low-priority thread will be equivalent "arduino loop". It will be possible to write endless loops, loop the program will be continuations in his spare procesor time. Only you will watch watch-dog in this loop-thread.

ps.After modifications to my application i made, I have finally TCP me work many hours without a problem

[hreintke]

@flexiti : What modifications did you make to your application to have it working ?

[flexiti]

@hreintke I have not yet tried to do the thread Just remade-in support for DS1820 and instead eg. delay (1000) , I use a timer callbacks The same for delay(150)

and I removed unnecessary printf :) //----------------------------- //Delay(1000); os_timer_disarm(&delay1); os_timer_setfn(&delay1, (os_timer_func_t *)StaticDoMesure,this); ets_timer_arm_new(&delay1, 1000, 0, 0); return;

[hreintke]

@flexiti : If the removal of the delay() solves the tcp issue it might not be related to the upgrade to sdk 1.3.0 and the new specs but to the usage of delay. As far as I know the delay(xx) function only keeping the cpu busy for xx ms. That might cause missed tcp communication in lwip -> errors. PS What thread software do you think of ?

[flexiti]

@hreintke @anakod please read again my first post and read all info :)

Problem has no connection with the SDK 1.3, but with timer callback restrictions. I think, the SDK version 1.3 simply more describes the behavior of a timer callback, because there have problems with the transmission earlier.

see http://bbs.espressif.com/viewtopic.php?f=46&t=919 ---> Optymization point 4.

[lopelex]

looks interesting https://github.com/Makuna/Task

[flexiti]

Writing programs using Sming:

1. Maybe we just need to follow these rules associated with the timer? (timer callback< 500ms, delay() < 10ms) 2.Maybe we can implement Espressif ESP8266 RTOS? we could do something like the "Loop" from Arduino
2. or something as @lopelex writes https://github.com/Makuna/Task
3. or other suggestions

I wonder what @anakod thinks about it

[hreintke]

Adding to the above. Maybe be can do something with the system_os_task/system_os_post as provided by the sdk. The Makuna/Task looks a nice addition. It is not really task scheduling but gives a good/easy interface to event based functionality.

[anakod]

Sming himself completely based on asynchronous model (in contrast to Arduino), and that is fine. But we should improve delay functionality for some cases, and may be replace it somewhere (question with DS18B20 is the right example).

[flexiti]

As in my point 1, I can agree with it, but we have to look through all the examples and if need - adjust. Example reading BS1820 in loop is most used (many programs of different authors uses sming / DS1820 - even on github) and it should be corrected first. (eg. BMP180, DHT do not use such large delays) I also suggest adding some text information about the rules of programming using Sming, but I leave decision to @anakod :) By the way - great job :)

Saturday or Sunday I can help and look through all other examples for compliance with timer callback restriction

ps.It really helped, now my test board broadcasting (so far) 52 hours without any problems - previously only up to 2-15 hours.

[avr39-ripe]

May be I miss point of discussion, but here is my way of reading ds18b20 without delay.. https://github.com/avr39-ripe/HeatControl/blob/trikur/app/thermostat.cpp#L208 _temp_start fires every 4 second and instead of delay (750) it arms another one shot timer to start _read_temp after 750 ms.. works with other stuff and ajax updated temperature on web page for more than 24 hours.. so every time you need delay for a while you should arm some timer for that delay and split function in chuncks.. Another example to read multiple ds18b20 in efficient way is here https://github.com/avr39-ripe/ValveControl/blob/pure-esp/app/application.cpp#L63 First of all we ask all devices to start temperature conversion and then address each one to read measured temperature. Without delay (750) as well..

[anakod]

I also suggest adding some text information about the rules of programming using Sming, but I leave decision to @anakod :)

It will be very helpful! We have real lack of any documentation now :(

[hreintke]

@flexiti : Not saying that we should use this in Sming but have you seen the discusion on espressif bbs http://bbs.espressif.com/viewtopic.php?f=7&t=1055 where yield() from arduino project is mentioned ?

[flexiti]

@hreintke : I don't know what to say :) of course I read it tomorrow but : "This will mean that all contributors will have to submit a PR to a feature branch, it will be tested and then merged to develop" I am a little disappointed. So far the strength of this project was that immediately after the publication of a lot of people tested it. Now "It's your responsibility to ask people to test / code review features" Please read #256 #230 I must first understand these changes ;)

[AutomationD]

@flexiti please join I need to hear your concerns.

[flexiti]

@kireevco Those already written :) if I'm the only one who thinks that way you do not bother - I can adjust :) Now I will wait a little bit until it's all a bit sort out, that's all - I will not complain any more :) if you would like to know how I'd seen work with versions, let me know, it's Tuesday or Wednesday I can write directly to You.

ps. I'm sorry but I sit down to sming casual. Chat requires a particular time. This way exchange of information is not satisfactory?

[hreintke]

@flexiti : I agree completely. As I mentioned in the chat. If we/someone want to change the procedure. Produce a PR or Sming issue with a clear proposal. Then each of us can comment in his/her own timezone/timing. Outcome is then an agreed update and implementation without lots of discussions which takes energy I would better spend on pleasant items.

[AutomationD]

Guys, If anyone other than me really had a strong desire to do this - it had been done already. Now, when I am actually doing this, don't you think it is weird to start seeing passive resistance?

Produce a PR or Sming issue with a clear proposal

What's not clear about #230 ? It is a complete proposal for switching to git-flow.

Then each of us can comment in his/her own timezone/timing.

It's been 14 days since the issue has been created. How much time do you need?

Outcome is then an agreed update and implementation without lots of discussions which takes energy I would better spend on pleasant items.

@hreintke Didn't you agree on the proposal?

Please keep it constructive here https://github.com/anakod/Sming/issues/230

[flexiti]

a new version of the jib how to handle the DS1820 released, #266