These are chat archives for esp8266/Arduino

3rd
Jul 2015
chad cormier roussel
@chadouming
Jul 03 2015 01:19
I can also give you my way of doing it :
/* float to string
 * f is the float to turn into a string
 * p is the precision (number of decimals)
 * return a string representation of the float.
 */
char *f2s(float f, int p) {
  char * pBuff;                         // use to remember which part of the buffer to use for dtostrf
  const int iSize = 10;                 // number of bufffers, one for each float before wrapping around
  static char sBuff[iSize][20];         // space for 20 characters including NULL terminator for each float
  static int iCount = 0;                // keep a tab of next place in sBuff to use
  pBuff = sBuff[iCount];                // use this buffer
  if (iCount >= iSize - 1) {            // check for wrap
    iCount = 0;                         // if wrapping start again and reset
  }
  else {
    iCount++;                           // advance the counter
  }
  return dtostrf(f, 0, p, pBuff);       // call the library function
}
Me No Dev
@me-no-dev
Jul 03 2015 09:07
any gain in using inline class members?
Me No Dev
@me-no-dev
Jul 03 2015 10:59
huge OTA update in my pull for whoever is following
make sure you use the updated example as well
chad cormier roussel
@chadouming
Jul 03 2015 12:27
cool, i'll have a look for sure :D
probonopd
@probonopd
Jul 03 2015 16:55
@me-no-dev, how can I test your work on OTA? Are there nightly builds or something like that?
Michael Miller
@Makuna
Jul 03 2015 17:32
@me-no-dev inline will save you the overhead of a function call. This is more important for small methods or one use methods inside loops. Avoid for large functions used in many places.
Me No Dev
@me-no-dev
Jul 03 2015 17:36
@Makuna exactly the answer I was looking for
@probonopd wait a bit, I found a bug in eboot
working on it
Me No Dev
@me-no-dev
Jul 03 2015 19:03
pfew... nasty issue
eboot first erases the space for the new sketch
then starts copying
in the way the address for the update was selected
Markus
@Links2004
Jul 03 2015 19:05
oO
Me No Dev
@me-no-dev
Jul 03 2015 19:05
if the new sketch is larger than the old one
the beginning of the new sketch got wiped
Markus
@Links2004
Jul 03 2015 19:05
this is bad
Me No Dev
@me-no-dev
Jul 03 2015 19:05
yup
took me a while to figure it out
so i opted to have max space half the available for both sketches
and start from the middle
Markus
@Links2004
Jul 03 2015 19:06
may simple store the new one at the right place is easier?
Me No Dev
@me-no-dev
Jul 03 2015 19:06
can't overwrite the runnign one while runnign it
Markus
@Links2004
Jul 03 2015 19:06
no not this way
currently the Esp.updateSketch store the new one direct after the old.
Me No Dev
@me-no-dev
Jul 03 2015 19:08
yeah, now I store it the size from the end + 20K
Markus
@Links2004
Jul 03 2015 19:08
it will work better if we store the new at the latest possible possistion
Me No Dev
@me-no-dev
Jul 03 2015 19:08
exactly
uint32_t freeSpaceEnd = (uint32_t)&_SPIFFS_start - 0x40200000 - (5 * FLASH_SECTOR_SIZE);
then I deduct the rounded sketch size to get the start address
Markus
@Links2004
Jul 03 2015 19:09
may we shut block updates with the size bigger then the half of storage, or you cant upload new ones at some point.
and getting you problem again on top
Me No Dev
@me-no-dev
Jul 03 2015 19:10
that is also what I did
i limit the incomming size to either half the space or what's left from the sketch now
whichever is smaller
Markus
@Links2004
Jul 03 2015 19:11
sounds good
Me No Dev
@me-no-dev
Jul 03 2015 19:12
when i update without knowing the final size beforehand, I start from that limit point with size what's left amd fill from then on
while I got your attention
i've been getting this strange error lately
lmac.c 669
which hangs everything and leads to reset
happens on busy network
have you had this happen to you
Markus
@Links2004
Jul 03 2015 19:15
have seen this too, a serial flash and it was gone, so i get no good way to debug it.
Me No Dev
@me-no-dev
Jul 03 2015 19:16
happens every once in a while when OTAing
i consume the data fast enough
so it's not overfill
Markus
@Links2004
Jul 03 2015 19:19
at reboot or during flash?
Me No Dev
@me-no-dev
Jul 03 2015 19:19
during flash
Markus
@Links2004
Jul 03 2015 19:20
have you close all other sockets (tcp/udp)
Me No Dev
@me-no-dev
Jul 03 2015 19:20
nope
should not need to
it's the same as uploading a file onto spiffs
we had no problem with that
and btw i've had it before when I was killing everythng else
Markus
@Links2004
Jul 03 2015 19:23
i get trouble at one point with udp pakets if they not Handel it in some time. but this was no lmac.c
calling WiFiUDP.stopAll(); if we start the update is a good idee i think.
\o/
Me No Dev
@me-no-dev
Jul 03 2015 21:19
great
i made the eboot go sector by sector
that makes possible update size up to the free space
as far as I can tell, the time it takes is the same
Me No Dev
@me-no-dev
Jul 03 2015 21:25
i hope this lmac will be gone
probonopd
@probonopd
Jul 03 2015 22:56
@me-no-dev is dns-sd working for you with the ESP8266 mDNS responder sample sketch?