These are chat archives for esp8266/Arduino

26th
Jan 2016
Michael Miller
@Makuna
Jan 26 2016 00:06
@igrr FYI: Servo fix pull was created. There is an interesting little routine in it, a "map" function that is more symmetrical. the constants for the fixed point are good enough for this case, other uses may require more bits so as written its not a general case solution.
VNArmy
@VNArmy
Jan 26 2016 03:36
@me-no-dev : I'm reading your ESPAsyncTCP. But there's no examples. Could you pls give me some examples about it like Telnet2Serial. Thanks.
Aditya Tannu
@AdySan
Jan 26 2016 04:00
If OTA sketch upload is working form IDE, SPIFFS upload should work too right?
If I do Tools > ESP8266 Sketch Data upload, I get
error: cannot access 192.168.1.2

error: espcomm_open failed
Aditya Tannu
@AdySan
Jan 26 2016 04:15
Never mind, just found this! Hadn't updated the ESP8266FS tool in a while esp8266/arduino-esp8266fs-plugin#4
PyB
@PyBerger
Jan 26 2016 06:53
@me-no-dev got it to link by putting my code in core_wiring_analog as well (was in .ino - no clue why it wouldn't work here)
When using it, though, I have problems as I always read 215 (decimal) whereas with the system_adc_read function I do read a 1 (input grounded).. Any clue why this could be ?
Ivan Grokhotkov
@igrr
Jan 26 2016 09:00
@PyBerger the reason it works in .c and doesn't work in .ino is because C allows implicit function declarations, while C++ doesn't. When you reference a function which hasn't been declared in C, compiler creates an implicit declaration based on the arguments you have provided. C++ doesn't allow that, so the undeclared function is reported as an error (error: 'rom_i2c_writeReg_Mask' was not declared in this scope)
Me No Dev
@me-no-dev
Jan 26 2016 09:08
@VNArmy here is a telnet server example :) https://gist.github.com/me-no-dev/116e417ea6a3bbc98b08
still heavily working on the lib to make sure it's all in proper condition before adding examples and docs
PyB
@PyBerger
Jan 26 2016 09:26
@igrr I understand this, and I was adding a tentative declaration in my ino file... the compilation was fine but the link was failing.
Ivan Grokhotkov
@igrr
Jan 26 2016 09:26
Did you add extern "C" before that declaration?
PyB
@PyBerger
Jan 26 2016 09:27
no that I didn't - that was my mistake I guess
anyway you guys are doing a great job with all this !
@igrr have you ever used this 'fast ADC' routine ?
andig
@andig
Jan 26 2016 09:30

@igrr getting some compile errors on the heap4c.cpp. Anything else I should look at? E.g.

cannot convert 'xBlockLink* {aka A_BLOCK_LINK*}' to 'const uint8_t* {aka const unsigned char*}' for argument '1' to 'void printhex(const uint8_t*, size_t)

This is before deleting the sdk module.

Me No Dev
@me-no-dev
Jan 26 2016 09:32
@andig it's a warning not an error :) it's working fine
andig
@andig
Jan 26 2016 09:36
nope, an error unfortunately. Here's the full output:
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp: In function 'void checkBlock(xBlockLink*)':
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp:144:27: error: cannot convert 'xBlockLink* {aka A_BLOCK_LINK*}' to 'const uint8_t* {aka const unsigned char*}' for argument '1' to 'void printhex(const uint8_t*, size_t)'
       printhex(pxBlock, 16);
               ^
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp:152:27: error: cannot convert 'xBlockLink* {aka A_BLOCK_LINK*}' to 'const uint8_t* {aka const unsigned char*}' for argument '1' to 'void printhex(const uint8_t*, size_t)'
       printhex(pxBlock, 16);
               ^
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp: In function 'void* pvPortMalloc(size_t, const char*, int)':
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp:223:28: error: invalid conversion from 'void*' to 'xBlockLink* {aka A_BLOCK_LINK*}' [-fpermissive]
         pxNewBlockLink = ( void * ) ( ( ( unsigned char * ) pxBlock ) + xWantedSize );
                ^
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp: In function 'void vPortFree(void*, const char*, int)':
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp:284:12: error: invalid conversion from 'void*' to 'xBlockLink* {aka A_BLOCK_LINK*}' [-fpermissive]
     pxLink = ( void * ) puc;
        ^
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp: In function 'void* pvPortRealloc(void*, size_t, const char*, int)':
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp:357:26: error: invalid conversion from 'void*' to 'unsigned char*' [-fpermissive]
     unsigned char* puc = mem;
              ^
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp: In function 'void prvHeapInit()':
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp:398:10: error: invalid conversion from 'char*' to 'unsigned char*' [-fpermissive]
   ucHeap = &_heap_start;
      ^
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp:405:26: error: invalid conversion from 'void*' to 'A_BLOCK_LINK*' [-fpermissive]
   xStart.pxNextFreeBlock = ( void * ) pucAlignedHeap;
              ^
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp:412:9: error: invalid conversion from 'void*' to 'xBlockLink* {aka A_BLOCK_LINK*}' [-fpermissive]
   pxEnd = ( void * ) pucHeapEnd;
     ^
C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266\heap4c.cpp:419:20: error: invalid conversion from 'void*' to 'xBlockLink* {aka A_BLOCK_LINK*}' [-fpermissive]
   pxFirstFreeBlock = ( void * ) pucAlignedHeap;
            ^
