These are chat archives for esp8266/Arduino

3rd
Dec 2015
Chris Elsworth
@celsworth
Dec 03 2015 00:05
@h4rm0n1c : so I did a bit more testing on that getVcc issue and found the offset is a constant multiplier for a given ESP12
on one of my units, the real voltage is always 0.982x the value returned by getVcc() (through a range of 2.96v to 3.46v, I didn't really want to go much higher), and on another one the multiplier is 0.96x on the same range
Me No Dev
@me-no-dev
Dec 03 2015 00:10
I think since the analor reference voltage is 1.024 volts and they use some sort of resistors in there to get it down to the required range, teperature and production difference could be the reason for what you are seing.
Chris Elsworth
@celsworth
Dec 03 2015 00:12
yeah, sounds likely. but at least now I know that I can correct for it, once I've sampled the difference I can be reasonably sure the multiplier is constant for the working voltage range of the chip
it'll just be wrong if I ever have to swap out the esp, just something ot remember I guess
Me No Dev
@me-no-dev
Dec 03 2015 00:13
maybe if you use your own divider externali and measure the voltage using ADC mode, you can keep the divider regardless of the esp
Chris Elsworth
@celsworth
Dec 03 2015 00:13
that doesn't help me get an absolute voltage reading though really?
I'm still at the mercy of what the ADC thinks 1024 is equal to
Me No Dev
@me-no-dev
Dec 03 2015 00:14
ADC is great
Chris Elsworth
@celsworth
Dec 03 2015 00:14
which can vary subtly around 1v
Me No Dev
@me-no-dev
Dec 03 2015 00:14
the 1.024 voltage reference is constant
Chris Elsworth
@celsworth
Dec 03 2015 00:14
not constant enough
Me No Dev
@me-no-dev
Dec 03 2015 00:14
the internal resistor divider is not
the ADC itself and the reference voltage are
Chris Elsworth
@celsworth
Dec 03 2015 00:15
you're saying the 1.024v reference is more stable than getVcc?
Me No Dev
@me-no-dev
Dec 03 2015 00:15
but if one of the resistors is a bit off, you will get offset readings
Chris Elsworth
@celsworth
Dec 03 2015 00:15
I'll try that on my two modules hten, see if I get more consistency
so when you use ADC_MDOE(ADC_VCC) it brings that extra divider into play?
Me No Dev
@me-no-dev
Dec 03 2015 00:16
it removes it
if you use nodemcu though it has one on the board
Chris Elsworth
@celsworth
Dec 03 2015 00:16
nah, just using esp12-f modules on a white breakout
Me No Dev
@me-no-dev
Dec 03 2015 00:17
then make sure your divider drops below 1 volt at max level
in theory should produce the same result across the modules
Chris Elsworth
@celsworth
Dec 03 2015 00:18
yep, will have a try
Me No Dev
@me-no-dev
Dec 03 2015 00:19
actually on the above command, I need to look... did not have it the last time i gave it a go
Angus Gratton
@projectgus
Dec 03 2015 00:19
celsworth: does it make any difference what VCC is set to at reset time (probably up to and including the first ADC read)?
I'm wondering if there might be some internal calibration that happens early on
Chris Elsworth
@celsworth
Dec 03 2015 00:23
doesn't seem, first read is consistent with the rest of them, whether ADC_VCC was on or off on previous boot
Me No Dev
@me-no-dev
Dec 03 2015 00:24
you say it does not matter if it's ADC_TOUT or ADC_VCC?
Chris Elsworth
@celsworth
Dec 03 2015 00:25
from the previous boot, no
Angus Gratton
@projectgus
Dec 03 2015 00:25
I was thinking more, is it the same if you reset at 2.6V then after the first few reads you change VCC to 3.3V. or if you reset at 3.3V then turn down to 2.6V.
Chris Elsworth
@celsworth
Dec 03 2015 00:26
oh I see
is 2.6v the lowest this will run on?
Angus Gratton
@projectgus
Dec 03 2015 00:27
i don't know, i actually misread your 2.96V before :)
it probably won't turn on that low
Chris Elsworth
@celsworth
Dec 03 2015 00:27
I thought it was 3-3.6
Me No Dev
@me-no-dev
Dec 03 2015 00:27
it should not. there is a source of constant voltage that it comapres against. Since that is 1 V I imagine the whole operating range will be fine
i've gone up to 4.2 volts
one chip survived, the other not, but reading were correct
Angus Gratton
@projectgus
Dec 03 2015 00:28
celsworth: yeah, go with 3V :)
Chris Elsworth
@celsworth
Dec 03 2015 00:29
well, to answer your question, no, the supply voltage at reset time doesn't seem to alter the readings
whether I power it up with 3v or 3.5v, I get the same readings
the reference 1.024v isn't exposed anywhere is it, so I can't check that with a meter
Me No Dev
@me-no-dev
Dec 03 2015 00:30
no, the best I have done is externally see what the ADC goes to at max
Chris Elsworth
@celsworth
Dec 03 2015 00:30
I'll just do my own divider as suggested :)
Me No Dev
@me-no-dev
Dec 03 2015 00:31
it could be 1.0V but my measurments gave me 1.024ish
Angus Gratton
@projectgus
Dec 03 2015 00:31
celsworth: ah well, thanks for checking :)
Chris Elsworth
@celsworth
Dec 03 2015 00:33
I may be getting far too OCD over this, its just that EmonLib wants to know the supply voltage for its calculations ;)
I can probably just tell it 3.3v and be perfectly fine.
especially as I'm using a half-decent regulator anyway
Angus Gratton
@projectgus
Dec 03 2015 00:34
wouldn't its calibration be relative to the ADC reference voltage anyhow?
Chris Elsworth
@celsworth
Dec 03 2015 00:34
it would, if I was using internal ADC :) I'm using an ADS7841 over SPI to get more analog inputs
so its relative to Vcc
and since I'm using the ADS7841, the internal ADC is unused so I was trying to use that for supply measurement.. maybe I still can with my own divider
Angus Gratton
@projectgus
Dec 03 2015 00:35
oic
tzapu
@tzapu
Dec 03 2015 05:21
@projectgus are you getting anywhere with emonlib? :)
Angus Gratton
@projectgus
Dec 03 2015 05:22
tzapu: you probably want celsworth not me
I was just being a busybody about emonlib, not doing anything with it :)
tzapu
@tzapu
Dec 03 2015 05:24
yes, sorry, thanks :P
@celsworth are you getting anywhere with emonlib? :)
frippe75
@frippe75
Dec 03 2015 05:52

