Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Daniel Ashcraft
    @dashcraft
    Wow!
    Chris
    @cmidgley
    I'm glad to share the source but I don't think it will be in PR-ready condition. Done right, it should abstract away the hardware specifics from the LoRa interface (much like how SPI works) but right now it's really bringing forward the unique needs of the SX1278 chip. Plus I didn't attempt to create a full interface of all features - I implemented only the features that my project needs. When I get it cleaned up, I'll send a link to the source and you can let me know what you want to do with it (if anything).
    Peter Hoddie
    @phoddie
    That would be great, thanks. I can imagine implementing the whole thing is a non-trivial project. FWIW - there's a very deliberate API style in Ecma-419 for IO and peripherals. That might be interesting to apply here to abstract away those hardware specifics.
    Chris
    @cmidgley
    I wouldn't say I fully grok the Ecma-419 style, but did spend some time there to get a basic feel (and to consume the interfaces for Digital and SPI). Since this chip lives on SPI (perhaps others don't?) I wasn't clear if that meant it should have SPI instantiated outside of the LoRa object, or have the SPI pins/mode/etc passed in the dictionary on the constructor and then have the LoRa class instantiate SPI. I assumed you would just extend that dictionary for device specific features - in this case, frequency, bandwidth, coding rate, CRC, implicit/explicit, etc? Didn't see any naming standards or rules for custom extensions to that dictionary. Similar with adding methods that are unique to the class - such as getting the signal-to-noise ratio (SNR) or live changing a parameter that was specified in the constructor dictionary. Sufficient questions / lack of understanding that I didn't attempt to directly model it. Doesn't seem too difficult to fit into the model once those style issues are resolved, but as always the devil is in the details.
    Chris
    @cmidgley
    Here is the code. It's not fully tested, but I did implement all the core chip features (even though I said I wasn't going to!) and it's working well for me sending/receiving packets. No interrupts yet, so it can block (especially on transmit) for up to 400ms (LoRa is slow...) to send a packet. Likewise reads need to poll received()to see if a packet is waiting (then receive_packet will be quite fast as it reads from a FIFO on the chip). You will see in there a TODO comment on the SPI config about Port - I wasn't clear as some code sets port to "VSPI" or "HSPI" but other code samples use "0" and "1". Not sure what that value really means yet, especially since I set the pins. Also if you look at the constructor, you will see I had issues with SPI automatically managing the CS pin, and had to remove it from SPI and do it myself.
    Chris
    @cmidgley
    FYI - interesting side effect of running two ESP32 on xsbug (via two instances of serial2xsbug)... a breakpoint set on one machine is also set on the other. Doesn't appear you can isolate breakpoints across machines. Perhaps a preferences feature to consider? Also, at least on Windows with a trackpad, I find the mouse drops to a crawl (and is difficult to navigate) when hovering on the source pane. Otherwise it's fine. Not sure what's up with that!
    Peter Hoddie
    @phoddie
    Right -- I didn't mean to suggest you should try to apply the Ecma-419 style. It won't help your immediate needs. But it could be a good way to package this eventually. I'll take a look at the code (thanks for posting!).
    The values of the SPI port specifier depend on the host MCU. There's no way to standardize those across silicon.
    Often SPI manages CS in a way you don't want. It is pretty common to have to do that yourself to satisfy the peripheral hardware. SPI isn't really that standard....
    On xsbug, having the breakpoints apply across machines is a bug or a feature depending on your situation. It is also how xsbug maintains breakpoints across sessions. It could be possible to support breakpoints by machine, but restoring them for the next session then gets complicated because the VM don't have a persistent unique identifier that can be used to re-apply the correct breakpoints.
    Peter Hoddie
    @phoddie
    Not sure about the Windows performance (I seldom use it...). Is it possible you have a lot of traces going by that are bogging things down? @PrototypingAndy_twitter - do you see the performance problem @cmidgley describes?
    Peter Hoddie
    @phoddie
    Reading through your code -- cool to see how much of the Arduino code you were able to reuse. On CS, I think the issue is that the LoRa part requires the CS to go inactivate and then active between each transaction, but that isn't the behavior of the SPI class. It just guarantees that CS will be active during a transaction.
    Chris
    @cmidgley
    Thanks for all the info - makes perfect sense. I have interrupts triggering now, but I'm doing refactoring to handle optional async. At the same time I'm restructuring a bit to make it closer to ecma-419. Expect a code update in a while.
    Peter Hoddie
    @phoddie
    (I ordered a couple boards to be able to try this myself eventually.)
    Chris
    @cmidgley
    So from my reading, target (the constructor property) is opaque to the implementation, so I'm free to add members there as needed for the driver, correct? Likewise, I can add device-specific methods as needed (staying within the naming rules) and still be pseudo-ecma-419 compliant?
    Also, I see that many devices define device.io for things like SPI, button, LED, etc. When I run, for example, the io/digital/button example, it fails for both esp32 and esp32/heltec_wifi_kit_32 because it isn't defined. Are those just missing, or do I need to do something to get them for those devices?
    Peter Hoddie
    @phoddie
    Yes, target is just for you. And you can add methods and properties as needed.
    Peter Hoddie
    @phoddie
    The device global is what binds the Ecma-419 APIs to the specific hardware you are running on. It must be provided by the build target. Not all do yet. The ESP32 provider doesn't provide device.pin.button because that isn't defined by ESP32 but by a particular board, like Moddable Two.
    Chris
    @cmidgley
    OK - so the heltec board should have one, but doesn't yet. I'll ignore it for now then.
    Chris
    @cmidgley
    Do you have a 3d printer? I designed a case for them, that also holds the battery if wanted. Glad to share if interested.
    Lora Case
    Peter Hoddie
    @phoddie
    Very nice. I don't have a 3D printer, but I have friends. ;)
    Chris
    @cmidgley
    Here are the files: Heltec V2 Bottom and Heltec V2 Top
    Andy Carle
    @PrototypingAndy_twitter
    Yes, actually, I have noticed some weirdness with xsbug on Windows. That crept in sometime quite recently -- I was blaming a recent video driver update on my machine, but @cmidgley's experience suggests otherwise. I'll see if I can figure out when that started.
    Chris
    @cmidgley
    @PrototypingAndy_twitter I recall this issue when I was using Moddable a year ago ... so not sure it's a new issue. Just FYI. Thx.
    Andy Carle
    @PrototypingAndy_twitter
    Interesting. It definitely hasn't been happening on my machine for more than a couple of weeks. I wonder if something did change on my machine that puts me into that camp now. I'll take a look.
    Andy Carle
    @PrototypingAndy_twitter

    @cmidgley When you get a chance, could you try something for me? I just want to make sure we're looking at the same problem. In %MODDABLE%\tools\xsbug\behaviors.js and %MODDABLE%\tools\xsbug\ConsolePane.js, comment out the lines (three total) that reference application.cursor, then close xsbug and rebuild tools (build.bat).

    The diffs for the changes are:

    $ cd $MODDABLE/tools/xsbug
    
    andyc@ANDY-SURFACE MINGW64 /c/moddable/tools/xsbug (master)
    $ git diff behaviors.js
    diff --git a/tools/xsbug/behaviors.js b/tools/xsbug/behaviors.js
    index e41106e31..4aa9d9f71 100644
    --- a/tools/xsbug/behaviors.js
    +++ b/tools/xsbug/behaviors.js
    @@ -51,7 +51,7 @@ export class ButtonBehavior extends Behavior {
                    this.changeState(container, container.active ? 1 : 0);
            }
            onMouseEntered(container, x, y) {
    -               application.cursor = cursors.arrow;
    +               // application.cursor = cursors.arrow;
                    this.changeState(container, 2);
            }
            onMouseExited(container, x, y) {
    @@ -379,7 +379,7 @@ export class CodeBehavior extends Behavior {
                    return true;
            }
            onMouseEntered(code, x, y) {
    -               application.cursor = cursors.iBeam;
    +               // application.cursor = cursors.iBeam;
            }
            onReveal(code) {
                    this.getScroller(code).reveal(code.selectionBounds);
    
    andyc@ANDY-SURFACE MINGW64 /c/moddable/tools/xsbug (master)
    $ git diff ConsolePane.js
    diff --git a/tools/xsbug/ConsolePane.js b/tools/xsbug/ConsolePane.js
    index 12daa115d..899c9bbc7 100644
    --- a/tools/xsbug/ConsolePane.js
    +++ b/tools/xsbug/ConsolePane.js
    @@ -108,7 +108,7 @@ class ConsoleCodeBehavior extends CodeBehavior {
                    let bounds = code.bounds;
                    let offset = code.findLineBreak(code.hitOffset(x - bounds.x, y - bounds.y), false);
                    let color = this.colors.find(color => color.offset == offset);
    -               application.cursor = color ? cursors.link :  cursors.iBeam;
    +               // application.cursor = color ? cursors.link :  cursors.iBeam;
            }
            onTouchEnded(code, id, x, y, ticks) {
                    super.onTouchEnded(code, id, x, y, ticks);
    That eliminates the performance problem for me, at the cost of making the cursor not look correct when hovering over text. If it's the same for you, we'll work on sorting out how to fix that without disabling features. :)
    Chris
    @cmidgley
    @PrototypingAndy_twitter That looks like it's it! Nice and smooth.
    Chris
    @cmidgley
    @phoddie I updated the gist with the code. Spent most of today doing a refactor for Ecma-419. Much nicer interface - very easy to use , and the chip is abstracted away from the interface. It also now fully supports interrupts, and will operate async if you supply onReadable / onWritable else will do sync. It's likely ... but no way for me to confirm right now ... that it will work on other processors that have the ST127x chip as it sits on top of SPI and Digital and does nothing otherwise that is platform aware/specific. It's likely I misunderstand 419 so if you see something odd, let me know. Tomorrow I plan on adding a few features I learned the chip can do, but otherwise I think it's pretty complete (though I'm sure there are bugs lurking...)
    You are welcome to use, or not use, the code as you please. The only license restriction I have is from the original author (MIT), two ports back, that has some fragments left but not much from a legal perspective. I'm no attorney, but if there was a desire to change the license, I think we have some leeway (especially since what little code remains is simply implementing against a documented chip interface). Either way, I will be using this for my project.
    Peter Hoddie
    @phoddie
    @cmidgley - that all sounds (really) great. I will take a look this weekend and get back to you.
    Andy Carle
    @PrototypingAndy_twitter
    @cmidgley Thank you for the report! We'll take a look at a real fix for that, but glad to hear that the workaround works as expected.
    Chris
    @cmidgley
    I'm trying to build a mod (mcrun -m -p <myplatform> -o build) but I just want a build without launching tools like xsbug or serial2xsbug. Not using -d at least stops xsbug from launching, and -p stops the simulator from running, but it always launches serial2xsbug. With mcconfig I can use -t build but that isn't available with mcrun. Any recommendations on how to build a mod, without launching the debugger or serial2xsbug? This is for an automated build system that I'm putting together inside Docker.
    Chris
    @cmidgley
    My current idea, which likely will work (not yet tested, but wondering if there is a better one), is to use sed to remove the line referencing SERIAL2XSBUG in makefile:
    mcrun -p <myplatform> -o build
    pushd build/tmp/esp32/release/mod
    sed '/$(SERIAL2XSBUG) $(UPLOAD_PORT) $(DEBUGGER_SPEED) 8N1 -install $(ARCHIVE)/d' makefile >makefile >makefile
    make
    popd
    Chris
    @cmidgley
    Slight update to script... this one is working. Is this the best approach for now?
    rm -rf build
    mkdir build
    mcrun -p esp32/heltec_wifi_kit_32 -o build
    pushd build/tmp/esp32/release/mod
    sed -i '/$(SERIAL2XSBUG) $(UPLOAD_PORT) $(DEBUGGER_SPEED) 8N1 -install $(ARCHIVE)/d' makefile
    make
    popd
    Peter Hoddie
    @phoddie
    For consistency, the right thing would be to implement -d for mcrun. I don't think that should be too difficult (but I'm notorious bad with make scripts). Calling serial2xsbug directly is fine.
    Chris
    @cmidgley
    Do you mean -t? (for -t build)? -d is implemented - to trigger xsbug at least (doesn't do anything else as I can see)

    You may like this... I now have a Google Cloud Run container that has Moddable, with a REST API. You just call the endpoint like this:

    {
        "config": {"mySetting": "one", "anotherSetting": "two"},
        "script": "console.log('test');\nconsole.log('two');"
    }

    And then Cloud Run launches a Docker contains with a REST API that returns something like:

    {
        "compileErrors": [],
        "binary": "AAABxVhTX0EAAAAMVkVSUwsFAAAAAAAYU0lHThJR/B2lKKlari/PPUNF7JQAAAAYQ0hLUwAAAAAAAAAAAAAAAAAAAAAAAAAeTkFNRXRlY2gubW9kZGFibGUuYnVpbGQtMAAAAAAvU1lNQgcAQABsb2cAY29uc29sZQBjb25maWcAZGVmYXVsdABvbmUAdHdvAAAAASxNT0RTAAAAEFBBVEhtb2QueHNiAAAAAEFDT0RFi1cAADEsDACRAgBmAgBCYAEAKMkFdGVzdACpAY+RAgBmAgBCYAEAKMkEdHdvAKkBj0RIj28Ce6FEAAAAElBBVEhjaGVjay54c2IAAAAAVkNPREVXAAAxFAwAmwKjAjgEADEFDADdj0ThAo9ESI9XAAAxBwwAmwKjAkRIj88DAMkKbWMvY29uZmlnAM8EAG8D2c8EAIuLzwQAbwTZbwR7oUQAAAAXUEFUSG1vZC9jb25maWcueHNiAAAAAFRDT0RFi1cAADE0DACbAqMBiI2zAlwCyQl0ZXN0LW9uZQCGBQBvAFwCyQl0ZXN0LXR3bwCGBgBvAN8BNAGPREiPzwQAi4vPBABvBNlvA3uhRAAAAAhSU1JD"
    }

    or in the case of a compile error:

    {
        "compileErrors": [
            "/workspace/builds/build-2/mod.js:2: error: end of file in string!",
            "/workspace/builds/build-2/mod.js:2: error: missing ,!",
            "/workspace/builds/build-2/mod.js:2: error: missing )!"
        ]
    }

    And thanks to Google Run pricing, it costs only $3/month to run 30,000 compiles, complete with geographic distribution (runs closest to the user) and with scale up/down on demand. Pretty cool!

    Blake Burkhart
    @bburky

    I've been enjoying playing with Moddable over the weekend, it seems nice overall. I wanted an easy to use framework to play with the M5Paper I got recently.

    One issue with switching to fast refresh modes like A2, is it the full screen may not be cleared on startup and filled areas are poorly drawn. It was even noticeable on the epaper-flashcards demo, old content from other demos wasn't cleared off the screen.

    I ended up with this code which seems to work well. First, clear the screen. Then draw content on screen with a high quality mode to draw all the UI well. Then defer changing the refresh mode to something like A2 (it must be deferred, or the mode changes before the UI is initially drawn).

    class AppBehavior extends Behavior {
        onDisplaying(application) {
            if (screen.configure && screen.refresh) {
                screen.configure({updateMode: "GC16"}); // Any high quality mode
                screen.refresh();  // Use INIT mode to clear the screen fully (optional, and slow. It causes a double flash, but is needed to clear all ghosting)
                application.defer("finishedOnDisplaying")  // Must be deferred so that the screen can finish drawing
            }
        }
        finishedOnDisplaying() {
            screen.configure({updateMode: "A2"});
        }
    }

    Is this the best way to do this? You may want to update some of the examples to do this if so, this draws with much better quality. Is application.defer() the best way to run something after UI has finished rendering?

    Alternately, something like a "temporarily use this mode for the next update" command could achieve this too, but I couldn't see how to do that.
    Peter Hoddie
    @phoddie
    @bburky - Thanks for giving the Moddable SDK a try. On the M5 Paper unit that I used to implement the ePaper display driver (and that @lprader used to implement the example apps) we didn't see the visual glitch you describe. We do have one report of it happening on a different M5 Paper unit though, so perhaps there is some variation or something we've overlooked. The approach you took looks pretty reasonable as a solution to the problem you describe. The finishedOnDisplaying function should be invoked after both the refresh and first frame update are complete. (The checks for screen.configure and screen.refresh is unnecessary if running on M5 Paper. I'm guessing that's so you can run in the simulator?)
    Blake Burkhart
    @bburky
    Yes that's for the simulator, I think the example code used an if (config.updateMode) check which is about the same.
    Peter Hoddie
    @phoddie
    "temporarily use this mode for the next update" could be done in the IT8951 driver, though that kind of behavior introduces state that could be confusing.
    I'm a few miles away from my M5 Paper device at the moment. I'll try this out when I can. If your approach generates better results, we should update the examples (and perhaps the driver?) to implement your behavior.
    Blake Burkhart
    @bburky

    Agreed. Reusing the application events with onDisplaying() and defer() is pretty easy and works. I don't think it needs to be done at the driver level if this covers all use cases.

    Epaper is just a bit weird, there are times you want fast refresh and times you want high quality. The Moddable app I made over the weekend was a replacement for a horrible phone app that interfaces with a BLE kitchen scale. A2 refresh does a good job of quickly updating the UI with new live data, but I used the high quality mode at startup to draw the main UI crisply.

    Peter Hoddie
    @phoddie
    Yea, every ePaper display has its own special behavior. It is always a bit of challege, though the results often look really great.
    Cool that you were able to get BLE + Piu working together on M5 Paper. Please consider sharing a video, if not the code. I suspect a lot of people could learn from that.
    Blake Burkhart
    @bburky
    I'll think about it, so far I just got the BLE connection and really really simple UI. Needs a few more features, then I'll post it somewhere.
    Peter Hoddie
    @phoddie
    Cool.