Most recent activity
-
The web service idea works fairly well and is what I did for my talk in Paris
. It's also how all the IoT startups are doing it, but I suspect this is partially so they have a service to sell and some degree of control.I don't like that it depends on active internet which is often a problem for my use cases (hacking while commuting/traveling). Also it's a pain to switch the microcontroller to a new wifi network when you change locations.
With AP that serves websockets, a webpage can connect and configure the device to use the local wifi or simply stay in AP mode if the programmer doesn't need or have internet.
You probably don't want to do the server in JavaScript. My experience doing this with nodemcu is it's too heavy for the poor little ESP8266. Making a minimal server that does just enough HTTP to perform a websocket handshake won't be too hard. It could also serve a minimal http page that bootstrapped the full IDE from the net and cached the resources locally in the browser so the IDE could work offline, but without the chip hosting all the content.
Anyway, I'm currently working on the offline-first web IDE platform and will happily bring over the tech once I've worked out the kinks. I might just give up on making my own langauge and use espruino since it's so nice.
-
Yeah, I imagine the idea that someone might actually want access to something in the real world didn't occur to Chrome's management at all :(
Actually I was one of the main people pushing for access to the local filesystem in chrome apps and got the API added. There were people in product management that explicitly were opposed to this because it's not the direction they wanted to go with ChromeOS. It allows too much offline autonomy. I thought I had won the war when we got is pushed through and Google would have to support the API forever, but I guess they showed me.
Generally speaking, Google engineers are amazing people who do amazing work, but their management sometimes shuts down good ideas if it doesn't line up with the company's product vision. (Which to be fair is their job.) We only get upset and angry when we forget that we developers aren't their stakeholders and they do something not in our best interest.
-
As far as local TCP, I've been working hard on integrating web socket server in the esp8266. It's a fairly simple protocol on top of the initial HTTP handshake and browsers can connect to it no problem. I could help code up support if you wanted to head that direction.
-
Hmm, not sure what's up. When I use my full program it does work. See for comparison.
https://gist.github.com/creationix/a7f161ffc53d6b6921bde387b830785c -
I'm trying again today. I've got what I think is the latest firmware (espruino_1v85.tve_master_66fde09_esp8266) flashed onto my brand new Wio Link (esp-12-ish). The repl works great over serial (much nicer than nodemcu's raw repl).
The wio link deluxe kit comes with a neopixel strip. It works great using their provided software (HTTP based interface), now I'm trying the same hardware using espruino.
No matter what I do, the pixels don't light up.
esp = require('ESP8266'); pinMode(D14, 'output'); esp.neopixelWrite(D14,[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]); -
With this latest build, I can't get my chip to boot. It is stuck in a reboot look with the message
Invalid saved code in flash!I'm using an Adafruit feather esp8266 (ESP-12mod) and using the esp-12 settings in the README.
-
Also I just noticed that the
save()command doesn't preserve the CPU speed. As a workaround, I added an onInit function to set it on 80Mhz before saving my state. -
I've got a ton of different neopixels from Adafruit for testing (including the new GRBW variants). I can get them to work on my ESP8266 as long as I knock the CPU freq down to 80Mhz. As I helped with neopixel support on nodemcu and am adding support on my own platform for esp8266, I can help with updating the code here if someone would direct me to the right place.
Also a suggestion. I bought one real espruino board (the pico) and using the SPI method I can mix GRB neopixels and GRBW neopixels just fine on the same pin. I just need need proper byte offsets in my logic. But using the esp.neopixelWrite command, I'm restricted to multiples of 3 bytes which is wrong once the 4-bytes-per-pixel GRBW hardware is introduced. We should remove that constraint.
I should mention that a local web server that serves the website as well as listening for tcp connections works well, but then you're back to needing a local native app (chrome app for ChromeOS or something else for everything else), but perhaps a minimal node server installed via npm is easier than a full on electron app.