@iggr went for a more loop oriented aproach to my OTA pull... I understand this is not really what you tried to describe. I guess I need to handle part of the http client library in the loop code so this was my ignorant first attempt :-)

First created a fake backend that progresses through my firmware states to get the client part working. Works but masks the blocking part of the code. Really need to get into the bits and peaces of working embedded...

client part working...

.

void firmware_loop (){
  switch (firmware_state) {
    case (const int) FIRM_BEGIN: // Really not needed state but just in case....
      firmware_state = FIRM_DOWNLOAD;
      prev_firm_state = millis();
      break;
    case FIRM_DOWNLOAD:
      if( millis() - prev_firm_state > 2000 ) {
        downloadFile("192.168.0.210", "/firmware/"  + fw_esp8266_file, "/firmware/esp8266.bin"); // Blocking during most of this download
        firmware_state = FIRM_UPGRADE;
        prev_firm_state = millis();
      }
      break;
    case FIRM_UPGRADE:
      if( millis() - prev_firm_state > 2000 ) { 
         updateESP8266("/firmware/esp8266.bin"); // Blocking during most of this install
         firmware_state = FIRM_REBOOT;
         prev_firm_state = millis();
      }
      break;
    case FIRM_REBOOT:
      if( millis() - prev_firm_state > 2000 ) { // Allow 2sec before rebooting to be able to detect this state from html5 client, which polls every sec...
         ESP.restart(); // Blocking during the reboot :-)
         firmware_state = FIRM_DONE;  // Will not reach here due to restart.... But starts off at this state
         prev_firm_state = millis();
      }
      break;
    case FIRM_DONE:
      break;
    default:
      // default is optional
    break;
  }
}
var code = "formatted";

