Search results for:

Surely it's got to be better than the current web request to the closure compiler (which is also without any status indication)

IIRC the JavaScript transpilation result is significantly slower compared to the native Java service provided (GWT is used to transpile from Java).

From this perspective I'd rather try babel-minify or the terser for minification. I used the terser in the rollup plugin.

Rollup (or webpack) give you IMHO quite important tree-shaking. Especially important for the Espruino's microcontroller world.

I think there is no point in trying to reinvent the wheel with regards to the bundling pipeline. What is the point in keeping this Espruino specific?

Yeah, I know - sorry about that PR. I've been on the fence about adding the big chunk of extra code for far too long, but I'll try and get it in this/next week. It's just a shame we can't do some kind of 'load on demand' thing.

It should be possible to lazy-load the closure compiler. My main concern was the time it takes to execute and the lack of any visual hint on that the browser is working on something.. Perhaps wasm would help eventually. Also this could be done in a webworker so that it would not block the js event queue.

I'm unsure about how rollup would work in the Web IDE though - doesn't it expect to be able to pull in NPM modules? I don't see how that'd work at all when running in the browser.

It should be possible to make it work. Rollup doesn't pull anything on its own. Only the https://github.com/opichals/rollup-plugi­n-espruino-modules/blob/master/espruino-­tools.js is actually fetching stuff from espruino.com and we could update this for sure (using CORS it would work even from the IDE hosted anywhere). You can replace the default loader to do anything - it doesn't have to touch any filesystem IMO.

With babel and the rest it might be a different story, but there is again the babel-standalone which is easily runnable in the browser if required.

@Gordon Storage module resolution would be a nice thing to have if the IDE would allow synchronizing them would sound as an interesting feature.

Using the external tools like rollup and the terser used to minify the bundle in the rollup plugin one can avoid hitting es6 (arrow functions) related minifcation issues for example. Also does the module contents merging mentioned in https://github.com/espruino/EspruinoTool­s/issues/27.

Although it will require some work I think we should be able to get rollup (and perhaps even the babel functionality if deemed interesting) including the necessary plugins into the EspruinoTools and therefore into the EspruinoIDE. There is no reaction on the EspruinoTools google-closure-compiler-js PR . @Gordon what would be your position on that?

@MaBe I'd rather not make the default firmware images bigger by including stuff people won't use. I'd instead aim for the 'Storage' module assigned flash space expansion for the boards where possible (like the ESP8266_4MB) and use tools like rollup to put stuff in.

I've looked into loading Espruino modules straight from
espruino.com/modules, and while that seems possible, I think It will
have to wait untill I actually need is, I have enough on my plate as
it is.

If someone else wants to give it a shot, the relevant Rollup hooks
appear to be resolveId and load.

https://github.com/opichals/rollup-plugi­n-espruino-modules (not published to npm yet).

It is generates a default config for Espruino which currently also does minification by default. It is just a first shot as it needs refinement with regards to configuration possibilities but it works quite nicely. It downloads the modules into the local ./modules folder

I converted the webpack/babel example to use this and babel 7.x here https://github.com/opichals/espruino-rol­lup-babel-sample

By using the import statements in the app code one can get use of tree shaking so that e.g. the SSD1306 driver's connectSPI is not bundled when not used.

caveat: I haven't tried the resulting bundles on-board yet.

@Gordon If considered then I think it would require native support to match the spec behavior

Proper Map and Set implementation allow the keys be an arbitrary Object for polyfills that requires the lookup be O(n) instead of O(1) as there AFAIK isn't any other way then to approximately this m.get = (key) => m[ Object.keys(m).find(k => m[k] === key) ].

@J{a}SON I would wait for the https://github.com/espruino/Espruino/pul­l/1415 to get merged and then grab the master build for further tests.

Submitted a fix PR

I tried the getPage() and it did work for me when the URL is correct. Cutting & pasting from the forum's example however mangled the URL for me so I got a 'Not found' error.

@J{a}SON could you try this and post the whole console result?

require("http").get("http://www.pur3.co.­uk/hello.txt", function(res) {
  console.log("Response: ",res);
  res.on('data', function(d) {
    console.log("--->"+d);
  });
}).on('error', function(err) {
  console.log('ERROR', err);
});

as you're working in JS you could look at compiling Espruino with Emscripten

A while ago I played with that idea for a bit. Got to the point where I got the minimum running within node.js but for more it would require some clever work on implementing the JS<->C trampoline properly.

@AntiCat Thanks, exactly.

@SergeP @Gordon I don't think this is a bug but rather a feature that the Espruino cleanInterval() implementation deviates from the specified behaviour by cancelling all scheduled timeouts and intervals rather then doing nothing.

That said unless we would like to change the behavior to comply to the spec which would break a lot of existing user code done specifically for Espruino (perhaps doable using some sort of deprecation mechanism).

@allObjects While putting the credentials into a module is a possible way of 'hiding' it from the application module it still logically doesn't belong there. It forces people using or deriving the application code to have such module as well or to change the code which is not clean.

There is also security aspect which we might want to think of. The configuration API should be done so that the sensitive information could be stored encrypted in a safe place and not in flash memory (something the BigClown core module would support).

