Search results for:

@Ducky -- Thanks! I always wondered what the code was -- it should be easy for any of us to throw this up on Heroku -- I think for a couple years now their free their account allows running a dyno for 24 hours....or AWS if you're more dedicated :P

+1 Yes that would be cool to have it as a service here. :)

Another way -- though weird, but cheap, would be to compile Espruino for the 8266 to get TLS going, and then use a second one to communicate with it using the first one to do the HTTPS requests (either via WiFi or the UART). Considering their price it would still be under $5 ... though could suck up alot of your time - so be prepared :P . The Espruino WiFi that Gordon sells sounds like a nice solution that "just works", if you're doing one off production.

Ok thats great! I actually am developing a workshop for kids as well -- might be a good choice. Thanks for the feedback.

Yes I agree -- very interesting! :)

I recently picked up this book:

https://www.nostarch.com/hardwarehacker

which was recommended on Hack A Day -- slightly tangential, but focused on China based manufacturing. As someone who spends a fair amount of time in Asia each year, I'm curious to see how easy it would be to setup a (small - say 1000s) production run of a particular board there (say for example an MCU and a WS2812 unit, in an all in one package).

What were the warnings? I never get any warnings anymore when compiling my firmware (and yes I do use the FS + FLASH options), since @Wilberforce fixed all the type casting.

So here is a question, its not really a problem. I understand it has very few JSVars (300 or so?). I think its a very cool platform -- have you done some interesting projects with this limit? If its just for one off things (like a bluetooth button, and or using its display), it could still be really fun....so curious about its utility.

(I'm also a patron ;)

I guess another way to put this is -- have I and @AntiCat misunderstood this feature -- or is there really a bug? :)

Yes, I use onInit. However my point was more that the code loads and works fine though if I disable Save On Send. If I enable it it runs out of memory on upload. To me it looks like the code is not getting minified when Save On Send is set.

Anyways no big deal I'll just disable it as I always have. I was just curious to try this feature.

Weirdly I tried this on an ESP8266 -- and first the uploaded code was the same size as the IDE code (suggesting it hadn't been minified -- as its usually much smaller by almost 1/3), and then at one point during the upload the board just freaked out with an out of memory error and then a continuous stream of "Execution Interrupted", until the upload failed due to the "Prompt not detected error...".

Under communications I had selected upload modules as functions, and then after "Save On Send" was set to "Yes". And under Minification I have both modules and regular code set to simple optimizations using Closure.

The board was flashed with a standard v92, using the last official release.

@MaBe So a quick update -- the ESP-201 is supposed to come with only 4mbit flash, and this is even supported by many photos online (at least I guess of early chips), but mine for whatever reason have 8mbit parts (maybe they ran out at the factory of the 4mbit flash? Who knows). This is what caused the problem. So I guess you can never assume anything in the ESP world :P

So I did erase the flash and use the following as per the README (adjusted for 8mbit flash):

esptool.py --port [/dev/ttyUSB0|COM1] --baud 115200 write_flash \
  --flash_freq 40m --flash_mode qio --flash_size 8m \
  0x0000 "boot_v1.6.bin" 0x1000 espruino_esp8266_user1.bin 
  0xFC000 esp_init_data_default.bin 0xFE000 blank.bin

and now it works, and thus no need for the combined file. Anyways so if anyone else has an ESP-201 board and is having problems flashing, please check the part size for the flash.

-hfc

Yes those were in the instructions and I followed them :) I will try again with the ESP-01 (I have a few coming in anyways), as I did that with the ESP-201 and had a negative result.

@MaBe @Fabiano-Gomes So just to report it did work on my ESP-01. I was able to flash it using the espruino_1v92_esp8266_combined_512.bin file. And after wifi.save() worked correctly.

Interestingly though both v92 and v91 combined files put my ESP-201 into a constant restart mode where the blue light on it flashed continuously. I downgraded to v86 and it works fine, so I'll use that for these remaining boards. Espytool said it autodetected 8m of flash, which would suggest that the ESP-201 is not a 512KB board as the spec suggests, but rather a 1MB board.

Either way, maybe we should include the espruino_1v92_esp8266_combined_512.bin file by default in the v92 distribution?

Just curious why this way preserves the wifi.save() functionality, and the more complex way does not?

Anyways thanks guys! :)

@MaBe great! Thank you :) I'll try your suggestion too and report back :)

Hi Guys,

Just curious if anyone can reproduce this problem. I noticed that when I flashed my 512K boards (specifically an ESP-01, and several ESP-201s), that they did not execute wifi.save(), and thus when restarted did not automatically connect to the network. The network parameters were blank/null.

I went BACK and tried v86 -- my kind of "standard" -- that always works, and after v91. Both work fine. However, I was using the following method:

esptool.py  --port /dev/ttyUSB0 --baud 115200 write_flash 0 espruino_1v91_esp8266_combined_512.bin

After I was able to use wifi.save() normally, and the boards reconnected normally on startup. However after some experimentation I discovered that if I use for example:

