Search results for:

It seemed like it'd be well supported, and also well optimised for ARM (which basically every uC apart from ESP8266 is using). It also exposes SHA/AES/MD5/etc that would be useful to Pico owners in their own right.

I think the only thing stopping a lot of people using PolarSSL was the licence, but since it got acquired by ARM they moved to something far more permissive.

For ESP8266, it could be worth setting MBEDTLS_SSL_MAX_CONTENT_LEN in config.h and actually seeing if it can connect to any services. My guess is that stuff like Twitter won't support it though.

Thanks! Yes, writing to a file would be a good one - especially where the compiled/assembled code comes in.

With the watch, it looks like it's just a few lines of code... For people that want it to 'just work' it might be a good idea to have built in - but yes, if it's more complex than that it'd make more sense to use something built for it.

Wow, that works well! So is your finished code literally just what was posted above?

And glediator handles the zig-zag automatically?

This is stuff that @chalkers committed just yesterday, so it might need a few tweaks before it works first time.

Minification

Nothing you can do here without a lot of work. Just run it again tomorrow and it'll start where it left off and everything will be fine.

Reference page

It's built from the Espruino sources. Check out the Espruino project and run scripts/build_docs.py - or if you just want the 1v81 docs, download the zip file from espruno.com/Download and it's in there.

Index page

No, but you have 'Modules' and similar pages

Navigation

Yes, that's part of Espruino.com which isn't open source. You could add code to app.js that put a header and footer on to the pages it served up.

Thanks for letting me know... And your board came with that firmware on it as well?

Nope... It should work too, but I haven't tested. It just requires a separate build which I couldn't be bothered to put online. You could build it yourself though.

Ok, an update on this... It's working great now, and I have just merged HTTPS client support in.

You can get an early build for the Espruino Pico and Wiznet/ESP8266/GSM modules by copying and pasting this into Advanced Flash in the Web IDE's settings:

http://www.espruino.com/files/espruino_1­v81.274_pico_1r3_https.bin

And the code works just as before, just add https to the beginning of the URL:

digitalWrite(B9,1); // enable on Pico Shim V2
Serial2.setup(115200, { rx: A3, tx : A2 });
var wifi = require("ESP8266WiFi_0v25").connect(Seri­al2, function(err) {
  if (err) throw err;
  wifi.reset(function(err) {
    if (err) throw err;
    console.log("Connecting to WiFi");
    wifi.connect("WiFi_name","WiFi_key", function(err) {
      if (err) throw err;
      console.log("Connected");
      // Now you can do something, like an HTTP request
      require("http").get("https://google.com"­, function(res) {
        console.log("Response: ",res);
        res.on('data', function(d) {
          console.log("--->"+d);
        });
      });
    });
  });
});

However, bad news for those of you thinking of using this on other boards. The TLS spec seems to require that there be 16kB packet sizes, and it looks like you need two buffers. So you need over 32kB of free RAM minimum if you're going to abide by the spec. There's an extension to this where the client can ask for smaller buffers, but it's not guaranteed to work at all.

So it looks like running HTTPS on the ESP8266 is never going to happen (we have 12kB available for all code and variables currently). That'll have to wait for the new one EspressIF are releasing :)

Thanks!

It should just be COM12 or similar. The easiest way is to click connect in the Web IDE, and see what number it reports (but you could look in Windows' Devices and Printers menu).

Just uploaded it here - as espruino for now as I didn't see UliMerkel's post when I did it.

... it's early days, so I can always change it later.

Hi,

Just to say that I finally got around to creating a NPM module for Espruino.

If you have node.js and NPM installed you can just do:

npm install -g espruino

and you'll get the command-line tool.

Instructions here

You can also use it to do things from node.js on your PC:

require('espruino').expr('/dev/ttyACM0',­ 'E.getTemperature()', function(temp) {
        console.log('Current temperature is '+temp); 
});

It still needs a bit of work, but hopefully this will be a good start.

I'm thinking I'll finally submit the command-line tool for Espruino to NPM, as espruino has become clear now.

... but any thoughts as to what would be a good name for the command? Currently it's espruinotool, but that's pretty longwinded.

What about:

• esp - too short - might get confused with something else?
  
• esptool - probably not given the ESP8266 programmer is already called that :)
  
• espr?
  
• espruino - might get confused with the actual Espruino binary?
  

Just to add that you could also be having some electrical issues if you get flickering - I think there's a note on the WS2811 page about using a pullup resistor and putting SPI into Open Drain mode? It might be needed if you're running the panel off a separate 5v supply.

... finally I don't know if Glediator handles the zig-zag pattern of the LEDs? It could be a pain to try and re-order them quickly. About the only thing I can think is to use Graphics with drawImage of the image data you received.

The 'out of memory' error sounds like you're not getting a newline, so are just making a huge string with all the data from multiple frames?

Actually, if you look at that Arduino file you sent, it seems to me like it's sending binary data and is using a simple 1 as the 'new frame' character (line 110) - presumably it ensures that it just never sends '1' normally.

Try:

function onInit() {
    SPI2.setup({baud:3200000, mosi:B15});    
    var cmd = "";
    Serial3.setup(1000000, {tx:C10,rx:C11});
    Serial3.on('data', function (data) {
      cmd+=data;
      var idx = cmd.indexOf("\1");
      while (idx>=0) {
        var line = cmd.substr(0,idx);
        cmd = cmd.substr(idx+1);
        idx = cmd.indexOf("\1");
        SPI2.send4bit(line, 0b0001, 0b0011);    
      }
    });
  }
  onInit(); 

