-
-
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. ??
-
-
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.
-
-
Sorry if I've missed this detail in existing communication. I'm interested in how variable names are stored (with its data?) and matched from executing code. I'm assuming if Espruino uses a linked list for variables, that a variable name from executing source has to be found in the JsVar structure?
I'm particularly curious about the string-length overheads (on mem & CPU both) during execution of code having variable names, and what optimizations may already be in use or available (e.g. pre-munging var names with Esprima, or ???).
Another angle on optimization (if relevant) is code-path frequency, in that (assuming a given variable name is evaluated faster if shorter), we could rewrite most-commonly-ACCESSED vars with the shortest names (it's hard to think Esprima could help much with that)
Another question has to do with namespacing of vars. It seems to me that an object global.JUNK = { foo: 'bar' } implies a variable 'foo' in JUNK's namespace (yes?) which puts an interesting twist on potentially rewriting 'foo'. Seems like JUNK has a linked list of its properties, but again with the variable-name question.
Finally, if I have obj1 = { foo: "bar" }; obj2 = obj1, then these two variables both point to the same object. Probably the answer about var names will demonstrate how this is implemented too, but if not, that extra info would be interesting too.
Thanks in advance.
R
-
-
-
Back-compat is certainly the sticking point. Doc improvement would certainly help, if nothing else arises - no question. The rest of your logic makes sense also.
Another technique for changing interfaces to existing functionality is to simply make a new version, deprecating the original over time. Could we add PIN.prototype.watch() or PIN.prototype.on() with new behavior, or would that preclude support for signals that aren't PIN's?
Obviously my approach on this is aggressive... with setWatch being such a fundamental technique, I'm highly motivated toward absolute zero on the "surprise" scale. (By the way, thanks so much for your welcoming attitude toward that pushy Randy guy) (also: no, I'm not a farmer).
If can, can. If no can, no can. :)
R
-
Oh, interesting. Thanks for helping enhance my imagination. So by measuring the pulse width, you can get a sense of the signal's "speed" on a pseudo-instantaneous basis. That's cool.
Still, I do feel that the default mode should be more obviously correct, with a mode to measure pulse-width available as a non-default option. +1 on efficiency and memory. Also, the same thing for developer time, if those two aren't in conflict.
What if...
- when edge:rising or edge:falling, default to event-orientation, unrolling the trivial workaround to non-developer responsibility
- when pulseWidth: true, additionally include pulseWidth or lastChangeTime in the event
WDYT?
R
- when edge:rising or edge:falling, default to event-orientation, unrolling the trivial workaround to non-developer responsibility
-
I'm experiencing a usability problem with setWatch, wherein the documented behavior matches reality precisely, but it's not useful to me (I dare say not useful to anyone). I'm exploring possibilities for adjustments toward more practical utility. Scenario:
- setWatch() with edge: 'rising' or 'falling'
- in the event handler, print event.time and event.lastTime
- compare each event's output to the output from the prior event
The result is that each event's 'lastTime' is mismatched with the 'time' of the prior event. With edge: 'both' (default), that's not the case, and the documentation corroborates this evidence; lastTime is NOT the time of the prior triggered event; it's the time of the last-state-change on the pin.
Perhaps it's only my lack of imagination, but I don't see how the time-of-last-state-change is useful to any client code. Time-of-last-event is IMO the only thing that could possibly be sensical from a "serve the client" point of view. A client who wants time-since-state-change can use edge:'both'.
Can we look for a way to fix this, to produce more usability for developers? It could be approached in any number of ways. I'll suggest a few here:
change lastTime to be time-of-last-triggered-event. Not back-compatible.
Add lastEventTime as time-of-last-triggered-event. Heavier, but back-compatible.
Add lastEvent as a reference to the prior-triggered event; client code consults event.lastEvent.time instead of event.lastTime. Increases memory usage by one event per setWatch, but lightens the event structure (especially if lastTime becomes deprecated and then is removed)
I have not tested with noisy inputs, with or without debouncing, being a little bit busy, and a little bit afraid of the result :). Perhaps the debouncing logic holds the key for explaining the current behavior, but I'd be glad to help work out expectations and maybe even some code for it.
@all and @Gordon - your thoughts?
R
- setWatch() with edge: 'rising' or 'falling'
-
@d0773d what hardware have you selected for ec and ph? Also that peristaltic pump? Have you sampled a variety of options and settled into one that you like? or are you still early in the process?
-
-
If it was me, I'd probably put a tone-generator/tuning-reference-pitch sorta app on my phone and put that right next to the mic, to get a fairly constant high-input signal to test with the voltmeter. Realize that the mic has to represent sound waves electrically, so you won't get (average) values in the 9V range.
I'd also probably generate an e.g. 440Hz tone, sample it as fast as possible for around 1s/220 or 5ms using a simple Espruino program (triggering the capture on button press, for example), and examine that data stream, hoping to see it vary through 0.0 - 1.0 (of 3.3V) and back down to 0.0 on a fairly smooth curve, then repeating. I'd spit out that data to the console and plot it on a graph to see things like:
- How much headroom you have (if you don't reach near 1.0) for extra-loud noises,
- Your average voltage, which should correspond to your Voltmeter's reading from the same signal
- Whether you're getting clipping (many samples at ~1.0) to suggest you didn't voltage-divide it sufficiently or that you're just feeding it a signal too close to the mic, and/or
- Whether you're getting any positive bias that prevents you from getting low-range values (at the bottom of the waveform) near 0.0 - a possible source of signal-quality problems.
Once you're able to see some of these attributes in the signals you sample by direct examination, you should then be able to write some logic to process the signal in a way meaningful to your application.
For instance, you could detect a large stream of measurements above a threshold like 0.95 and turn on the LED to indicate clipping. When not clipping, you could detect signals in the 80-95% range and use partial intensity on the LED to indicate the signal strength. Or you-call-it, because I have no idea how you're wanting to use the mic for your project. :)
- How much headroom you have (if you don't reach near 1.0) for extra-loud noises,
-
You want your input to be in the 3.3V range for the Espruino, but your mic wants 4-10V, per the oh-so-detailed specs :). I would compute a voltage-divider for the mic input to bring the signal into your target voltage range.
You could try feeding the mic with 3.3V off the Espruino too, but you'll probably get very poor response from the mic that way.
-
-
Tried all baud rates. Absolutely no response on Serial2.
No LED signal from the ESP-12 (not 100% sure there is an LED, but it's not in front of me ATM). Will check the connections. Was waiting for the resistors and capacitors to arrive but didn't realize I was expecting a light even without them. Thanks for the suggestions.
-
-
I'm no hardware guru, so apologies for the obvious naiveté(s). I'm only a little out on limb, but it's just stuff, so some trial and error is par for the course; I'll come out stronger at the end. Thanks in advance for your forbearance and assistance.
https://github.com/espruino/EspruinoBoard/blob/master/Pico/Adaptors/eagle/esp8266_esp12.brd
I had 3 of these made, and ordered the corresponding esp12's (ESP8266 as SMD board) from Adafruit. In retrospect, the pin version would have been easier for prototyping, but this looks so clean! Anyway: so far, so good. I removed the pins from my pico and got it and the esp12 soldered onto the shim board, woo hoo! Espruino works in the IDE, so I didn't cause any shorts, but no love on access to Serial2 per the guidelines.
Fast forward to morning: It seems on inspection of the Eagle file, that I failed to recognize that there are three 4.7k resistors and a 10µF capacitor that also need to be added in order to complete the design. Yep, there's the pads for them. First: is that correct? Second, how do I know which way to connect the capacitor?
Thanks in advance,
Randy -
-
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?