Most recent activity
-
As I'm seeing it, this is an STM32 F4, with the Marvell module on the breakout board being specifically for wifi.
Maybe there's a significant difference between that and the other STM32 chips Espruino is already running on?
-
4MB flash, 512KB RAM, Broadcom wifi. 200MHz. This looks like a real beast of a $15 unit.
-
Does this version have dummy-proofing power protection against ground shorts?
-
Kudos for such great functionality crammed onto such a small PCB.
I guess it wouldn't be feasible to put the low-profile main processor on the back, with the ESP8266 on the top side - not that it would really make the board surface-mountable, unless a depression (not quite a hole) was carved for the STM to nest into to the "host" PCB. ??
-
Key shortcut for saving to hardware would be nice too
-
Neil, I'd figure there'd be a driver, at least architecturally. It sort of sounds like you might be wishing for wifiDriverX, Y and Z to each provide a standard wifi interface, so that you don't have to care what driver is in play - just call wifi.connectAP() or some such. You could write such a driver layer, with each function implemented in terms of the respective wifi libs, but more layers don't come for free.
Speaking of native ESP8266 coding, I've been playing with Lua on the ESP8266, which is interesting, but it's not Javascript. The especially interesting part for me is how the ESP8266 SDK (which enables application code to run on the same hardware being used for networking) is mapped onto the Lua runtime: C functions, registered with the SDK for specific events, calling into the Lua code through the standard Lua C API.
Within this SDK framework, the SDK (not an OS) takes a turn processing network traffic, then calls into your application, where you take a turn doing stuff with pins and lights, say. 6 alarms are built in at some level, though I'd expect you only need two and a setTimeout data structure (that's the purpose of the alarms). Pin-triggered interrupt(s), etc... All analogous to how we arrange event-oriented programs on Espruino.
All very encouraging in terms of making Espruino run there. Yielding to the SDK in the JS event loop is key.
One downside of the CPU-sharing for the developer is that if your event-handler does very much work, you run the risk of interfering with network operation. That's where I'm actually quite keen on Espruino, in that you can easily optimize those particular time-sensitive functions with pre-compilation. Maybe nodemcu has an option for that too, but I haven't found such a thing.
-
- 7 comments
- 3,430 views
-
Yeah, I get it. So docs it is.
Experienced web developer, in-depth JS experience. Small level of hardware experience.