But still not working properly using esp as backend. I actually dont get any responses at all from the esp ones the firmware pull is started... Any tips on changes? I see http requests going out from the browser ....

Is there no way to make more part of the code non-blocking? without getting a fullblown OS...
Just exactly how bad of an idea would it be to call server.handleClient() via a timer during the firmware process .?.?.?. :-1: )

Ivan Grokhotkov
@igrr
Dec 03 2015 05:55
We stop all other connections once the firmware update starts, because data coming on other connections can overflow ESPs rx buffers while we are handling the update.
To avoid this we have to make the WebServer work asynchronously. @me-no-dev started working on an asynchronous network library, and once this is done we can have a non-blocking variety of WebServer.
At the moment you shouldn't call server.handleClient from a timer/interrupt, because it uses blocking network APIs inside, which are only supported in the context of setup/loop functions.
frippe75
@frippe75
Dec 03 2015 08:19
@igrr I only call EspClass::updateSketch for the update part giving a file stream and that does not call any WIFI stop (from what I can see). So the only incomming Webserver traffic should be my /firmware/progress.
Ivan Grokhotkov
@igrr
Dec 03 2015 08:20
It calls stop internally inside Updater class.
frippe75
@frippe75
Dec 03 2015 08:24
Sure?
The only thing I find related to wifi is
wifi_set_sleep_type
@iggr I have found some OTA examples doing this:
        // Time for update...
         /*
         WiFiUDP::stopAll();
         WiFiClient::stopAll();
         delay(100);
         */
         USE_SERIAL.println("Running ESP.updateSketch");
         if(ESP.updateSketch(file, file.size(), false, false)) {
frippe75
@frippe75
Dec 03 2015 08:30
But that is from the sketch and not from within the Updater.cpp class nor the ESP.cpp
Ivan Grokhotkov
@igrr
Dec 03 2015 08:43
ok, you're right, this is done in ArduinoOTA and ESP8266httpUpdate
so in your case web server socket is not closed
Stavros Korokithakis
@skorokithakis
Dec 03 2015 08:45
hmm, i'm bit-banging some stuff and am seeing way increased latency
i'm delaying 5 usec and am seeing 40 usec come out
should i be disabling interrupts or something?
Ivan Grokhotkov
@igrr
Dec 03 2015 08:47
@skorokithakis you may disable interrupts, but you shouldn't disable them for more than 10 us
Stavros Korokithakis
@skorokithakis
Dec 03 2015 08:47
hm
what's the resolution that delayMicroseconds should have?
i don't understand why i see such big delays
goddamnit
Ivan Grokhotkov
@igrr
Dec 03 2015 08:48
you may want to try calling it with low values (i.e. 0, 1) and see if there is a constant overhead
Stavros Korokithakis
@skorokithakis
Dec 03 2015 08:49
my logic analyzer was set to 25 ksamples/sec :(
never mind, it's doing the right thing :(
Helio Machado
@0x2b3bfa0
Dec 03 2015 12:32
Hi!
Mario Mikočević
@mozgy
Dec 03 2015 13:00
@me-no-dev finally got some time to test OTA with 2.0.0-stable and it does not work for me .. investigating ..
Chris Elsworth
@celsworth
Dec 03 2015 13:01
it hasn't missed a beat for me yet, and I did probably 50 ota updates last night :)
Mario Mikočević
@mozgy
Dec 03 2015 13:01
flashing went fine but on next restart got
Fatal exception (28):
epc1=0x40001800, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00007ff0, depc=0x00000000
@celsworth it's quite possible that I messed something up :)
Chris Elsworth
@celsworth
Dec 03 2015 13:03
I guess the benchmark first is just to try BasicOTA a few times and see if that's reliable
rules out it being something in your code
Mario Mikočević
@mozgy
Dec 03 2015 13:04
yep, on it ..
in the meantime wrote TM1650 library :)
for I2C 4 segment LCD
Me No Dev
@me-no-dev
Dec 03 2015 13:20
@mozgy if flash goes fine and the ESP reboots, that means OTA is working fine. If goes through numerous checks before confirming success and rebooting
only possibility and chance (something we need to fix) is if what got written is different than whet we received
currently check on the written firmware is not performed
maybe the bootleader does that... do not know
Mario Mikočević
@mozgy
Dec 03 2015 13:23
@me-no-dev BasicOTA works .. tried several times
tho multicast storm annoys me :)
Me No Dev
@me-no-dev
Dec 03 2015 13:23
yeah... will see if I can fix that once PR 4107 is merged
Mario Mikočević
@mozgy
Dec 03 2015 13:24
have to close all IDE windows to stop it
Me No Dev
@me-no-dev
Dec 03 2015 13:24
maybe each window opens a new mDNS requester?
Mario Mikočević
@mozgy
Dec 03 2015 13:24
and drains batteries on my already placed sensor PCB .. :(
Me No Dev
@me-no-dev
Dec 03 2015 13:24
will look at it more
Mario Mikočević
@mozgy
Dec 03 2015 13:26
hmm, you're right, might be that second IDE window starts storm
Mario Mikočević
@mozgy
Dec 03 2015 14:02
nope, got storm even with only one IDE open whole time
Me No Dev
@me-no-dev
Dec 03 2015 14:13
does the storm start after some time?
Mario Mikočević
@mozgy
Dec 03 2015 14:16
not sure what starts it yet
ok - Wire.setClock( 400000 ); crashes OTA next reboot here
Me No Dev
@me-no-dev
Dec 03 2015 14:32
It does not make sense... setClock does not do much
void TwoWire::setClock(uint32_t frequency){
  twi_setClock(frequency);
}

void twi_setClock(unsigned int freq){
#if F_CPU == FCPU80
  if(freq <= 100000) twi_dcount = 19;//about 100KHz
  else if(freq <= 200000) twi_dcount = 8;//about 200KHz
  else if(freq <= 300000) twi_dcount = 3;//about 300KHz
  else if(freq <= 400000) twi_dcount = 1;//about 400KHz
  else twi_dcount = 1;//about 400KHz
#else
  if(freq <= 100000) twi_dcount = 32;//about 100KHz
  else if(freq <= 200000) twi_dcount = 14;//about 200KHz
  else if(freq <= 300000) twi_dcount = 8;//about 300KHz
  else if(freq <= 400000) twi_dcount = 5;//about 400KHz
  else if(freq <= 500000) twi_dcount = 3;//about 500KHz
  else if(freq <= 600000) twi_dcount = 2;//about 600KHz
  else twi_dcount = 1;//about 700KHz
#endif
}
Mario Mikočević
@mozgy
Dec 03 2015 14:55
hum? I'm puzzled now, same code, uncommented all lines and it works now .. all I did was add and remove //
I blame neutrinos ..
Chris Elsworth
@celsworth
Dec 03 2015 15:52
I'm struggling to find much information on optimistic_yield() .. is it something I should be using my own code or not?
I see it used throughout the arduino code
Me No Dev
@me-no-dev
Dec 03 2015 15:54
optimistic_yeald() yields if yield has not been called since that many microseconds/cycles (not sure which one)
so you do not yield if not needed
Chris Elsworth
@celsworth
Dec 03 2015 15:54
ok, thanks
Helio Machado
@0x2b3bfa0
Dec 03 2015 17:20
Hi!
I'm facing a really weird (for me) SPIFFS problem.
I can create 30 files called index.html and they can coexists in the same partition. How can I avoid this adding a "File already exists" error?
Me No Dev
@me-no-dev
Dec 03 2015 17:28
how do you create them? there is SPIFFS.exists(path) that you can use to check if the file exists, but generally SPIFFS.open(path, "w") should open the existing file or create a new one
Mario Mikočević
@mozgy
Dec 03 2015 17:57
SPIFFS.open always opened old file for me
onkelfunny
@onkelfunny
Dec 03 2015 20:10
hello. i try to run the neopixel on GPIO16 but this is not working. GPIO14 and AND GPIO2 working.
The problem is, i have a pcb who is using the GPIO16 as LED Stripe out
Angus Gratton
@projectgus
Dec 03 2015 20:13
onkelfunny: GPIO16 is "special", it's connected to the RTC hardware internally not the GPIO hardware
it might be possible to use it to drive neopixels, but at minimum you need special code to work with it rather than the other GPIOs
Me No Dev
@me-no-dev
Dec 03 2015 20:16
@onkelfunny which library are you using? and which branch? there are libs that use the serial, other uses i2s and there are some that bitbang the signal
spi is also possible
Me No Dev
@me-no-dev
Dec 03 2015 20:23
@onkelfunny I looked at the lib @Makuna has posted here https://github.com/Makuna/NeoPixelBus
and if pin 16 is your only option, then it's not hard to modify the library to work on it
I think one if/else will not bring lots of jitter
I have not tested if the pin changes with the same speed as the other 16 GPIOs, but it should be fine
onkelfunny
@onkelfunny
Dec 03 2015 21:03

thx i will check it. i use the adafruit library... latest version.
but at this moment something else is very strange.

void setup() {
  Serial.begin(115200);
}
void loop() {
  Serial.println("HELLO");
  delay(2000);
}

i have no output in the console

Angus Gratton
@projectgus
Dec 03 2015 21:44
onkelfunny: the adafruit library writes directly to the GPIO registers, so it won't work with pin 16 https://github.com/adafruit/Adafruit_NeoPixel/blob/master/esp8266.c#L54
onkelfunny
@onkelfunny
Dec 03 2015 21:55
i try this library: Makuna/NeoPixelBus with gpis 16 and 14 without luck
onkelfunny
@onkelfunny
Dec 03 2015 22:02

GPIO2 works just for the first run.
Flash with GPIO2 -> works
Flash with GPIO16 -> not working
Flash back with GPIO2 -> not working

???

Me No Dev
@me-no-dev
Dec 03 2015 22:04
both need modification to run on pin 16
while(((c = _getCycleCount()) - startTime) < period); // Wait for bit start
if (pin == 16) GP16O |= 1;      // Set gpio 16 high
else GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, pinMask);       // Set high
    startTime = c;                                        // Save start time
