These are chat archives for esp8266/Arduino

1st
Oct 2015
Ivan Grokhotkov
@igrr
Oct 01 2015 05:57
FSBrowser sketch by @me-no-dev adapted for the new FS API
xbary
@xbary
Oct 01 2015 08:28
and we Profi hardware platform ... >> http://www.wemos.cc/d1/Main_Page
Mario Mikočević
@mozgy
Oct 01 2015 12:57
@igrr old nodemcu 0.9 upload bug is back
Ivan Grokhotkov
@igrr
Oct 01 2015 13:10
i'm not sure this is the same old bug. previously the bug was due to reset method not being set correctly... however right now in boards.txt we have
nodemcu.upload.resetmethod=nodemcu
so this is something different
which OS are you using?
Russ Mathis
@RussMathis
Oct 01 2015 13:16
@igrr, is there a simple way to provide WiFiClient the Server feature StreamFile ?
Ivan Grokhotkov
@igrr
Oct 01 2015 13:19
You just open the file, and then call client.write(file, file.size())
Russ Mathis
@RussMathis
Oct 01 2015 13:20
Cool--Thanks, and I like the update FSBrowser source! Your coding style is very elegant! LOL! Thanks.
Ivan Grokhotkov
@igrr
Oct 01 2015 13:21
is I mentioned above that's a sketch by @me-no-dev, so all credit goes to him
i have just commented out some stuff which stopped working after FS API change ;-)
Russ Mathis
@RussMathis
Oct 01 2015 13:22
Oops my bad, still the same excellent coding tech! and great utility for learning!
@igrr, while building the FSBrowser I get SPIFFS.exists does not exist?
Never, mind I see the updated staging version! :)
Mario Mikočević
@mozgy
Oct 01 2015 13:43
@igrr atm linux here, I'll check on win7 later today
Ivan Grokhotkov
@igrr
Oct 01 2015 13:45
esptool has not been updated since the last staging version, so not sure what's going on...
Russ Mathis
@RussMathis
Oct 01 2015 13:55
@igrr, having issues building, have been using visual studio great until this latest staging version but now getting:ld.exe:cannot open linker script file {build.flash_ld}: No such file or directory
collect2.exe*:error: ld returned 1 exit status
Error creating .elf
Ivan Grokhotkov
@igrr
Oct 01 2015 13:57
Does it work with Arduino IDE?
Russ Mathis
@RussMathis
Oct 01 2015 13:57
Yes
Ivan Grokhotkov
@igrr
Oct 01 2015 13:57
just to rule out installation issues...
okay
Russ Mathis
@RussMathis
Oct 01 2015 13:57
"C:\Users\Russ\AppData\Roaming\arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\1.20.0-26-gb404fb9-2/bin/xtensa-lx106-elf-gcc" -g -Os -nostdlib -Wl,--no-check-sections -u call_user_start -Wl,-static "-LC:\Users\Russ\AppData\Roaming\arduino15\packages\esp8266\hardware\esp8266\1.6.5-1160-gef26c5f/tools/sdk//lib" "-LC:\Users\Russ\AppData\Roaming\arduino15\packages\esp8266\hardware\esp8266\1.6.5-1160-gef26c5f/tools/sdk//ld" "-T{build.flash_ld}" -Wl,-wrap,system_restart_local -Wl,-wrap,register_chipv6_phy -o "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic/FSBrowser.elf" -Wl,--start-group "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\FSBrowser.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\ESP8266mDNS\ESP8266mDNS.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\ESP8266WebServer\ESP8266WebServer.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\ESP8266WebServer\Parsing.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\ESP8266WiFi\ESP8266WiFi.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\ESP8266WiFi\ESP8266WiFiMulti.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\ESP8266WiFi\WiFiClient.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\ESP8266WiFi\WiFiClientSecure.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\ESP8266WiFi\WiFiServer.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic\ESP8266WiFi\WiFiUdp.cpp.o" "C:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic/core.a" -lm -lgcc -lhal -lphy -lnet80211 -llwip -lwpa -lmain -lpp -lsmartconfig -lwps -lcrypto -laxtls -Wl,--end-group "-LC:\Users\Russ\AppData\Local\V.Micro\Arduino\Builds\FSBrowser\generic"
Ivan Grokhotkov
@igrr
Oct 01 2015 13:58
yeah, {build.flash_ld} option didn't get expanded for some reason.
Russ Mathis
@RussMathis
Oct 01 2015 13:59
hmm can this be modified with hard coded text, not familiar with it?
Mario Mikočević
@mozgy
Oct 01 2015 14:01
@igrr nodemcu v1.0 works fine ..
btw, I'm getting - /home/mozgy/.arduino15/packages/esp8266/hardware/esp8266/1.6.5-1160-gef26c5f/cores/esp8266/libc_replacements.c:408:22: warning: 'struct tm' declared inside parameter list [enabled by default]
time_t mktime(struct tm *timp) {
only first time after board change tho
Ivan Grokhotkov
@igrr
Oct 01 2015 14:04
you can ignore this warning...
it was fixed last night, will be in the next staging
Mario Mikočević
@mozgy
Oct 01 2015 14:05
ty
Ivan Grokhotkov
@igrr
Oct 01 2015 14:05
@RussMathis i suppose you can replace {build.flash_ld} in platform.txt with the value of .flash_ld parameter for your board of choice
look that up in boards.txt
Russ Mathis
@RussMathis
Oct 01 2015 14:06
ok, thx
Mario Mikočević
@mozgy
Oct 01 2015 18:02
@igrr nodemcu 0.9 works fine on win7 x64 .. (upload that is)
d-anders
@d-anders
Oct 01 2015 18:14
hm, so basically user_rf_pre_init is for power saving?
Thorsten von Eicken
@tve
Oct 01 2015 18:30
FYI, a change in SDK 1.4 makes it impossible to receive wifi change events when running an idle loop. I'm 99% sure that this affects the esp8266/arduino project. See http://bbs.espressif.com/viewtopic.php?f=7&t=1182 and please chime in if it affects you (or tell me how to work around it if it doesn't affect you).
Ivan Grokhotkov
@igrr
Oct 01 2015 21:56
@tve there was a small change to the way pp_post() works, so yes, i had to make a change to the way my main loop is scheduled. I was planning to do that for a long time already, seems like Espressif has encouraged me to finally do that :)
Thorsten von Eicken
@tve
Oct 01 2015 21:57
So, how are you doing it now?
And have you tried it with SDK 1.4?
Ivan Grokhotkov
@igrr
Oct 01 2015 21:59
Basically, don't schedule the task before ets_run finishes its task-checking loop. Instead, schedule the task from idle callback.
Yes this works quite well with 1.4
Thorsten von Eicken
@tve
Oct 01 2015 22:00
Do you have a link to the code on github? I may be looking at the wrong branch.
Ivan Grokhotkov
@igrr
Oct 01 2015 22:01
I don't have that code on github. I'm still running tests to see if there were regressions, so not going to push 1.4 update until that's done.
something along these lines:
diff --git a/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_main.cpp b/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_main.cpp
index a953c87..1e7b446 100644
--- a/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_main.cpp
+++ b/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_main.cpp
@@ -41,7 +41,7 @@ struct rst_info resetInfo;
 int atexit(void (*func)()) {
     return 0;
 }