exit status 1
Error compiling.
Me No Dev
@me-no-dev
Jan 26 2016 09:36
cast it then, but all those gave warning on my side and compiled fine
PyB
@PyBerger
Jan 26 2016 09:39
@me-no-dev - have you ever had problems with the phy_adc_read_faast - always returns 215 to me and even when I change the clock_div, always take about 20~30us...
Me No Dev
@me-no-dev
Jan 26 2016 09:46
the code I posted above is working as expected on my side :) tried it for a while last night
never tested thise code before
maybe try copy/paste and see if it will work
Ivan Grokhotkov
@igrr
Jan 26 2016 09:48
holy cow
@me-no-dev remember i had to re-build lwip to fix some weird issues we were having?
and then it didn't work for you?
well i finally found out why stock lwip didn't work for me
Here's an excerpt of tcp_input function, compiled with xt-xcc by Espressif:
4022f600 loc_4022f600:                                                                                                │
│4022f600     $a7 = *(u32*)($a12 + 0x8c) ; l32i     $a7, $a12, 0x8c                                                    │
│4022f603     if (!$a7) goto loc_4022f613 ; beqz.n   $a7, loc_4022f613                                                 │
│4022f605     $a2 = *(u32*)($a12 + 0x18) ; l32i.n   $a2, $a12, 0x18                                                    │
│4022f607     $a3 = $a12 ; mov.n    $a3, $a12                                                                          │
│4022f609     $a4 = 0x0 ; movi.n   $a4, 0x0                                                                            │
│4022f60b     $a5 = 0x0 ; movi.n   $a5, 0x0                                                                            │
│4022f60d     call $a7 ; callx0   $a7                                                                                  │
│4022f610     goto loc_4022f615 ; j        loc_4022f615                                                                │
│4022f613              ; xref: 0x4022f603 j                                                                            │
│4022f613 loc_4022f613:                                                                                                │
│4022f613     $a2 = 0x0 ; movi.n   $a2, 0x0                                                                            │
│4022f615              ; xref: 0x4022f610 j                                                                            │
│4022f615 loc_4022f615:                                                                                                │
│4022f615     $a4 = $a2 + 0x8 ; addi.n   $a4, $a2, 0x8                                                                 │
│4022f617     if (!$a4) goto loc_4022f4fa ; beqz     $a4, loc_4022f4fa                                                 │
│4022f61a              ; xref: 0x4022f5e9 j                                                                            │
Me No Dev
@me-no-dev
Jan 26 2016 09:54
what is a12 here?
Ivan Grokhotkov
@igrr
Jan 26 2016 09:55
and corresponding C code:
if(pcb->recv != NULL) {
    err = pcb->recv(pcb->callback_arg, pcb ,NULL, ERR_OK);
} else {
    (ret) = ERR_OK;
}
if (err == ERR_ABRT) {
    goto aborted;
}

/// more code
tcp_output(pcb);


/// more code
aborted:
so basically, call receive callback, if return code is ERR_ABRT, go to aborted label
a12 is pcb
Me No Dev
@me-no-dev
Jan 26 2016 09:55
yes :) see that now
alright that does not seem so bad? what am I missing?
Ivan Grokhotkov
@igrr
Jan 26 2016 09:56
well see how it does if (err == ERR_ABRT) check there :)
ERR_ABRT is defined as -8
and remember that err_t is defined as int8_t :)
Me No Dev
@me-no-dev
Jan 26 2016 09:57
yes
Ivan Grokhotkov
@igrr
Jan 26 2016 09:57
at 0x4022f615, it adds 8 to the value returned by callback and then compares to 0
well callback places 0xf8 into a2, because that's -8 in int8_t
Me No Dev
@me-no-dev
Jan 26 2016 09:58
:D
and isn't a4 = 0
so +8 ..
nevm
Ivan Grokhotkov
@igrr
Jan 26 2016 09:59
nope, it's 256 :)
which isn't equal to 0, obviously
that's what happens when you have two different compilers working on your code
Me No Dev
@me-no-dev
Jan 26 2016 10:00
awesome :D
any way around?
can we make sure it's all compiled with the same one?
Ivan Grokhotkov
@igrr
Jan 26 2016 10:02
well Espressif builds their libraries with xt-xcc. it does produce smaller code than gcc, with the same optimization settings
yeah, i'll probably add an explicit cast to int for the return value.
Mario Mikočević
@mozgy
Jan 26 2016 10:03
heheh, @me-no-dev, that reminds me of my problems awhile ago :D
Ivan Grokhotkov
@igrr
Jan 26 2016 10:04
should work, but the total number of hours i have spent trying to troubleshoot this issue would probably add up to a week by now.
Me No Dev
@me-no-dev
Jan 26 2016 10:05
yeah :( that's how it is
i'm in an exception loop since last week also :D
kinda gotten used to it
Ivan Grokhotkov
@igrr
Jan 26 2016 10:06
i still don't know why gcc-built lwip breaks your code though.
Me No Dev
@me-no-dev
Jan 26 2016 10:06
maybe something is missing
Ivan Grokhotkov
@igrr
Jan 26 2016 10:06
but i'd imagine it has something to do with calling tcp_abort
Me No Dev
@me-no-dev
Jan 26 2016 10:06
something does nto deal with memory properly
I notice aborts ;) do not get the often
I had 2 issues
with your lwip things just did not work... random crashes
with stock lwip above 1.4 SDK if you waste time to write file on a dirty FS it just loses packets
they never get to pcb_recv
this is the current condition too
not sure if they are connected but test sketch is identical
you compied it against the 1.3 lwip for 1.3 right?
they have different pvPort signatures
Ivan Grokhotkov
@igrr
Jan 26 2016 10:09
yep
Me No Dev
@me-no-dev
Jan 26 2016 10:10
it was failing at bizare places (pvPort*)
and aligning them did not help
Ivan Grokhotkov
@igrr
Jan 26 2016 10:11
well, the tools that helped me were:
  • custom heap routines, which checked buffer bounds and 0xcc-filling of free'ed memory — this helped convert random crashes to instantaneous ones, indicating 'use after free' error somewhere
  • ScratchABit dissasembler, which i used to make sense of the generated code
  • GDBStub, which I used to step through the code and find the offending place