Yeah, the issue is really getting something that works well across all devices without using too much memory.

... and then some poor sucker (me, most likely) has to make the changes and test on Linux, Pi, ESP8266, Pico, Original Espruino, ESP8266 with AT commands, WIZnet, SIM900 GSM and CC3000 :(

Right now, anyone could get UDP working in JavaScript using ESP8266 + a normal Espruino board in a few minutes. It's just a matter of using the existing module as a base and changing the text TCP to UDP. Nobody's bothered though :)

Yes, it's 1.2. mbedtls seems quite flexible so potentially other things could be used though.

When 1v82 comes out there'll be documentation in the reference page on espruino.com - until then you can build it yourself by running the scripts/build_docs.py script on the Espruino repository on GitHub.

There's also some very basic test code at: https://github.com/espruino/Espruino/blo­b/master/tests/test_crypto.js

Or if you don't want to build the docs, search for occurrences of JSON in https://github.com/espruino/Espruino/blo­b/master/libs/crypto/jswrap_crypto.c

You currently have:

• SHA1/224/256/384/512
  
• PBKDF2
  
• AES CBC/CFB/CTR/ECB
  
  

The API is meant to be just like CryprtoJS - but instead of returning a custom class, functions just return ArrayBuffers

Great, thanks @Kolban!

With the HTTPS stuff (see the other thread) I'll hopefully get the async connect stuff added (I still have to figure out a nice way of handling it) and that should help simplify the ESP8266 side.

Do you currently handle name resolution as part of the connection? If not, I'd hold off doing that. Hopefully the async changes will make that a lot easier too.

It looks like there's some USB data connection issue (it seems like USB power is connected fine).

Please can you take a look at the back of your Pico and see if the PCB is scratched such that you can see copper?

If you're using one of the white Apple Extension leads, the 'spring' they put on the back of the lead tends to dig into the back of the Pico and can short out one of the USB data connections.

If that's it, the fix is quite easy:

• Use a non-Apple extension lead. Everyone else uses one with two leaf springs that don't scratch the PCB, and won't cause problems with the existing scratch.
  
• You can cut the offending track on the Pico (it's not needed) and you can then keep using it with whatever extension lead you want.
  
  

If that's not it, it'd be worth cleaning the contacts on the Pico (ideally with some kind of alcohol), and maybe trying a different extension.

It's still early VERY days, but it's now possible to:

• Check out the HTTPS branch on GitHub
  
• build and flash with make clean;PICO_1V3=1 WIZNET=1 USE_HTTPS=1 make serialflash
  
  

then...

SPI2.setup({ mosi:B15, miso:B14, sck:B13 });
var eth = require("WIZnet").connect(SPI2, B10);
eth.setIP(); // DHCP
require("http").get("https://www.google.­com", function(res) {
  res.on('data', function(data) { console.log(data);    });
});

HTTPS support works on:

• Linux, Raspberry Pi, OpenWRT stuff
  
• Pico with WIZnet ethernet
  
  

There are some big issues:

• There's no cleanup, so you can only do a single HTTPS request before it fails right now
  
• You can only do one HTTPS request at once
  
• The network API needs reworking to allow nonblocking connect and name resolution before ESP8266 (AT or native)/CC3000/etc will work. But when that's done, it'll solve a few other problems too!
  
  

This uses a lot of code space, and realistically it's not going to fit on the Original Espruino board unless you're happy using the extra flash memory that isn't supposed to exist (but does).

Would Gordon's list of unused flash pages help ?

To be fair, this was @tve's idea originally ;)

The list would be created by the process.memory function, so potentially some runtime checks could be done to see what part was being used?

I'll update the Quick Start on the website, but version 1.3.1 is available here now: https://github.com/espruino/EspruinoDocs­/blob/master/files/stm32_vcp_1.3.1.zip

and should hopefully work for you on XP.

Just to check: did you actually try and install the drivers from 1.4.0 on your XP PC? It seems strange that XP drivers would actually have been removed.

Yep, those batteries look good.

still_waiting_for_more_infos

Yeah, was that in the SIM900 driver? It was some contributed code and I ended up buying two SIM900 modules that don't work in the UK, so I haven't been able to test it out properly!

SMS

If you do a google search for site:forum.espruino.com sms you'll find some code people have used for this in the past.

Now there's the AT library it should be a bit easier too.

When you do the SMS stuff, it'd be really good if you could put it up as a module - it'd be really useful for loads of people I reckon.

Oh, I just looked again - and you're just creating a Waveform, not doing anything, and then reading back the values. It's not really surprising the array is just full of 0?

What about doing what's described on the waveform page, and using the finish event?

var w = new Waveform(128);
w.on("finish", function(buf) {  //<----------- this
  // your temperature reading code
});
w.startInput(A0,2000,{repeat:false});

Wow, there's an awful lot of stuff there :)

Just to say I have some of @DrAzzy's early proto boards, and they're really nice.

@DrAzzy if you wanted to submit a PR with links to (for instance) your mosfet boards under 'buying' on http://www.espruino.com/mosfets then a few more people might find out about them?

Could you post up the contents of myarr.buffer, the contents of view and the actual results you're getting?

As far as I can see, if you get an analog reading less than 0.4 (so 0.4*3.3 = 1.32v) it's going to give you a negative temperature in degrees C.