Avatar for Gordon

Gordon

Member since Sep 2013 • Last active Oct 2017

Most recent activity

  • in Interfacing
    Avatar for Gordon

    You know you can also share the SPI pins? So you just re-use the same MOSI, MOSI and SCLK for all your parts, and then give them separate CS pins?

    Also with I2C you can just share the same 2 wires for everything, as long as you have different devices (so they have different addresses). It might even be that you can do what you need without a port expander?

  • in JavaScript
    Avatar for Gordon

    I believe so, yes. Thinking about it, it's possible that the module loader doesn't take the path of the file into account - only the current directory.

  • in Interfacing
    Avatar for Gordon

    I just saw your other post and the title, and with the MCP23017 the code would look a little like this:

    var port = require("MCP23017").connect(i2c, null, address);
    var mosi = port.A0;
    var sclk = port.A1;
    var spi = {
      write : function(data,cs) {
        if (cs) cs.write(0);
        E.toUint8Array(data).forEach(function(by­te) {
         for (var i=7;i>=0;i++) {
           mosi.write((byte>>i)&1);
           sclk.write(1);
           sclk.write(0);
         }
        });    
        if (cs) cs.write(1);
      }
    };
    var disp = require("MAX7219").connect(spi,port.A2);­
    

    Not tested, but it should work. The nRF24 reads from SPI, so you'd need to implement an SPI.send function to get it working though.

  • in Interfacing
    Avatar for Gordon

    You could do very slow software SPI pretty easily over a port expander, and could even write your own SPI class which you could feed into existing modules.

    I have literally just made digitalWrite/Read able to use an object passed in, so assuming you're using a 'cutting edge' build of Espruino (or 1v95 when it's available), you should be able to do:

    var spi = {
      write : function() { SPI write code }
    };
    var cspin = {
      write : function(v) { write value to pin }
    };
    var disp = require("MAX7219").connect(spi,cspin);
    
  • in Pico / Wifi / Original Espruino
    Avatar for Gordon

    Thanks @ClearMemory041063 - @sureshkm you basically just need to generate a random series of bytes for the array, as in the code above.

  • in JavaScript
    Avatar for Gordon

    It should be fine - just stick anything you want in a modules folder, and the CLI will look in that for any modules.

  • in ESP8266
    Avatar for Gordon

    I don't think so unless you can drop the voltage with a diode. LiFePo4 batteries are in the right voltage range though.

    You could always run from the mains, and should be able to connect the USB-TTL converter (just not with the 3.3v supply connected). The only reason I'm less happy about suggesting that is you want to be really careful you don't touch the mains connection.

  • in Pico / Wifi / Original Espruino
    Avatar for Gordon

    The type of quotes shouldn't make a difference - and yes, 85k would be way too much :)

    The module you seem to be including is only 20k, but even so it seems like a lot. It also appears to use XMLHttpRequest, which is a browser API - so it seems unlikely it'd work. There is a REST API (https://www.pubnub.com/docs/pubnub-rest-­api-documentation) so especially if you were just publishing it should be quite straightforward.

    But if they have an MQTT option, I'd totally suggest using that. It's a lot more standard and the MQTT module is now pretty well tested.

  • in ESP8266
    Avatar for Gordon

    Maybe just try unplugging the USB-TTL completely and plug the Sonoff into the mains? You should be able to see it appear as a new ESPsomething access point if it's working.

    It's highly likely that your USB-TTL converter won't supply enough power on the 3.3v line. When I did mine in the video I'd got a beefed up 3.3v regulator added to it.

Actions