This 'failing at bizzare places' looks very much what i had before i added my own heap functions
Me No Dev
@me-no-dev
Jan 26 2016 10:11
GDBStub I'm not familiar with
maybe it's time to get ;)
Ivan Grokhotkov
@igrr
Jan 26 2016 10:12
After i did that, it became immediately obvious that it's not random, but rather some code in LwIP was accessing memory which was just free'ed
and depending on other code running, this memory got corrupted or not
GDBStub allowed me to get a stack trace at the point of crash, indicating a pair of tcp_input -> tcp_output calls
Me No Dev
@me-no-dev
Jan 26 2016 10:13
I notice in 1.5.1 they have debug telling you that the address XXXX has been already freed
i imagine they are trying to fix it too
Ivan Grokhotkov
@igrr
Jan 26 2016 10:14
nice... although i will probably throw their heap functions out once i clean up my own version
Me No Dev
@me-no-dev
Jan 26 2016 10:14
it's always better to have the code ;) I hope they do not mind
i'm already using your version (pasted ast night) so far behaves the same
@igrr where should I look fot GDB help?
Me No Dev
@me-no-dev
Jan 26 2016 10:18
i feel stupid :D did not notice the lib at all
Ivan Grokhotkov
@igrr
Jan 26 2016 10:19
by default it will only enter GDB stub on exception. you can trigger breakpoint manually (when you figure out which part of code is responsible) by calling gdbstub_do_break()
that's extern "C" void gdbstub_do_break(); if you're in a CPP file
Me No Dev
@me-no-dev
Jan 26 2016 10:20
awesome!
I have just the case to test it with as well
Ivan Grokhotkov
@igrr
Jan 26 2016 10:21
remember that there is only one hardware breakpoint, and software ones only work on RAM code
so i ended up using hbreak <address>, delete <breakpoint id> often
single-stepping (si works as expected)
Me No Dev
@me-no-dev
Jan 26 2016 10:23
so gdbstub_do_break() should go to in ram functions only?
Ivan Grokhotkov
@igrr
Jan 26 2016 10:23
step-over (ni) only works when gdb is smart enough to find prologue/epilogue and stack frame, which doesn't happen always...
nope, i called it from cached function
gdbstub_do_break triggers a hardware breakpoint which works everywhere
but then you have to use hbr command instead of br to set a new one
i think this is mentioned in gdbstub doc (the second link)
oh, yeah, and be sure to modify your platform.txt
replace all -Os with -O0 -ggdb
in three places: C compiler args, C++ compiler args, linker args
Me No Dev
@me-no-dev
Jan 26 2016 10:25
ok :) giving it a go
will bother you if I get to something I can not google
Ivan Grokhotkov
@igrr
Jan 26 2016 10:26
sure
Me No Dev
@me-no-dev
Jan 26 2016 10:26
tcp_serial_redirect.py ?
Ivan Grokhotkov
@igrr
Jan 26 2016 10:27
i think it comes with pyserial
Me No Dev
@me-no-dev
Jan 26 2016 10:28
where is it on your mac?
not finding it hete
Me No Dev
@me-no-dev
Jan 26 2016 10:37
yeah :) was nowhere in the package
maybe link it inthe docs
PyB
@PyBerger
Jan 26 2016 10:41
@me-no-dev I did a copy paste already - which version of the SDK are you using ?
Me No Dev
@me-no-dev
Jan 26 2016 10:42
git (1.5.1)
PyB
@PyBerger
Jan 26 2016 10:44
ok so do it...
will do a test sketch to see
Me No Dev
@me-no-dev
Jan 26 2016 10:47
@igrr ... compiling S does not seem to bring all include folders
recepie looks fine but the command it executed had no include
so build fails
#include <xtensa/config/specreg.h>
nvm, eclipse problem
PyB
@PyBerger
Jan 26 2016 10:55
@me-no-dev , this is my test sketch - anything wrong you would catch :

void setup() {
  // put your setup code here, to run once:
  delay (1000);

  // Setup the IOs
  // -------------
   // ADC pin as input  
  pinMode(17, INPUT);     // ADC pin to read voltage/noise/signal

  // Blink led for a while to make sure the ethernet shield is initialized
  // ---------------------------------------------------------------------
  for (unsigned char i = 0; i < 5 ; i++)
  {
      digitalWrite(16, HIGH);
      delay(100);
      digitalWrite(16, LOW);
      delay(100);
  }

    Serial.begin(921600);
  while(!Serial);


  Serial.println("Started");


}

