by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andy Carle
    @PrototypingAndy_twitter
    Note that the code overhead on the driver side is minimal due to convenient language features like object destructuring. On the driver side you can simply unpack the object right in the function parameter, if you want to: configureGyroControlRegister1({outputDataRate, fullScale, bandwidth}). Fancy, indeed.
    So, now we have code that is readable with respect to what parameters of the sensor are being configured by a call to configureGyroControlRegister1. But the values themselves are still opaque numbers/bit masks. Can we do better?
    Donovan Buck
    @dtex
    Have you looked at options where driver users don't need to know anything about which register location each feature belongs in? More code, but much more intuitive. Maybe some kind of shorthand lookup table that maps features by name to register locations?
    Andy Carle
    @PrototypingAndy_twitter
    Hi Donovan! Good to see you.
    Donovan Buck
    @dtex
    Hi! I wanted to check out the office hour.
    I hope all is well.
    Andy Carle
    @PrototypingAndy_twitter
    Still mostly on lockdown out here. But the weather is beautiful and I'm healthy. Can't complain too much. :)
    I hope things are starting to turn the corner for the better in Texas.
    As to your question above, yes, very much so. I'm using configureGyroControlRegister1 as an example here to simplify the space that we have to consider down to one register. But I would not recommend doing this in a real driver implementation. In both the Moddable SDK and our work at TC53, we combine all of the configuration options into one generic configure(options) function that takes a single, potentially large options object and performs all of the configuration for the sensor.
    Donovan Buck
    @dtex
    Same. Worse every day. We're locked in competition with Florida for worst possible response to a pandemic. They've got us by a nose at the moment, but there's still time.
    Andy Carle
    @PrototypingAndy_twitter
    Yeah... these are not the best of times.
    Donovan Buck
    @dtex
    Ah cool. That's of course how it's done over in Johnny-Five as well. TBH we almost never expose all the options. We set defaults for many things, but our focus is to make it easy, not necessarily make it work for any possible configuration.
    Andy Carle
    @PrototypingAndy_twitter
    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:
    image.png
    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.
    Andy Carle
    @PrototypingAndy_twitter
    That produces client code that looks like: configureGyroControlRegister1 ({ outputDataRate: 59.5, fullScale: 2000, bandwidth: 0 }); which I find a whole lot more readable than just configureGyroControlRegister1 (0x02, 0x03, 0x00);.
    What's new in Johnny-Five land, @dtex ? Anything exciting coming down the pipeline?
    Donovan Buck
    @dtex
    That's very similar to a J5 style device driver. Rick refactored the whole darn thing recently. My focus has been on J5e (writing tests and fixing bugs this week).
    Refactor = modernized the code base
    Andy Carle
    @PrototypingAndy_twitter
    Very cool. I should go check out what Rick has been up to.
    I see that J5e is on npm now! Exciting stuff; it's great to see the TC53 work having practical applications beyond our stack.
    Donovan Buck
    @dtex
    Ya, it's worked out really well.
    Andy Carle
    @PrototypingAndy_twitter

    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!

    Donovan Buck
    @dtex
    Adios, stay safe
    Andy Carle
    @PrototypingAndy_twitter
    You too!
    Shinya Ishikawa
    @meganetaaan
    Hello!
    I'm here for an interview about the Metadata API.
    Shinya Ishikawa
    @meganetaaan
    Is Josué here? My schedule is open for about an hour and a half after this, so please let me know when it's convenient for you.
    Josué K
    @eusojk
    Hello @meganetaaan. I texted you privately
    a while ago. Please did you not receive my text?
    Shinya Ishikawa
    @meganetaaan
    I got your message! thanks.
    Peter Hoddie
    @phoddie
    (@meganetaaan - thank you for helping out @eusojk!)
    Shinya Ishikawa
    @meganetaaan
    :+1:
    Andy Carle
    @PrototypingAndy_twitter
    @meganetaaan Yes, thank you! Also, my next door neighbor just gave me a funny look because I was mindlessly playing with Bongo Cat on an M5Stack Fire while sitting in the backyard. :)
    Peter Hoddie
    @phoddie
    @meganetaaan and @PrototypingAndy_twitter -- Can you confirm this issue is fixed and close it out? Thanks! Moddable-OpenSource/moddable#388
    Andy Carle
    @PrototypingAndy_twitter
    It's definitely fixed for me, but I'd love to get independent confirmation from @meganetaaan. I'll close the issue out tomorrow if we don't hear back.
    Per Modin
    @pmodin

    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.

    Peter Hoddie
    @phoddie
    Hello @pmodin. Yes, this is a good place to ask.
    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.
    Peter Hoddie
    @phoddie
    I just ran $MODDABLE/examples/network/wifi/wifiscan and $MODDABLE/examples/network/http/httpget on a Moddable Three. They work as expected. I used the same mcconfigcommand line as you show above.
    (...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.
    Shinya Ishikawa
    @meganetaaan
    @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.
    Shinya Ishikawa
    @meganetaaan
    By the way I'm interested in the recent update of experimental support for TypeScript.I would be love to contribute them.
    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
    Peter Hoddie
    @phoddie
    @meganetaaan - glad to know that the audio fix is working for you. It strange that the IDF update caused that problem to happen. I hope it stays fixed. ;)
    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.