while(((c = _getCycleCount()) - startTime) < t);      // Wait high duration
if (pin == 16) GP16O &= ~1;     // Set gpio 16 low
else GPIO_REG_WRITE(GPIO_OUT_W1TC_ADDRESS, pinMask);       // Set low
replacing the code @projectgus pointed at in the Adafruit library with this will make it work on all pins
onkelfunny
@onkelfunny
Dec 03 2015 22:08
thx. i try this
Me No Dev
@me-no-dev
Dec 03 2015 22:09
make sure you set pinMode(16, OUTPUT); before you start
onkelfunny
@onkelfunny
Dec 03 2015 22:09
ok
onkelfunny
@onkelfunny
Dec 03 2015 22:22
no, no luck
the strip is with this code just slightly lighter
Me No Dev
@me-no-dev
Dec 03 2015 22:34
you mean brighter on the lower 16 pins and not working on pin 16?
onkelfunny
@onkelfunny
Dec 03 2015 22:36
the color don't change. but the stripe is brighter
Angus Gratton
@projectgus
Dec 03 2015 22:41
I don't know if you can wiggle gpio16 as fast as the other GPIOs
Me No Dev
@me-no-dev
Dec 03 2015 22:42
no, you can not :( in fact it's alot slower
75ns for regular GPIO
onkelfunny
@onkelfunny
Dec 03 2015 22:43
it is better to use another gpio port?
Me No Dev
@me-no-dev
Dec 03 2015 22:43
800ns for GPIO 16
Angus Gratton
@projectgus
Dec 03 2015 22:44
me-no-dev: do you have a link for that? (not questioning it, just something for future reference)
Me No Dev
@me-no-dev
Dec 03 2015 22:44
sec takin a shot from the scope
Angus Gratton
@projectgus
Dec 03 2015 22:44
ah, you just tested it? don't worry then :)
i just thought there might be some magical page of timing specs that I'd missed
Me No Dev
@me-no-dev
Dec 03 2015 22:46
i ran this in order to see the max speed:
  GPOS = 0x4000;
  GPOC = 0x4000;
  GPOS = 0x4000;
  GPOC = 0x4000;
  GPOS = 0x4000;
  GPOC = 0x4000;
  GPOS = 0x4000;
  GPOC = 0x4000;
  GPOS = 0x4000;
  GPOC = 0x4000;
  GPOS = 0x4000;
  GPOC = 0x4000;
  GPOS = 0x4000;
  GPOC = 0x4000;
  GPOS = 0x4000;
  GPOC = 0x4000;
  GPOS = 0x4000;
  GPOC = 0x4000;
  GPOS = 0x4000;
  GPOC = 0x4000;

  GP16O |= 1;
  GP16O &= ~1;
  GP16O |= 1;
  GP16O &= ~1;
  GP16O |= 1;
  GP16O &= ~1;
  GP16O |= 1;
  GP16O &= ~1;
  GP16O |= 1;
  GP16O &= ~1;
  GP16O |= 1;
  GP16O &= ~1;
  GP16O |= 1;
  GP16O &= ~1;
  GP16O |= 1;
  GP16O &= ~1;
  GP16O |= 1;
  GP16O &= ~1;
  GP16O |= 1;
  GP16O &= ~1;
Angus Gratton
@projectgus
Dec 03 2015 22:46
seems reasonable
is the 800ns edge-to-edge or per full cycle?
Me No Dev
@me-no-dev
Dec 03 2015 22:48
pic_44_2 copy.png
edge to edge
yellow is gpio16
Angus Gratton
@projectgus
Dec 03 2015 22:49
ws2812b spec, the shortest edge period has to be <500ns (for T0H)
so gpio16 probably can
't possibly handle it
onkelfunny: yeah, probably time to "green wire fix" the pcb to another gpio :)
onkelfunny
@onkelfunny
Dec 03 2015 22:52
ok. will do this. thx for helping me
Me No Dev
@me-no-dev
Dec 03 2015 22:57