void loop() {
  // put your main code here, to run repeatedly:

 uint32_t micros_in = micros();

  // Convert value to mV
  int batt = analogRead(17);

  uint32_t micros_out = micros();

  Serial.print(batt); Serial.print(" - ");Serial.println(micros_out - micros_in);


delay (1000);

}
Output is
214 - 14
231 - 14
214 - 14
215 - 14
215 - 14
224 - 14
215 - 18
224 - 14
215 - 14
Me No Dev
@me-no-dev
Jan 26 2016 10:58
looks fine :) values between 214 and 224
PyB
@PyBerger
Jan 26 2016 10:59
should be around 0 (tied to gnd)
and if I put 1V, still remains @ 214/224...
the range should be 0..1023 - isn't it ?
Me No Dev
@me-no-dev
Jan 26 2016 11:00
@igrr with -O0 -ggdb in ide complains in the linker about WITHINISR missing
@PyBerger it's what I see with the code I pasted above and your exact method of test
range running fine from 0 to 1023
PyB
@PyBerger
Jan 26 2016 11:09
@me-no-dev , hhuuuummm what could go wrong...
When you change the adc_clk_div, do you see the ADC duration last more time
For example if you change from 8 to 16..... we should go from ~14us to ~28us right ?
on my setup always remains around 14us
which shouldn't be...
Me No Dev
@me-no-dev
Jan 26 2016 11:13
most time is taken before and after the actuall measurement.
each measurement takes a bit over 1us (se the loop in the code)
so when you say you want 10 measurements, it will prep the ADC once, then run 10 times and leave the ADC the way it found it
PyB
@PyBerger
Jan 26 2016 11:15
yep
but in your code, we only ask for 1 measurement (and have a clk_div of 8)
Me No Dev
@me-no-dev
Jan 26 2016 11:15
I'm thinking of exploiting this for a simple scope :)
PyB
@PyBerger
Jan 26 2016 11:16
simple but drives me nuts :(
Me No Dev
@me-no-dev
Jan 26 2016 11:16
@PyBerger regardless of what you ask, trhe time that the clock matters is so small that you do not notice
you spend most time waiting
before and after measurements that is
PyB
@PyBerger
Jan 26 2016 11:20
ok, why not -
but why is it that I always get ~214 as a result...
Me No Dev
@me-no-dev
Jan 26 2016 11:21
that I can not say :)
what ESP are you using
IMG_1640.JPG
Ivan Grokhotkov
@igrr
Jan 26 2016 11:25
@me-no-dev yeah, i think i comment that ETS_WITHINISR call manually for debug builds :)
PyB
@PyBerger
Jan 26 2016 11:26
ESP12E mounted on nodemcu 1.0
Me No Dev
@me-no-dev
Jan 26 2016 11:27
@igrr alright :) that explains it
PyB
@PyBerger
Jan 26 2016 11:31
@me-no-dev
is there any mean to further debug this ? I don't think, we have docs for those registers - correct ?
Me No Dev
@me-no-dev
Jan 26 2016 11:33
@PyBerger registers work. I can not explain why they would act differently for us
could maybe the ADC port on your ESP be damaged?
PyB
@PyBerger
Jan 26 2016 11:37
I don't believe so, let me do a test - same as before, but 2 reading 1 with the fast and one with the 'slow' : system_adc_read function
Slow : 215 - 19
Fast : 1024 - 97
Slow : 231 - 19
Fast : 1024 - 96
Slow : 215 - 18
Fast : 1024 - 97
Slow : 215 - 19
Fast : 1024 - 96
Slow : 216 - 19
Fast : 1024 - 96
Slow : 214 - 19
Fast : 1024 - 97
Slow : 215 - 19
Fast : 1024 - 96
Slow : 215 - 24
Fast : 1024 - 100
Slow : 217 - 19
Fast : 1024 - 96
Slow : 215 - 19
Fast : 1 - 97
Slow : 215 - 18
Fast : 0 - 97
Slow : 215 - 19
Fast : 1 - 96
Slow : 215 - 19
Fast : 0 - 96
Slow : 215 - 19
with this :
```

uint32_t micros_in = micros();
uint16_t batt = analogRead(17);
uint32_t micros_out = micros();

Serial.print("Slow : ");Serial.print(batt); Serial.print(" - ");Serial.println(micros_out - micros_in);

micros_in = micros();
batt = system_adc_read();
micros_out = micros();

Serial.print("Fast : ");Serial.print(batt); Serial.print(" - ");Serial.println(micros_out - micros_in);

PyB
@PyBerger
Jan 26 2016 11:55
@me-no-dev should I send you my core_wiring_analog.c file for test at your end ?
may be I miss something completely obvious
Me No Dev
@me-no-dev
Jan 26 2016 11:56
i'll give you mine :) that will be easier
PyB
@PyBerger
Jan 26 2016 11:56
as you wish
PyB
@PyBerger
Jan 26 2016 12:02
anything that can turn to help me getting this stuff more rational is welcome ...
there are diffs...
you renamed save_20... to saveConf....
that's it otherwise same :(
Me No Dev
@me-no-dev
Jan 26 2016 12:04
hold on I think I got into your situation
tzapu
@tzapu
Jan 26 2016 12:05
2016-01-26 13.06.46.jpg
@skorokithakis first step done
2016-01-26 13.06.56.jpg
now waiting on delivery of smd s...
PyB
@PyBerger
Jan 26 2016 12:15
@me-no-dev I'm waiting to understand...
Me No Dev
@me-no-dev
Jan 26 2016 12:16
@PyBerger it was working beauty last night :D
not today
PyB
@PyBerger
Jan 26 2016 12:17
haaa at least I'm not alone now !!!!
possibly one register that isn't set right at start
PyB
@PyBerger
Jan 26 2016 12:25
tell me if you want me to do some tests :)
runing out of ideas here
Me No Dev
@me-no-dev
Jan 26 2016 12:34
@PyBerger some success
ACD needs to be in TOUT mode
PyB
@PyBerger
Jan 26 2016 12:38
ok and how u do that ?
Mario Mikočević
@mozgy
Jan 26 2016 12:42
default is ADC_MODE(ADC_TOUT); I think
for reading internal vcc you do ADC_MODE(ADC_VCC);
PyB
@PyBerger
Jan 26 2016 12:44
ah so my 215 would be internal vcc
Me No Dev
@me-no-dev
Jan 26 2016 12:46
ADC_MODE(ADC_TOUT); gives me error in ArduinoIDE
fine on eclipse
PyB
@PyBerger
Jan 26 2016 12:48
added that in arduinoide 1st file of sketch, compiles ok but no change...
and for you ?
adding ADC_TOUT --> no change
adding ADC_VCC --> no change for fast read (still 219 or so), system_adc_read plots FFFF...
n u ?
Me No Dev
@me-no-dev
Jan 26 2016 13:01
ok this is bizare
ADC_MODE(ADC_TOUT); in IDE gives the following:
/var/folders/b_/2gy4g72944359d2vj4htbtwm0000gn/T/arduino_modified_sketch_317359/sketch_jan26a.ino: In function 'int __get_adc_mode()':
sketch_jan26a:13: error: previous declaration of 'int __get_adc_mode()' with 'C++' linkage
 ADC_MODE(ADC_TOUT);
     ^
In file included from /Users/ficeto/Desktop/ESP8266/Arduino-Main/build/macosx/work/Arduino.app/Contents/Java/hardware/esp8266com/esp8266/cores/esp8266/Arduino.h:247:0,
                 from /var/folders/b_/2gy4g72944359d2vj4htbtwm0000gn/T/arduino_modified_sketch_317359/sketch_jan26a.ino:1:
/Users/ficeto/Desktop/ESP8266/Arduino-Main/build/macosx/work/Arduino.app/Contents/Java/hardware/esp8266com/esp8266/cores/esp8266/Esp.h:74:58: error: conflicts with new declaration with 'C' linkage
 #define ADC_MODE(mode) extern "C" int __get_adc_mode(void) { return (int) (mode); }
                                                          ^
/var/folders/b_/2gy4g72944359d2vj4htbtwm0000gn/T/arduino_modified_sketch_317359/sketch_jan26a.ino:13:1: note: in expansion of macro 'ADC_MODE'
 ADC_MODE(ADC_TOUT);
 ^
and the fast ADC does not work
same exact sketch (copy/paste) to eclipse
and it compiles and fast adc works
not sure who to blame
Mario Mikočević
@mozgy
Jan 26 2016 13:02
my 1.6.7 IDE compiles fine ADC_MODE(ADC_TOUT);
Ivan Grokhotkov
@igrr
Jan 26 2016 13:03
I know... it's arduino-builder
Mario Mikočević
@mozgy
Jan 26 2016 13:03
btw, you might stumble on latest IDE feature
Ivan Grokhotkov
@igrr
Jan 26 2016 13:04
it generates forward declarations for each function encountered in the sketch
Mario Mikočević
@mozgy
Jan 26 2016 13:04
it does search ALL files in current folder
and what @igrr wrote
Ivan Grokhotkov
@igrr
Jan 26 2016 13:04
apparently it doesn't handle extern "C" properly
i.e. it generates forward declaration without extern "C"
will fix that
Me No Dev
@me-no-dev
Jan 26 2016 13:07
I tried not using that and having it inside extern "C" {} together with other C sttuff
while it compiled fine, it did not give any effect
btw I run 1.6.8 IDE (git)
Ivan Grokhotkov
@igrr
Jan 26 2016 13:09
ADC_TOUT is the default, so it shouldn't give any effect
Me No Dev
@me-no-dev
Jan 26 2016 13:09
well :D it did not give TOUT :D
it gave VCC
at least that what I get from the results
Ivan Grokhotkov
@igrr
Jan 26 2016 13:09
with normal system_adc_read?
Me No Dev
@me-no-dev
Jan 26 2016 13:10
not working good also
jumps values... no liearity
PyB
@PyBerger
Jan 26 2016 13:11
For me system_adc_read works fine (slow below) while I have this ù^ù! result of 219 with phy_adc_read_fast (fast below)
Fast : 219 - 24
Slow : 0 - 101
Fast : 219 - 24
Slow : 1 - 101
Fast : 219 - 24
Slow : 0 - 101
Fast : 219 - 23
Slow : 0 - 101
Fast : 219 - 24
Slow : 0 - 101
1st digit is value, 2nd is duration in us
tzapu
@tzapu
Jan 26 2016 13:39
@Links2004 i ve noticed, and got some reports from users that if you do the following, sometimes the wifi won t connect
  • connect once with WiFi.begin(ssid,pwd); connects fine
  • rewrite firmware, leave code with same ssid, pwd (hardcoded) it doesn t connect anymore
  • reboot also doesn t make it connect, nor power cycle
  • use WiFi.begin(); connects just fine
this only happens on some routers it seems... or quite hard to replicate
tzapu
@tzapu
Jan 26 2016 13:45
also, quite weird is that when this happens, i have got no debug info at all, even though debug is set to all
i might not have been able to replicate it in the end, for me at least it seems that this is happening when I am not setting the proper size of the flash --- it was 512kb while it was actually 4MB
but still very weird way of behaving itself
PyB
@PyBerger
Jan 26 2016 13:50
@me-no-dev @igrr
any further idea on the Fast ADC issue ?
tzapu
@tzapu
Jan 26 2016 14:27
there were at least of couple of guys here having and playing with an arducam, mine just arrived as well, any interesting projects/sources ? :D
Mario Mikočević
@mozgy
Jan 26 2016 14:30
oshpark sent me an email last night that they shipped my PCB :)
I'm not publishing anything yet .. want to test it first
Me No Dev
@me-no-dev
Jan 26 2016 14:33
@tzapu mine is not what it was supposed to be to test
else would have tested async with it
tzapu
@tzapu
Jan 26 2016 14:48
ah ha
nice
no breadboard test setup ? :P
if oshpark needs to send other boards it s gonna be loooong :P
Mario Mikočević
@mozgy
Jan 26 2016 14:54
it is on breadboard atm :D :p
tzapu
@tzapu
Jan 26 2016 15:17
:D
mine as well :)
altough it gives me an error Can't find OV2640 module!
it still works
fine
i wonder, what would i need to power it only when i toggle a digital pin on the esp...
FWeinb
@FWeinb
Jan 26 2016 15:28
I just got this display in the mail connected via SPI and used @Links2004 ILI9341 lib but the module isn't responding.
andig
@andig
Jan 26 2016 15:31
would you guys allow me to ask a stupid newbie cpp inheritance question here?

ok, I'll try. If not ok please tell me off. This has been driving me crazy for an hour and is probably obvious:

void Plugin::getSensorJson(JsonObject* json, int8_t sensor) {
  Serial.println("Plugin::getSensorJson");
  char buf[UUID_LENGTH];
  if (getAddr(&buf[0], sensor)) {
    (*json)["addr"] = String(buf);
    Serial.println(buf); // prints garbage
  }
}

bool WifiPlugin::getAddr(char* addr_c, int8_t sensor) {
  Serial.println("WifiPlugin::getAddr");
  if (sensor >= devs)
    return false;
  addr_c = "wlan";
  Serial.println(addr_c); // prints wlan
  return true;
}

WifiPlugin inherits from Plugin. When WifiPlugin::getSensorJson is called, I get rubbish in addr. Debug shows that all functions are called in expected order (they're all virtual):

WifiPlugin::getSensorJson
Plugin::getSensorJson
WifiPlugin::getAddr

Why is the value of buf garbage in Plugin::getSensorJson?

sticilface
@sticilface
Jan 26 2016 15:37
so i use references to pass the json around...
void addjson(JsonObject& root) { }
andig
@andig
Jan 26 2016 15:39
The problem is not the json but the buf. If fails in Plugin::getSensorJson even when printing the buffer?
PyB
@PyBerger
Jan 26 2016 15:41
@me-no-dev @igrr eventually got the adc read OK - but had to take another version of Victor
Martin Ayotte
@martinayotte
Jan 26 2016 15:42
the problem is within your getAddr() : you would need to change "addr_c = "wlan";" by "memcpy(addr_c, "wlan");"
Me No Dev
@me-no-dev
Jan 26 2016 15:45
@PyBerger wat is different/
andig
@andig
Jan 26 2016 15:46
@martinayotte I've tried both strcpy(addr_c, "wlan"); and memcpy(addr_c, "wlan", 5); neither working. Even if- shouldn't the compiler otherwise warn? What wrong with my pointers???
PyB
@PyBerger
Jan 26 2016 15:46
some register tweaking on the same register as before.
I used :
haven't checked all the details - yet
Martin Ayotte
@martinayotte
Jan 26 2016 15:47
@andig , in the above code, you simply overwrite local addr_c pointer with new address, but it doesn't fill the caller's buffer. strcpy() adn memcpy() should work.
PyB
@PyBerger
Jan 26 2016 15:48
now for some reason I got between 0 & 2048 - but that works
Martin Ayotte
@martinayotte
Jan 26 2016 15:48
(unless there is another issue in the code)
Me No Dev
@me-no-dev
Jan 26 2016 15:49
getAddr(buf, sensor);
strcpy(addr_c, "wlan");
try that
andig
@andig
Jan 26 2016 15:53

here we go. buf vs &buf[0] doesnt make a difference. However, when I said strcpy doesn't work I've still had this code:

addr_c = "wlan";
strcpy(addr_c, "wlan");

I guess add_c pointer was changed first, than wlan copied in. Bad idea. What I don't get is why the compiler doesn't notice.

Chris Elsworth
@celsworth
Jan 26 2016 15:54
what is there for it to notice? :)
its doing exactly what you told it ;)
FWeinb
@FWeinb
Jan 26 2016 15:54
Checked connections for the 100 time now...
Martin Ayotte
@martinayotte
Jan 26 2016 15:56
@andig compiler doesn't catch such errors, because it can be what the programmer wished : ptr1 = ptr2; strcpy(ptr1, "wlan");
Chris Elsworth
@celsworth
Jan 26 2016 15:56
and "wlan" can be compiled to a perfectly valid char pointer
andig
@andig
Jan 26 2016 15:56
must admit that c pointers are killing me. could do this every day in assembler, but not in c :(
Chris Elsworth
@celsworth
Jan 26 2016 15:56
who knows where it points, but it does :)
andig
@andig
Jan 26 2016 15:57
@celsworth arggh. I see- pointer assignment?! my bad....
wondering if that "wlan" pointer is being caught by garbage collection? if not that might be my memory loss...
Chris Elsworth
@celsworth
Jan 26 2016 15:58
there is no garbage collection of a static string
but it only ever uses 5 bytes (including the terminating null)
it won't use another 5 bytes next time you run that code, it'll be the same 5 bytes
however where you strcpy it to, is another matter, something has to take care of the memory where you copied it to
andig
@andig
Jan 26 2016 15:59
thanks. pls forgive me for wasting your time with stupid newbies questions...
Martin Ayotte
@martinayotte
Jan 26 2016 15:59
there is simply no garbage collection in C/C++
FWeinb
@FWeinb
Jan 26 2016 16:30
It's glowing white now...
Markus
@Links2004
Jan 26 2016 16:35
@tzapu try to set Serial.setDebugOutput(true); in the setup, the debug menu can only enable it after setup, may it show more.
@FWeinb do you have connected the back-light (its not controlled by SPI)
Markus
@Links2004
Jan 26 2016 16:42
@tzapu may WiFi.setAutoConnect(true); help
Michael Miller
@Makuna
Jan 26 2016 17:08
@andig pointers always seem to be common bug creator. Some teams will require all pointer variables to marked to make sure its obvious they are pointers, (i.e. pVariable, ptrVariable), and pointers to strings is the next level of problems, (i.e pstrVariable, ptrstringVariable). While these notations may seem overkill, with them it makes doing code reviews (even my own code) much quicker.
Michael Miller
@Makuna
Jan 26 2016 17:14
I have a general question for "consumers" not developers of libraries, sorry if this feels like spam. What do you think of the new library manager for the Arduino IDE? Weird and difficult or intuitive and easy?
Its seems platformio has something similar.
Mario Mikočević
@mozgy
Jan 26 2016 17:52
@Makuna it hasn't gotten in the way for me yet so it's good so far .. :)
Me No Dev
@me-no-dev
Jan 26 2016 18:00
@Makuna it's horrible as interface. But then the whole IDE is... :D
Category tree would e nice. Same goes for different view types (list, details..)
Aditya Tannu
@AdySan
Jan 26 2016 18:18
@FWeinb good luck with that, I had to get a refund, waiting for new one to arrive. Same issue, just white, no response.
@FWeinb try something from here, its a good compilation of all different types and some debugging techniques http://misc.ws/2015/01/24/lcd-touch-screen-information/
Mario Mikočević
@mozgy
Jan 26 2016 18:20
@AdySan @FWeinb are you sure it's not just backlight resistor ?
FWeinb
@FWeinb
Jan 26 2016 18:25
@mozgy @AdySan I have connected VCC to LED and to VCC.
Mario Mikočević
@mozgy
Jan 26 2016 18:25
that'll do full white :) on most LCDs
FWeinb
@FWeinb
Jan 26 2016 18:26
But without VCC to LED there is nothing...
Mario Mikočević
@mozgy
Jan 26 2016 18:26
exactly
FWeinb
@FWeinb
Jan 26 2016 18:26
I am running the graphicstest sketch and I am getting this.
Mario Mikočević
@mozgy
Jan 26 2016 18:27
there should be some kind of resistor there I think
FWeinb
@FWeinb
Jan 26 2016 18:27
Display Power Mode: 0x0
MADCTL Mode: 0x0
Pixel Format: 0x0
Image Format: 0x0
Self Diagnostic: 0x0
Yeah LED is connected to a resistor.
I even soldered the J1 pad to get it working with 3.3V
Mario Mikočević
@mozgy
Jan 26 2016 18:28
variable one ? so you can test brightness
FWeinb
@FWeinb
Jan 26 2016 18:28
I can't even get a response from the ILI9341
@Links2004 there is a LED PIN that I have connected to VCC with that it is just glowing white.
Markus
@Links2004
Jan 26 2016 18:36
@FWeinb the reset pin has a pullup?
FWeinb
@FWeinb
Jan 26 2016 18:38
@Links2004 Awesome! That's it!
@AdySan Did you try adding a pullup to reset?
Aditya Tannu
@AdySan
Jan 26 2016 18:40
@FWeinb nope, will try!
FWeinb
@FWeinb
Jan 26 2016 18:46
@AdySan did you close J1 on your board?
I can't find anything about the touchscreen controller that is used on that board... The label says H2046...
Markus
@Links2004
Jan 26 2016 18:52
FWeinb
@FWeinb
Jan 26 2016 18:53
Thanks! Again!
Markus
@Links2004
Jan 26 2016 18:53
have too displays here but have not used the touch yet.
brutzler
@brutzler
Jan 26 2016 19:38
@FWeinb: be aware, there are two different boards around. One drives the backlight direct from LED-PIN, and on the other one the LED-Pin goes to a Transistor/MosFET to control the backlight.
FWeinb
@FWeinb
Jan 26 2016 19:42
I don't get the touch screen working... I connected CS and IRQ but it seams that the SPI bus isn't shared between Touchscreen and display.
Do I need to connect the SPI to T_OUT T_Din and T_CLK too?
Chris Elsworth
@celsworth
Jan 26 2016 20:15
sounds like they stand for touchscreen_ so probably :)
probably so you can control the different parts from different buses/mcus if you like
FWeinb
@FWeinb
Jan 26 2016 20:21
Yeah but it is confusing as hell to have some pins that are SPI but have no clear naming...
Markus
@Links2004
Jan 26 2016 20:28
T_OUT T_Din and T_CLK are the SPI pins of the touch
brutzler
@brutzler
Jan 26 2016 20:28
Does anybody know, what state has GPIO2 of an ESP-01 during deepsleep?
I ask, because I want to connect the pin to a DS18B20 and therefore there should be a pullup to VCC.
Using the ESP battery-powered, I do not want to lose power on this resistor.
What would be the maximal pullup for the OneWire? Higher value = less power consumption.
FWeinb
@FWeinb
Jan 26 2016 20:30
@Links2004 T_OUT = MISO T_DIN = MOSI and T_CLK = SCK right?
Markus
@Links2004
Jan 26 2016 20:30

sleep is input no pullup internally
@FWeinb sounds good
FWeinb
@FWeinb
Jan 26 2016 20:33
But it isn't working... it will register on touch but than hang. And never work again till I remove power.
brutzler
@brutzler
Jan 26 2016 20:34
@Links2004 : hmm... that means I lose 0,7mA during sleep with a 4k7.
can internal pullup be used for OneWire?
Markus
@Links2004
Jan 26 2016 20:34
yes for short wire and some sensors
brutzler
@brutzler
Jan 26 2016 20:35
0,5m; DS18B20?
Markus
@Links2004
Jan 26 2016 20:35
if you power them externally sure may use a GPIO to disable power too them
Mario Mikočević
@mozgy
Jan 26 2016 20:38
@brutzler I'm using GPIO2 on my sensors, both DHT and Dallas
Markus
@Links2004
Jan 26 2016 20:38
@FWeinb so you can read from the chip (no wireing problem), may the lib you use has some problem
FWeinb
@FWeinb
Jan 26 2016 20:39
If I invert Miso and MOSI I get a constant return value of 9...
brutzler
@brutzler
Jan 26 2016 20:39
@mozgy: what pullup?
Mario Mikočević
@mozgy
Jan 26 2016 20:39
10k
Markus
@Links2004
Jan 26 2016 20:40
@FWeinb Does not support SPI transactions sounds bad.
brutzler
@brutzler
Jan 26 2016 20:40
@mozgy: would be 0,33mA :-)
How to activate the internal pullup for OneWire?
FWeinb
@FWeinb
Jan 26 2016 20:41
I feared that this might be a problem.
Markus
@Links2004
Jan 26 2016 20:41
modify the OneWire lib
Aditya Tannu
@AdySan
Jan 26 2016 20:43
you'd need to share the SPI bus between display and touch?
FWeinb
@FWeinb
Jan 26 2016 20:44
Yeah. Not enough pins on the esp8266
Aditya Tannu
@AdySan
Jan 26 2016 20:45
so how was that demo working in that video with the library you just mentioned
FWeinb
@FWeinb
Jan 26 2016 20:46
It is using ucglib and that seams to work without support for transactions..
Martin Ayotte
@martinayotte
Jan 26 2016 20:46
@brutzler , internal pullups (about 100K) are too weak for 0.5m of OneWire
FWeinb
@FWeinb
Jan 26 2016 20:46
it so happens that parameters good for Ucglib on an ILI9431 are also good for this chip; YMMV.
Markus
@Links2004
Jan 26 2016 20:47
@FWeinb yes but without transactions you can not share the SPI port well
FWeinb
@FWeinb
Jan 26 2016 20:48
Yeah just found this: https://github.com/PaulStoffregen/XPT2046_Touchscreen which seams to support transactions
brutzler
@brutzler
Jan 26 2016 20:48
@martinayotte : then i will try with 10k. although spec tells me 4k7
Martin Ayotte
@martinayotte
Jan 26 2016 20:50
@brutzler , as @Links2004 said, you can shutoff the pullup as well as the DS18B20 using a MOSFET during Sleep
FWeinb
@FWeinb
Jan 26 2016 20:51
@Links2004 I am using that lib but that i wan't to have touchscreen support.
brutzler
@brutzler
Jan 26 2016 20:51
@martinayotte ?? You mean I should use a different GPIO with a MOSFET to controll Vcc to the dallas?
Chris Elsworth
@celsworth
Jan 26 2016 20:52
for a dht22 I'd just skip the mosfet to be honest
they're not that hungry
Markus
@Links2004
Jan 26 2016 20:52
@FWeinb yes but it has transactions combinde it with the https://github.com/PaulStoffregen/XPT2046_Touchscreen and the share of the SPI can work
FWeinb
@FWeinb
Jan 26 2016 20:53
Okay. will try
Martin Ayotte
@martinayotte
Jan 26 2016 20:53
@brutzler , yes, if you wish to have good power saving, but no if you don't care much
Chris Elsworth
@celsworth
Jan 26 2016 20:53
max power consumption of a 22 according to the datasheet is 1.5mA
gpio can easily supply that directly
brutzler
@brutzler
Jan 26 2016 20:53
Or can i power the DS18B20 directly?
upps too late
Martin Ayotte
@martinayotte
Jan 26 2016 20:54
yes
in such case, no needs for mosfet
Chris Elsworth
@celsworth
Jan 26 2016 20:54
DS18B20 is also 1.5mA max, just checked.. so yep, same.
Martin Ayotte
@martinayotte
Jan 26 2016 20:54
simply turn GPIO low before sleep
brutzler
@brutzler
Jan 26 2016 20:55
@celsworth yep checked too. 1-1,5mA during measuring
@martinayotte: lucky to have another GPIO (GPIO0) on the ESP-01
Martin Ayotte
@martinayotte
Jan 26 2016 20:56
hoping that Voh won't be too low for the DS
brutzler
@brutzler
Jan 26 2016 20:57
Voh?
Martin Ayotte
@martinayotte
Jan 26 2016 20:57
Oh, but GPIO0 boot, be carefull with boot process
Voh = V output High level
brutzler
@brutzler
Jan 26 2016 20:58
xrzfks.... can TxD or RxD be used?
Martin Ayotte
@martinayotte
Jan 26 2016 20:58
it is probably not 3.0V required, but maybe 2.7V. you need to try it out
DS18B20 require 3.0V, but who knows, it may work
Mario Mikočević
@mozgy
Jan 26 2016 20:59
my sensors with DS18B20 work down to 2.6V
brutzler
@brutzler
Jan 26 2016 20:59
hmm.. powering with 2xAA = 3V (in best case) ... losing some voltage in the ESP.... close thing
as i asked before: Can I use TxD or RxD on a ESP-01 for normal GPIO-use?
Markus
@Links2004
Jan 26 2016 21:01
yes
but they need to be HIGH at boot
GPIO1 + 3
brutzler
@brutzler
Jan 26 2016 21:02
then i cannot turn them to low before deepsleep :-(
Markus
@Links2004
Jan 26 2016 21:03
deepsleep on ESP01 is only possible with HW mods on the Module.
you can use them as OUTPUT, during deepsleep they are INPUTS
brutzler
@brutzler
Jan 26 2016 21:05
@Links2004 already soldered this wire.
That means, it could work. power the DS18B20 from TxD. switch this pin to Output/high at beginning of my software. Calling deepsleep will power off the DS18B20 automatically.
Markus
@Links2004
Jan 26 2016 21:06
the DS18B20 get some startup messages then but yes

this table shows the states during reset / sleep (oe = output enabled, wpu = weak pull up)
brutzler
@brutzler
Jan 26 2016 21:09
Will try this then.
Do I need more parts as shown in my pic?
gitter.jpg
Markus
@Links2004
Jan 26 2016 21:09
pullup for reset and CH_DP?
may CH_CP is not needed with you mod
Mario Mikočević
@mozgy
Jan 26 2016 21:13
brutzler
@brutzler
Jan 26 2016 21:15
better?
gitter.jpg
Martin Ayotte
@martinayotte
Jan 26 2016 21:21
What about pullup on GPIO0 ?
FWeinb
@FWeinb
Jan 26 2016 21:27
Finally. Thanks for the help. Display is working! But the other library isn't that good either...
Markus
@Links2004
Jan 26 2016 21:28
when i add touch support to VNC I will write one, but will not be the next weeks, have too many todo.
FWeinb
@FWeinb
Jan 26 2016 21:29
I will try to write one too. Should be a good exercise.
Would be good if there is some kind of "global" interface for a touchscreen lib. Like your VNC Interface for Touch.
Or the Adafruit GFX lib that is working on many screens.
Markus
@Links2004
Jan 26 2016 21:31
have not seen one yet
may some callback based interface.
FWeinb
@FWeinb
Jan 26 2016 21:33
T_IRQ line would be awesome as a wake signal for the esp. So you would wakeup if the user touches the screen.
Chris Elsworth
@celsworth
Jan 26 2016 21:34
doesn't it have one?
you mentioned IRQ before, what does that do?
FWeinb
@FWeinb
Jan 26 2016 21:35
T_IRQ is LOW on touch. Might not work as a wakup signal for the esp...
Chris Elsworth
@celsworth
Jan 26 2016 21:35
so run it through a transistor ;)
always a way :D
FWeinb
@FWeinb
Jan 26 2016 21:35
Sure that would be possible.
Chris Elsworth
@celsworth
Jan 26 2016 21:35
hm, new atmega chip announced..
Martin Ayotte
@martinayotte
Jan 26 2016 21:47
... and still has only 32KFlash with 2K only of RAM ... STM32F103 are better ! ;-)
brutzler
@brutzler
Jan 26 2016 22:00
@martinayotte: pullup GPIO0? really needed?
will have to search for the minimal wiring. long time ago I found something like this on github. going on searching.
gitter.jpg
hmmm.... where is GPIO15 on a ESP-01?
Martin Ayotte
@martinayotte
Jan 26 2016 22:06
GPIO15 is already grounded on the ESP-01 PCB. For GPIO0, yes, even your picture show it pulled-up, and the requirement comes from boot process https://github.com/esp8266/esp8266-wiki/wiki/Boot-Process. (Don't rely on "weak" internal pullup !)
Mario Mikočević
@mozgy
Jan 26 2016 22:07
anyone here using Async WebServer ?
brutzler
@brutzler
Jan 26 2016 22:09
OK. final solution:
gitter.jpg
But no pullup for RST on the "minimal hardware setup for running only"
Martin Ayotte
@martinayotte
Jan 26 2016 22:35
the above "minimal hardware setup for running only" doesn't pullup GPIO2 too, but they are wrong. For RST, it is mandatory : antenna effect will make ESP resetting by simply touching the pin.
brutzler
@brutzler
Jan 26 2016 22:37
pullup for GPIO2 is nowhere shown...not even in the schematic for improved stability ???
(Now I know, why I prefer to work with a NodeMCU: no care for this...lol)
Martin Ayotte
@martinayotte
Jan 26 2016 22:39
What do you mean ? GPIO2 is in the schematic above, but wrongly left floating. About RST, let me quote a contradiction in ESP Hardware Guide : "no external pull-up resistor is necessary" and few lines later "Note that this pin cannot be dangled" :-)
Only few resistor won't you make suffer :-)
Aditya Tannu
@AdySan
Jan 26 2016 22:59
For using latest git core these instructions work on windows too right?
brutzler
@brutzler
Jan 26 2016 22:59
I mean, that I nowhere have seen, or read, that GPIO2 should be provided with a pullup.
In my breadboard-schematic its only the pullup for the OneWire on GPIO2.
Or do we talk past each other atm?
Aditya Tannu
@AdySan
Jan 26 2016 23:00
This message was deleted
brutzler
@brutzler
Jan 26 2016 23:02
oh I think you talk about the bootmode?
gitter.jpg
Martin Ayotte
@martinayotte
Jan 26 2016 23:04
@brutzler , I've provided this link earlier https://github.com/esp8266/esp8266-wiki/wiki/Boot-Process, GPIO2 need to be HIGH for proper boot, so HIGH = PullUp, not floating. Floating is a bad practice for such sensitive pins like those.
Yes, this is another proof.
brutzler
@brutzler
Jan 26 2016 23:56
OMG. This is definitely not matching to my strategy to power the DS18B20 with RxD as an output. This means that GPIO2 is pulled down during deep-sleep. And Boot process after wakeup will fail :-(