Search results for:

@Gordon

We are currently at v1.99

So will you go three digits on the version v1.100 or are you going to roll over to v2.00?

A bit of a milestone in either case!

Have you got tx and rx the wrong way around?

I started an issue here for it with a few discussion points

https://github.com/espruino/Espruino/issues/1474

@jumjum
I guess what I'm asking is do you need to include the TLS library from ESP-idf?

@JumJum

What are we using in the ESP-idf that uses the mBed tls?

libmbedtls.a
Looks like this is being referenced in two different paths.

They might have moved it to a new location, and the Makefile, and your build, has both, so it's finding both and getting confused.

@JumJum

I have updated the build tools to use esp-idf 3.0.1

Let's keep a watch here:

https://github.com/espressif/esp-idf/releases

There is a v3.1-beta1 there now.

Should be update the old esp32 branch to current and use that? The v3.0 branch is now named incorrectly for the current v3.1.

I suppose we could drop that branch and add a 3.1 that we can then advance as the beta becomes live?

You mentioned Makefile and path changes that will need to be sorted.

what hardware are interfacing too? there might already be a module you can use - or something similiar that you could modify.

@jumjum

Please can you explain what the minHeap means here?

>ESP32.getState()
={
  "sdkVersion": "v3.0",
  "freeHeap": 38528, "BLE": true, "Wifi": true, "minHeap": 32720 }

@JumJum
Do you think it's worth updating to 3.01 ? Looks like there are some bug fixes.

@JumJum

https://github.com/espressif/esp-idf/releases/tag/v3.0.1

There is a new release - not sure if this addresses any of your concerns.

I can try a build with espruino-build tools and see if it works directly or if there are other changes required.

Please post all of your code.

Where are you seeing the error message?

The message appears to be coming from chrome - not from espruino

@gendor

Can you use babel?

Using a random googled input:

class Waiter {
  async wait() {
    return await Promise.resolve(1);
  }
}

new Waiter()
  .wait()
  .then(alert); // 1

http://babeljs.io/en/repl#?babili=false&browsers=&build=&builtIns=false&spec=false&loose=false&code_lz=MYGwhgzhAEDqYEsAuBTATtA3gKGtSAngHbDQDuiSAFAJRa57RopICuaR-Fy0ACmgHsAtgggoAdMwgCQANxRUAjDQDcDAL7ZN2IijJxK6Wg3HdqNE0gAWKIlTAh0SVdAD0r6IqA&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&sourceType=module&lineWrap=true&presets=es2015%2Creact%2Cstage-2&prettier=false&targets=&version=6.26.0&envVersion=

Espressif is to allow WROOM or WROVER to be supported with the same binary

They do support this, however it was not in the v3.0 release. It is the working branch ( unstable) at the moment.

To build with wrover with the v3.0, you have to make a change to the library, and then the same binary can't used on a regular board.

I think @jumjum was talking about 20,000 at one stage.

@DrAzzy
The initial problem you had should be largely sorted by this fix:

https://github.com/espruino/Espruino/commit/5c9c7b5c561eda7408b2e5d8194f8127a6a5d5f6

It allows the port to be reused.

>    require("http").get("http://drazzy.com/time.shtml", function(res) {
console.log({GMT:res.headers.Date});
        var contents = "";
        res.on('data', function(data) { contents += data; });
        res.on('close', function() {
console.log(contents);
setTime(contents); });
 }).on('error', function(e) {
:        console.log("ERROR", e);
:    });
=undefined
{
  "GMT": "Wed, 13 Jun 2018 11:22:54 GMT"
 }
Wed Jun 13 11:22:54 2018

Looks to me line 19 there is still a console.log.

Why don't you push the frame rates into an array and dump that at the end or in a timeout that happens say once a minute?

Are you powering via usb? Try another lead and also a different port on the computer - or try powering directly from a 10w charger

Following the calls from jswrap_net_kill it ends up here in the ESP32 case - so it has been implemented, so I think something else is going on.

https://github.com/espruino/Espruino/blob/fb99bda56518dfa50218fc419b24fac3584cfd9d/libs/network/esp32/network_esp32.c#L199-L203

I have also observed this behaviour in the ESP8266 build.

ohh -0nce a second you are going to the internet to update the time?

Instead do that a lot less frequently - say once an hour - and then set the internal clock to the time, and use the internal clock as your time reference.

What is probably happening is a new call to get the time is made, when the last has not finished.

What is the error output your are seeing?

What is the output of process.env ?

The will show the free jsvars after the load.

If you use the save on send option in the ide settings, the code will be stored in flash rather than ram and you might not run out of space then.

The issue is the the build is compiled with 10 sockets.
When you reset, the sockets are not closed. Part of the reason for this, is one of the sockets was the telnet server socket - you would loose your connection to the board.

If you saved the result of you your server connect as a global:

var server=require("http").createServer(onPageReque­st).listen(7348);

Then before the reset - you could do server.close()

This will shut down the connect and close the socket.

By the way, are using using a telnet connection? It is so much faster than the com port connection.

Oh - and your call to get the time - rather than have a page that returns the time - you can get the time out of the header..

There's a bug in the plugin that has been pushed to npm - lodash forEach - you have to edit that to get it to build which is a real pain.

There has also been some changes to the espruino (confusing name - the npm code that talks to a connected board) that allows you to specify the port as "tcp://1.2.3.4" where 1.2.3.4 is your ip - this sends over tcp rather than serial ansis about a million times quicker.

I've also looked at the parcel package for building code - although that does not intergrate with the sending to espruino part.