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
    Imagine you were writing a JavaScript driver for the LSM9DS1 and (in a slight simplification of reality) that you were adding a function to your API design called configureGyroControlRegister1 to set the contents of this register. How would you design the function signature (so to speak) of configureGyroControlRegister1? What arguments would it take and how would they be interpreted by the function to go and make the proper changes on the hardware?
    The most obvious answer (and the answer chosen by many driver implementations in C) would be to do something like configureGyroControlRegister1(value) where value should be a Number between 0x00 and 0xFF. After all, this would allow the developer using your API to set all possible configurations of this register. This design would be quite straightforward.
    Andy Carle
    @PrototypingAndy_twitter
    But, "easy to implement" and "easy to use" do not always travel together. To use this design, the application (or framework) developer would absolutely have to dive into the data sheet for the LSM9DS1 to figure out what the various values that can go into this register mean. And this design would be extremely error-prone. A value like 0xF1 doesn't really mean anything and does not parse well to the human eye while reviewing code. The client developer could do better by using bit mask constants and bitwise operations to combine them. But it would still be messy to read, and at best this is shifting the responsibility for making the driver usable from the driver developer to the driver consumer. Not good!
    Andy Carle
    @PrototypingAndy_twitter
    So, how can we do better? A first crack at this might be to at least split up the three distinct options that can be set into three distinct arguments to the function. Perhaps something like configureGyroControlRegister1(outputDataRate, fullScale, bandwidth) where each provided argument must be a number between 0 and (2^n)-1 based on how many bits long the corresponding field in the register is. So, an application might call it like configureGyroControlRegister1(0x05, 0x01, 0x00).
    Andy Carle
    @PrototypingAndy_twitter
    The first thing to notice here is that C-style argument lists to functions are terribly fragile and difficult to read in client code. If the driver developer decides down the road to add more arguments to this function or to reorder the arguments, client code will break. This is seen as part of doing business in C. But we can do better in JavaScript! An easy improvement here is to drop the three separate arguments idea and instead use an options object: an object with well-known named properties that can be pulled out of the object for use by the function. On the driver side that would look like this: configureGyroControlRegister1(options) and on the client side it would look like this: configureGyroControlRegister1({outputDataRate: 0x05, fullScale: 0x01, bandwidth: 0x00}). A simple use of basic JavaScript language features to make an API more usable!
    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.
    Andy Carle
    @PrototypingAndy_twitter
    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!