Avatar for Kolban


Member since Aug 2015 • Last active Jan 2017
  • 38 conversations

Neil Kolban. Keen on all things ESP8266 at the moment.

Most recent activity

  • in Projects
    Avatar for Kolban

    Howdy ... I'm in Fort Worth (about 45 mins away). I'm a huge fan of Espruino and did some work on the ESP8266 port and am working with others on the ESP32 port. Feel free to drop me a line at kolban1@kolban.com if you want to shoot the breeze. There is also a great chat room at https://gitter.im/espruino/Espruino for Espruino in general and https://gitter.im/espruino/esp32 for technical chatter on Espruino being ported to ESP32.

  • in General
    Avatar for Kolban

    The use case that I'm working on is the notion of bootstrapping network connectivity of an Espruino device. Imagine I have an Espruino device which I take with me to my friends house. He has WiFi and is willing to let me have his SSID and password. However, my Espruino has no screen or input source to allow me to enter that information so it can connect to his WiFi. So when Espruino starts, it looks at the list of found SSIDs, realizes that it doesn't know how to connect to any of them and then the Espruino becomes an access point.

    Now .. on my phone, I see the Espruino as a target table access point. I connect my phone to the Espruino and then bring up a browser (on my phone). I am presented with the list of found access points ... I select the one I want to use and enter the password. That is transmitted to the Espruino which says "thank you very much" and now stops being an access point and becomes a station.

    All good ...

    However, I am trying to think of objections folks may have to that technique (also looking for better techniques myself). One is that the password for the WiFi flows over a network to the Espruino so that it can login. I was thinking that if the browser (on the phone) made an SSL connection to Espruino, there would be an ounce more security. I don't know if WiFi traffic is already encrypted (I would guess not). In principle one could then packet sniff and see the password flowing in the clear between my browser and my Espruino. If the Espruino had HTTPS support, that issue would appear to be moot.

    Again ... so far this is all a theoretical story ... but it got me curious about what if anything in Espruino might be presented for server side SSL. I had failed to note that outbound SSL was baked into Espruino and was delighted when it "just worked".

  • in General
    Avatar for Kolban

    Does anyone know if it is possible to setup an HTTP server on Espruino that listens using SSL? I.e. serves up HTTP traffic for requests that start "https" such that the content is encrypted during transport?

  • in ESP32
    Avatar for Kolban

    Status: SPI support is now available and I2C should be right behind it as the puzzles are now resolved. Note that the build instructions changed a tad to get the libraries correct for SPI and I2C. Espressif has released the news that their formal SDK at the 1.0 release will be available at the start of December at which time we will have all the proper libraries that we need to complete the build out. Until then we are using libraries that "work" but which aren't final.

    My 2 cents opinion on multi-threading in JavaScript is ... well ... not to do it. The dual core that is now the ESP32 is primarily one core for the app and one core for networking (Wifi and/or Bluetooth). This allows us to dedicate a core to the app without ANY worry about starving the networking. This dramatically simplified Espruino builds because we can now use FreeRTOS and berkley sockets. As for trying to leverage both cores of the ESP32 for Espruino ... I personally don't see a need. One core for Espruino (the app) and one core for ESP32 networking feels right. That said, I am always open to listening to discussions and if anyone can put forward a cogent reason for using the 2nd core for Espruino work ... I'm all ears.

  • in ESP8266
    Avatar for Kolban

    Looking at the source code, it doesn't appear to be implemented. This is where it should be:


    It doesn't look horribly complicated to add. It seems that we would have to add a new property to the configuration of the parameters as an access point. From what I can see, the ESP8266 API does support the functional capability so really what would be required would be exposing that through Espruino.