writing

GP16O = 1;
GP16O = 0;

naturally made it twice faster

tha means the protocol can be bitbanged with it
with no delays
T1L being the only problem
onkelfunny
@onkelfunny
Dec 03 2015 22:59
i try this
works!!
Me No Dev
@me-no-dev
Dec 03 2015 23:02
woot??
onkelfunny
@onkelfunny
Dec 03 2015 23:03
no color problems... everything is fine :D
Me No Dev
@me-no-dev
Dec 03 2015 23:05
on pin 16?
onkelfunny
@onkelfunny
Dec 03 2015 23:05
yes
Me No Dev
@me-no-dev
Dec 03 2015 23:08
i'll give it a go without delays and see if it will work
onkelfunny
@onkelfunny
Dec 03 2015 23:10
while(((c = _getCycleCount()) - startTime) < period); // Wait for bit start
    if (pin == 16) GP16O = 1;      // Set gpio 16 high
    else GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, pinMask);       // Set high
    startTime = c;                                        // Save start time
    while(((c = _getCycleCount()) - startTime) < t);      // Wait high duration
    if (pin == 16) GP16O = 0;     // Set gpio 16 low
    else GPIO_REG_WRITE(GPIO_OUT_W1TC_ADDRESS, pinMask);       // Set low
this helps
GP16O = 1;
GP16O = 0;
by the way... my stripe has 114 leds
THX!!!!
Helio Machado
@0x2b3bfa0
Dec 03 2015 23:13
@me-no-dev: When I use the SPIFFS.exists(file) conditional in the server.onUpload function, the HandleRoot function triggers automagically.
Me No Dev
@me-no-dev
Dec 03 2015 23:15
@crushedice2000 are you saying that when you upload a file through the browser and it writes it to a new file keeping the old one?
I have had this happen to me when I had broken SPIFFS
formatting that fixes it :)

I have added this to my web server sketch:

server.on("/format", HTTP_GET, [](){ if(SPIFFS.format()) server.send(200, "text/plain", "FORMAT OK"); else server.send(500, "text/plain", "FORMAT FAILED"); });

and openning http://espip/format lets me format it