esptool.py --port /dev/ttyUSB0 --baud 115200 write_flash \
  --flash_freq 40m --flash_mode qio --flash_size 4m \
  0x0000 "boot_v1.6.bin" 0x1000 espruino_esp8266_user1.bin
  0x7C000 esp_init_data_default.bin 0x7E000 blank.bin

on v91 then it does NOT save any wifi configuration when I do wifi.save().

As v92 does not have the "espruino_1v92_esp8266_combined_512.bin" file, its impossible to test between the two methods.

I'm curious if anyone else can confirm this, or if perhaps its a problem with my setup. I have not tested if this problem exists on my 4MB flash boards at this point.

Thanks :)
-hfc.

@MaBe Hello! This was a great link and very informative, thank you :) I'll see what I can do on my side to mitigate the effect. :)

Ah, OK thanks -- I will do that :)

Hello Everyone,

I was in the process of adapting some code from

http://forum.espruino.com/conversations/301910/

to test out writing using fs.pipe() on Espruino/8266 to the new file system enhancement. And I came across a strange problem -- at least for me. I may not be coding it right, and or it maybe a known problem I'm not aware of, though its happened on two boards now. So I thought I'd share it with you to get your feedback.

Basically with this code:

var http = require("http");
var wifi=require("Wifi");
var esp8266=require("ESP8266"); // for esp8266.printLog()

var page = "<html><head><title>test pipe</title><script src=\"https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js\"></script></head><body><button id=\"getPage\">Reload Page</button><textarea rows=\"5\" cols=\"100\" id=\"Htmlfile\"></textarea></body><script>$(\"#getPage\").click(function(){$.get(\"/getPage\",function(data){$(\"#Htmlfile\").val(data);})});</script></html>";

function handleGet(req,res) {
  console.log("handleGet() -> req");
  console.log(req);
  
  if (req.url=="/getPage" || req.url== "/") {
    
    res.writeHead(200,{"Content-Type":"text/html"});
    res.end(page);
    
  } else {
    res.writeHead(404);
    res.end("404 Not Found");
   }
}

function onPageRequest(req,res) {
    console.log("onPageRequest() -> req");
    console.log(req);
 
    if(req.method == 'GET') 
       handleGet(req,res);
    //else req.connection.destroy();
  
}

E.on("init", function () {
      wifi.connect(wifi.getDetails().ssid, {password: wifi.getDetails().password}, function(err) {
          if (err) {
            console.log("Connection error: "+err);
            return;
          }
          console.log("Connected!");
          console.log(wifi.getIP());
          server = http.createServer(onPageRequest);
 server.listen(80);
        });
});

After 7 to 9 sequential requests spaced by a few seconds (ie: pressing the button in the example), I would get a failure status in Chrome's developer tools and of course no data would be returned, as shown in the included screenshot. I was doing this manually (pressing the button), and made sure to wait until the requests had completed in the browser. If I pressed RELOAD in the browser (not the button in the html page), the 8266 would also fail to send anything, though interestingly it was still seeing the requests, as they would be "consoled" properly. Just nothing was returned.

If I waited 5 minutes or so, I could do it again another 7-9 times then it would fail. I suppose it could be a fun game if I had been drinking, but this was not the case. :) And I suppose the more practically minded of you would tell me just not to press it so often :P

By including this line:

memoryInterval=setInterval(function() {console.log(process.memory());},1000);

I could see easily that free memory almost always stayed between around 1400-1513.

{ "free": 1513, "usage": 187, "total": 1700, "history": 105 }

After each failure esp8266.printLog shows something like this:

>esp8266.printLog()
70, heap: 2592
793824> espconn_tcp_delete 1, 80
794217> > jshReset
794218> < jshReset
807169> E:M 416
816078> E:M 416
817512> E:M 416
818945> E:M 416
820081> E:M 416
840002> Thu Jan 01 00:14:00 1970, heap: 1376
900002> Thu Jan 01 00:15:00 1970, heap: 1376
=undefined

and another time:

>esp8266.printLog()
2> E:M 656
 43382> E:M 656
 43382> E:M 656
 43382> E:M 656
 43382> E:M 656
 43382> E:M 656
 43383> E:M 656
 45902> E:M 656
 45902> E:M 656
 45902> E:M 656
 45903> E:M 656
 45903> E:M 656
 45903> E:M 656
 45903> E:M 656
 45903> E:M 656
 45903> E:M 656
=undefined

So my first question is have I done anything visible wrong in my code? And then if not, can anyone replicate this? Or have any other ideas?

For what its worth, I have a few ESP8266s talking to each other (so 2-4) in another project, so we could imagine that this scenario would occur if some of the units made some requests quickly in sequence. So its something that could be seen "live" somewhere outside of this example, at least for me.

Thanks :)
-hfc

BTW: I'm using 1v91.741.

Hi everyone, I've posted my results in GitHub. Thanks :)

I'll test also on the ESP8266 and report back, as it was definitely on that board that I first encountered the problem, as opposed to the ESP32.

I love Espruino and bacon! :P