@Gordon Thanks for the 'Storage' module! Its use should to be a great way of not having to duplicate the serialization (JSON.stringify should suffice?) and flash access in the jswrap_wifi_save/restore methods. I would still vote for a .wifiauth file (or a more generic .config perhaps?) which would get loaded and wifi connected after every reset independently of the E.setBootCode stuff.

BTW What would you think of using a leading dot (or perhaps some other character of your liking) in the filename as a nice way of distinguishing internal files.

Also thank you for the onInit() { on('connected', ...) } note, I haven't noticed that before for some reason.

@Ollie I somehow didn't spend too much time but I think I could not find a way to pass arguments/env variable values to the espruino npm's cli .js script.

I find it quite a good feature of not having to include the SSID and credentials to the actual device code. It doesn't belong there. I use onInit() { wifi.on('connected', function() {}) }.

I wish I could do something like espruino -e 'wifi.connect($SSID, { password: $PASS }, () => wifi.save()) where I would be prompted to type in the password which would be sent to the board but I have yet to find a way which would not require saving the script to a file first.

Finally I got it working. The wiring based on the schematics is as follows

           SHIELD      Espruino
MOSI   ICSP4          B5
MISO   ICSP1          B4
SCK    ICSP3          B3
CS     JHIGH3 (10)    B2
3V3    ICSP2          3V3
GND    ICSP6          GND

The shield worked with 3.3V as well as 5V wiring with level shifters.

So I managed to resurrect the Espruino board with serialflash.

However I didn't have much luck so far with the current master. I tried using 3.3V as well as with level shifters to 5V (according to the shield spec).

>var eth = require("WIZnet").connect();
=Ethernet {  }
>eth.getIP()
={
  "ip": "0.0.0.0",
  "subnet": "0.0.0.0",
  "gateway": "0.0.0.0",
  "dns": "0.0.0.0",
  "mac": "00:00:00:00:00:00"
 }
>eth.setIP({ "ip": "10.0.5.3", "subnet": "255.255.255.0",
: "gateway": "10.0.5.1", "dns": "8.8.8.8", "mac": "aa:bb:cc:dd:ee:ff"
: });
=true
>eth.getIP()
={
  "ip": "0.0.0.0",
  "subnet": "0.0.0.0",
  "gateway": "0.0.0.0",
  "dns": "8.8.8.8",
  "mac": "00:00:00:00:00:00"
 }

Thank you Gordon! Got it flashing correctly...

After few experiments though I closed the flashing dialog during a running flash and pressed RST on the board which bricked it. Now I need do learn how to do the serialflash procedure I guess ;)

So no real W5100 success on my side yet.

Hey!

There is a running campaign for BigClown make kit here https://www.indiegogo.com/projects/bigcl­own-the-iot-kit-for-makers-for-you-diy#/­ .

Their core module is 19EUR (192k flash, 20k RAM, ARM Cortex M0+ 32-bit MCU STM32L083CZ (ST)... so similar to Olimexino STM32) or 29EUR for the same thing with an RF chip for wireless communication. It all comes with great support, security chip on board, an async API based SDK and a warranty.

What would you think of porting Espruino to it? Any interest?

Best Regards
Standa

Ah, I guess I got it. As documented in README_Building.md I need to build bootload+firmware image using scripts/create_espruino_image_1v3.sh. Will try tomorrow.

I've got two of the W5100 Arduino Ethernet Shield 05 (at least according to this page) so I plan on testing those as I get to it.

However for now there seems to be something wrong on my side. Perhaps the PR reported .bin size issues are not valid as I found that my vagrant created VM is not delivering a working .bin. I also tried to compile master even w/o wiznet myself and tried flashing it through the 'Advanced Flashing' in the EspruinoIDE and it failed the same way (EspruinoBoard v1.3). It doesn't come up after RST, after a seemingly successful flash procedure. It is not present in the connectable USB devices after that. The official travis-built master from http://www.espruino.com/binaries/travis/­master/espruino_1v95.153_espruino_1r3.bi­n works fine though.

Here are the steps I do this to build the firmware .bin

vagrant up
vagrant ssh
cd /vagrant
source scripts/provision.sh ESPRUINOBOARD
RELEASE=1 BOARD=ESPRUINOBOARD make

Any idea why this could be broken?

There is a PR for it now https://github.com/espruino/Espruino/pul­l/1316

There is a PR for it now https://github.com/espruino/Espruino/pul­l/1316

According to this the 1.5.0 version might be required http://bbs.espressif.com/viewtopic.php?f­=66&t=1677&p=5517&hilit=CIPDINFO#p5517. So perhaps the CIPSTATUS workaround (could be problematic for multiple subsequent incoming +IPDs of different origins) and when the CIPDINFO works use rather that.

But that gets complicated. Does EspruinoWifi support updating the ESP firmware? With that it could get integrated into the EspruinoWebIDE flasher which would be sufficient IMO.

There seems to be even better way which would be to use AT+CIPDINFO according to the docs PDF.

On github I could only find the CIPDINFO in the docs for ESP32 though and the implementation seems to be in the libat_core.a which looks like a closed source thing probably shared across the ESPs.

It may be that this just isn't possible with the ESP8266 AT firmware. As far as I can tell the AT firmware provides no information on where a UDP packet came from (address/port), so it might not be possible to send a response back to the right address (unless you know for sure where Alexa is).

The CIPSTATUS (implementation source link) seems to be the command returning the remote_port/ip information. Perhaps that could be send for every +IPD received?