-
+extern "C" void ets_set_idle_cb(void (*fn)(void), void*);
 extern "C" void ets_update_cpu_frequency(int freqmhz);
 void initVariant() __attribute__((weak));
 void initVariant() {
@@ -79,10 +79,14 @@ extern "C" void esp_yield() {
     }
 }

-extern "C" void esp_schedule() {
+void esp_post_task() {
     system_os_post(LOOP_TASK_PRIORITY, 0, 0);
 }

+extern "C" void esp_schedule() {
+    ets_set_idle_cb(&esp_post_task, nullptr);
+}
+
 extern "C" void __yield() {
     if (cont_can_yield(&g_cont)) {
         esp_schedule();
@@ -116,6 +120,7 @@ static void loop_wrapper() {

 static void loop_task(os_event_t *events) {
     g_micros_at_task_start = system_get_time();
+    ets_set_idle_cb(nullptr, nullptr);
     cont_run(&g_cont, &loop_wrapper);
     if(cont_check(&g_cont) != 0) {
         ets_printf("\r\nsketch stack overflow detected\r\n");
@@ -135,7 +140,6 @@ void init_done() {
     esp_schedule();
 }
Thorsten von Eicken
@tve
Oct 01 2015 22:04
ah, didn't know about ets_set_idle_cb, I guess another undocumented feature... sounds like exactly what I asked for in my post on the espressif forum..
Ivan Grokhotkov
@igrr
Oct 01 2015 22:05
i think if you're going to use it, you would benefit from reading the code of ets_run...
Thorsten von Eicken
@tve
Oct 01 2015 22:06
why do you system_os_post in esp_post_task as opposed to calling cont_run(&g_cont, &loop_wrapper); ? is that because the idleCb happens in the wrong task?
where do I find ets_run? In the old SDK 0.9 sources that are around?
Ivan Grokhotkov
@igrr
Oct 01 2015 22:09
this is due to the way ets_run works. once idle callback is complete, CPU starts waiting for an interrupt. therefore if you run your loop from the idle callback as opposed to running it from the task, it will run once, and then CPU will sleep until next interrupt. so your loop will be gated by interrupts...
Thorsten von Eicken
@tve
Oct 01 2015 22:16
thanks for the explanation. I saw some code from pvvx. but does system_os_post cause an interrupt?
Ivan Grokhotkov
@igrr
Oct 01 2015 22:27
good point. i checked with a debugger and it turned out the loop was actually resumed by CCOMPARE interrupt :)
will fix that.
Thorsten von Eicken
@tve
Oct 01 2015 22:31
you speak in riddles :-)
Ivan Grokhotkov
@igrr
Oct 01 2015 22:35
sorry for not making sense... i was referring to the infinite loop inside ets_run function, which is in ROM. you can take a look at its code by opening ROM elf file using a disassembler of your choice.
i have (incorrectly) thought that calling ets_post would cause a software interrupt which would fire at the point when waiti, 0 instruction is reached.
your question made me go and check this assumption, and it turned out that ets_post didn't cause an interrupt. instead, CCOMPARE interrupt fired which made CPU resume from wait state, and caused the infinite loop inside ets_run to continue
Thorsten von Eicken
@tve
Oct 01 2015 22:42
OK, makes sense. I assume you are not setting the CCOMPARE register and it's simply set by the SDK for other purposes? In that case we still need something that reliably forces an interrupt?
It sounds like the "idle_callback" really is intended as a callback just before going idle, as opposed to a continuous callback while idle.
Ivan Grokhotkov
@igrr
Oct 01 2015 22:44
CCOMPARE was set as a side effect of using timer0 in the same sketch.
i think i will simply trigger software interrupt, i don't think it's used for anything.
Ivan Grokhotkov
@igrr
Oct 01 2015 22:52
xthal_set_intset(1<<ETS_SOFT_INUM); seems to do the trick
Thorsten von Eicken
@tve
Oct 01 2015 22:58
mhh, you're too smart ;-). It would be really good to get Espressif to provide the functionality we need as opposed to us all hacking around it, don't you think? Maybe you would add your voice to the thread on the Espressif forum: http://bbs.espressif.com/viewtopic.php?f=7&t=1182 or start your own request there?
Ivan Grokhotkov
@igrr
Oct 01 2015 23:03
actually i think i will be better off rolling my own main loop, replacing ets_run. seeing how easily Espressif breaks things, i'd rather have minimal possible amount of SDK code in my project.
Thorsten von Eicken
@tve
Oct 01 2015 23:03
Q: how bad is a os_timer_arm of 0ms? I don't have jtag debug capability... does the os_timer stuff only fire every millisecond so setting it to 0ms duration waits for the expiration of the current ms quantum?
Ivan Grokhotkov
@igrr
Oct 01 2015 23:04
i can think of quite a few ways Espressif can fulfill this feature request, breaking some things at the same time...
Thorsten von Eicken
@tve
Oct 01 2015 23:06
well, even if you roll your own ets_run loop you're not guaranteed that Espressif won't break stuff for you. The loop is pretty tied in with other functionality. I assume you've seen https://github.com/pvvx/EspLua/blob/master/app/main/ets_run.c ?
Ivan Grokhotkov
@igrr
Oct 01 2015 23:08
yes, that's another way to customize ets_run, adding a way to run tasks above certain level and return.
ideally such things should be outside of the SDK, or at least customizable as in Nordic's nRF5x SDK.
Ivan Grokhotkov
@igrr
Oct 01 2015 23:19
regarding os_timer_arm(0), i will check tomorrow.
ets_timer (or os_timer) uses a linked list of timer events dispatched using interrupt # 10. there's some error checking and bounds checking done on the argument, need to see if value of 0 will cause interrupt to fire "at once"
Angus Gratton
@projectgus
Oct 01 2015 23:24
I'm coming to this late, but is what you need to do just triggering any interrupt to bypass a waiti?
Ivan Grokhotkov
@igrr
Oct 01 2015 23:25
yes, software interrupt works fine for this.
Angus Gratton
@projectgus
Oct 01 2015 23:25
ok :)
Ivan Grokhotkov
@igrr
Oct 01 2015 23:26
but still this is less than ideal solution. i did a benchmark, and my busy loop spins a few orders of magnitude slower than before the upgrade to 1.4.0
i have a few other ideas, will try them out tomorrow or on the weekend... it's past 2am here already.
for now will just stick to the SDK 1.3
Thorsten von Eicken
@tve
Oct 01 2015 23:40
@igrr thanks for sharing the info! If you would ping me when you come up with a solution I would appreciate. In the meantime I'm going to continue with a os_timer_arm(0) which works "OK" in my context.