A simple example of this type of "take everything in one
configure function" implementation is in our LIS3DH driver that exposes its configuration options without regard to where on the device they actually live. More recent work that I've done for TC53 (driver implementations that are not yet in our public tree, because things are still moving around a bit there) take that a lot further by really exposing every option of the sensor.
For the sake of completing the exercise I was laying out above: yes, I think we can and should do better than simply taking opaque bit masks as the values for configuring sensors. We should, instead, map out what those values actually mean and accept arguments that refer to that instead of the raw register bits.
So, for example, for the
outputDataRate property described above, it doesn't just mean 0x0 to 0x7. It means something like this:
So, in my opinion, it would be better for the
outputDataRate property of the options object to take the values 0, 14.9, 59.5, 119, 238, 476, and 952 instead of the values 0b000 to 0b110.
What's new in Johnny-Five land, @dtex ? Anything exciting coming down the pipeline?
Refactor = modernized the code base
I see that J5e is on npm now! Exciting stuff; it's great to see the TC53 work having practical applications beyond our stack.
Alright, I'm going to call it a day here. Thank you for chatting, Donovan, and thank you to all the lurkers for stopping by to see what we're up to!
Our next office hour will be in a week or so. But please leave any questions, comments, or puzzles here in the meantime: a member of the Moddable team will get back to you in short order, even when we're not holding office hours. Cheers!
I'm here for an interview about the Metadata API.
a while ago. Please did you not receive my text?
@meganetaaan and @PrototypingAndy_twitter -- Can you confirm this issue is fixed and close it out? Thanks! Moddable-OpenSource/moddable#388
Hi, I recently bought a moddable two and three, and I have some issues with the wifi on Three, is this a good forum? Basically I can't connect nor scan, examples/network/wifi/wifiscan just yields "Scan start" on the Three while it works fine on Two.
I'm running mcconfig as mcconfig -d -m -p esp/moddable_three and mcconfig -d -m -p esp32/moddable_two respectively.
The Wi-Fi scan and Wi-Fi connect process is the same on both Moddable Two and Moddable Three. I'll check here now with a Moddable Three to confirm that it is work as expected with the current software.
(...with ssid and password added for httpget .)
Just to try one other use of Wi-Fi, you might try running $MODDABLE/examples/network/wifi/wifiaccesspoint to see if the access point is visible. From your other results, it seems unlikely.
@phoddie @PrototypingAndy_twitter Sorry to be late! Yes I tried this fix (Moddable-OpenSource/moddable#388) and it worked like a charm! Thank you!
I'm also late for responding Josue's last questions. I think I gonna make response tomorrow.
I've noticed that not all the class is typed, seeing definition files (https://github.com/Moddable-OpenSource/moddable/tree/public/typings)
I will try to integrate my own .d.ts to yours
https://github.com/meganetaaan/types-moddable/tree/master/types
I will try to integrate my own .d.ts to yours
https://github.com/meganetaaan/types-moddable/tree/master/types
Thanks for looking at our TypeScript integration. It is definitely not complete, but a starting point. @bmeck generously provided .d.ts files for about 30 of the built-in modules. That was a huge effort and a great starting point. There is more to do. Integrating your VERY IMPRESSIVE (!!) suite of definition files would certainly be another big leap forward.
That you can sometimes see the access point, but not reliably, seems consistent with your other results. Something isn't working with Wi-FI. I assume the PCB trace antenna looks OK and you aren't running the test in a Faraday cage.
It may be just be a bad ESP8266 module. That's exceedingly rare, but possible. We should probably just ship you a replacement Moddable Three.