Search results for:

Are both versions using the same firmware, and hardware SPI?

Also, could one be using Paletted code and the other not? There are now some differences there: http://www.espruino.com/ILI9341

Thanks - I've filed an issue for it now: https://github.com/espruino/Espruino/iss­ues/742

Yes, that sounds like a good idea. I guess you'd still have problems with 'daylight saving time' but it'd be a great help for the majority of things.

I added an 'issue' for it here: https://github.com/espruino/EspruinoTool­s/issues/17

Thanks - that's an odd error. It looks like it's as I said above though - out of memory :(

Without key,cert' andca` you'd probably be ok, but right now there doesn't seem to be enough free memory for all the TLS buffers required and the keys. I'll look into @allObjects' suggestion of storing the keys in flash - that could be a big help.

Thanks - I'll change the documentation. I vaguely remember changing it - the reasoning was that if you made a really long interval, it got difficult to change it to anything shorter.

If you want the old behaviour it's easy enough to fake:

var interval = setInterval( function() {
  if (newInterval) {
    changeInterval(interval, newInterval);
    newInterval =  undefined;
  }
  // ...
, 1000 );
var newInterval = 1000;

Add a * to espruino in 1 - so espruino*. Then hit enter.

Or try removing espruino from 1 and then manually looking for the espruino_pico library.

The other option is:

• Put espruino_pico.lbr in your project folder
  
• In Control panel, navigate to it, and click the down arrow to expand espruino_pico.lbr
  
• Find the outline you want (maybe ESPRUINO_PICO_HALFSMD) and then just click and drag it onto your Schematic (not the board layout).
  
  

That's what I usually do - it's much easier than fighting with the 500 libraries in the Add... window. The search there is a disaster and it's easy to miss what you're looking for unless you use wildcards.

Thanks - I just posted here

1v83 won't do that, but it should be possible with some changes. I filed an issue for it here: https://github.com/espruino/Espruino/iss­ues/738

... if only! Sadly I don't think there's a way to do that with the firmware as it is now, because the API requires that all 3 variables are in the same object at once.

However I might be able to make some minor changes to make that happen. I have just filed an issue for it: https://github.com/espruino/Espruino/iss­ues/738

And 1v83 is released now, so it's fine to use again.

1v83 released, and there's now enough memory free - so you can go back to using the flash again.

Just to add, while this works in theory, in practice there could be trouble. It doesn't look like there's enough RAM in the Pico to store the all the information needed for the certificates.

Ok, just done. For instance the following now works:

var options = url.parse("https://localhost");
options.key = atob("MIIJKQ ... OZs08C");
options.cert = atob("MIIFi ... Uf93rN+");
options.ca = atob("MIIFgDCC ... GosQML4sc=");
require("http").get(options, ... );

If you have the certificates as .pem files, you need to load these files, take the
information between the lines beginning with ----, remove the newlines from it
so you have raw base64, and then feed it into atob as above.

This will be in http://www.espruino.com/binaries/git/com­mits/master/ - just give it an hour for the latest build to appear in there.

That's strange...

I have 7.4 here and when I open it up I get the following window. What happens if you do File -> Open -> Library from the control panel and open the library directly?

@aerialist_user6911 now the Pico supports HTTPS, I wonder whether your code would finally work?

There's also require("crypto").SHA1 as well which might tidy things up a little?

It's a good point... Yes, I think that makes a lot of sense. After all, you're going to know what information you're interested in - and on other devices that don't do AP, those functions just get left out.

... I think the ESP8266.reboot() is overkill. To be honest we should probably make that E.reboot() or E.hardReset() and expose it as a function in jshardware.c. It'd be really useful for STM32s as well.

Hmm - actually that documentation isn't too clear... It should (IMO):

• Close any sockets opened by the JS code (does this)
  
• Clear the program/intervals/etc and not load saved code (does this)
  
• Reset the pin states to power-on states (jshReset)
  
  

Ideally it should be as close to power-on as possible, but as you say we ought to think that maybe someone will be programming it via a network connection in the future.

So yes, I think probably leave WiFi as-is. There is the default argument when connecting to an AP or making one, and I wonder whether if that is false we should probably disconnect from WiFi (you can put it to sleep I think?).

We should really move fully over to jsException(JSET_ERROR and kill jsError eventually... jsError was used before Espruino had Exceptions, and it's not part of the JavaScript spec at all.

I'm afraid it's just a bit of a hangover. There are other error types though - TypeError (invalid arguments) and InternalError (stuff that went wrong in Espruino) might be the most useful.

Yes, that's correct - at that link there will be the absolute latest build of Espruino available.

However that may not be what everyone wants, as it could be a bit hit or miss whether it works or not. It might be better to keep EspruinoBuilds going for a bit with a Neil-curated version of Espruino for the ESP8266.

I think when I do the next full release (probably 1v84 - I plan to rush 1v83 out now because of an issue with the Pico's 1v82 firmware) I'll stick ESP8266 in the downloads and get the Wifi class documentation pulled into the Reference - and then we could retire EspruinoBuilds - because there'll be 'stable' build available, and a proper 'release'.

Are you connecting Espruino to an ESP8266, or are you running the Espruino firmware on and ESP8266? It sounds like the latter.

If so, you're going to have to make changes to the C code itself: https://github.com/espruino/Espruino

Hi,

Recently we've had a whole lot of 'issues' posted on the Espruino forums that relate to the Espruino software running on the ESP8266. (This isn't the same as connecting a ESP8266 module to an Espruino board).

The port of Espruino is still under heavy development, and there are quite a few gotchas. Please look and post here for any issues related to it - you're much more likely to find an answer, and less likely to confuse any users who have bought an official Espruino board :)

@tve is there actually a separate A0 pin, or is it the same as D0? I wouldn't duplicate pin names - that'd just get confusing.

Cool - thanks for posting up! For others looking at this, the last 2 code snippets here are ESP8266-specific

Ok, I just filed an issue for this: https://github.com/espruino/Espruino/iss­ues/736

I'm not sure when I'll get around to it, but I'll see what can be done. It doesn't look like it'll be too painful to implement.

Depends what you're doing, but you could just convert both objects to a String with JSON.stringify and compare the strings?

Can you file a bug for instanceof? I'm kind of surprised about that - I thought those kind of issues had been ironed out a while back.

I think in JS, an array is Array, which is also an instance of Object. Espruino currently has a bit of a shonky prototype chain implementation, and it's possible instanceof has fallen foul of that.