Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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.
    Shinya Ishikawa
    @meganetaaan
    Yeah thank you so much @bmeck !! I know maintaining type definitions is tough. But I would love to help you.
    Per Modin
    @pmodin
    @phoddie thanks, I just tried the AP and while it runs fine on Two, with Three I get below output. It sometimes shows the AP but I've not been able to connect, seems it's flapping. Any advice?
    No Wi-Fi SSID
    http server ready at 192.168.4.1
    Peter Hoddie
    @phoddie
    That looks correct -- the access point example creates a trivial HTTP server and traces out the address where it can be reached.
    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.
    Per Modin
    @pmodin

    @phoddie crap, I was hoping it was a software error but I agree that it seems possible that the hw are to blame. I've an email adress to chris@ on my receipt, should I email there or should I send you the paypal tx id?

    Many thanks for the swift support! Much appreciated!

    Per Modin
    @pmodin
    Those assumptions are sane btw :D I see no bad solders or anything that looks damaged on the board
    Peter Hoddie
    @phoddie
    @pmodin - You don't need to do anything. We've put a replacement unit in the mail. Please let me know how it goes when that arrives.
    Per Modin
    @pmodin
    Oh wow, thank you @phoddie ! Will do!
    Shinya Ishikawa
    @meganetaaan
    Hello! One piece of good news. The commercial edition of my fanzine "実践Moddable(Moddable in practice)" has been published and is now available on Amazon and many other ebook sites. I believe this book will help to spread Moddable to more Japanese engineers.
    https://nextpublishing.jp/book/12230.html
    Peter Hoddie
    @phoddie
    Congratulations! It looks great. I'm sure it will help many developers.
    Jan Van Braeckel
    @janvbraeckel_twitter
    Hi all, been playing around with the moddable sdk recently and I must say it works great
    I come from a web development background and have tried to program some ESP8266 in the past with c++, and it definitely hurt my development speed/sanity, since I don't really know c++
    One thing I was wondering about the moddable SDK is OTA updating. I saw there is esp32 support, but didn't find anything similar for the esp8266. How would one go about integrating OTA for the esp8266 with moddable?
    Jan Van Braeckel
    @janvbraeckel_twitter
    I've tried including the ArduinoOTA.h via the makefile for the esp8266 and making an xs in c bridge, but of course there are other esp8266 arduino core headers missing. Should I try to make the ArduinoOTA work or would it be more efficient to try and implement ota myself in c?
    Peter Hoddie
    @phoddie
    Jan, good to hear from you. And very glad that the Moddable SDK is working well for you!
    You are correct that there is no OTA module for ESP8266. That's long been on my to-do list. ;)
    Both approaches you described could work -- using the ArduinoOTA code or implementing it yourself. The Arduino code is generally quite good, but... it often relies on a lot of the Arduino infrastructure which pulls in lot of other code. With the limited flash space (1 NB) for code on ESEP8266, that's a problem.
    It should be possible to replicate that functionality, however. You could do it in C. You could also do it in JavaScript. The flash module ($MODDABLE/modules/files/flash) supports read/write/erase to the full flash range.
    Given your web background, implementing it in JavaScript is probably more comfortable too.
    Peter Hoddie
    @phoddie
    If you decide to explore that, let me know. I'd really like to see OTA in the Moddable SDK for ESP8266, so I'm happy to try to support that effort.
    Jan Van Braeckel
    @janvbraeckel_twitter
    Alright, I'll try to give that a go in the near future, thanks for the pointers!
    I see here you talked about creating a partitions.csv: Moddable-OpenSource/moddable#157
    In the past I've used an ldscript to maximize flash storage size: https://github.com/esp8266/Arduino/blob/master/tools/sdk/ld/eagle.flash.1m.ld
    Would using that ldscript be sufficient, or does the Moddable SDK expect the partitions.csv file to indicate 2 different partitions for OTA? I see only the ESP32 has a default partitions.csv
    Peter Hoddie
    @phoddie
    The ESP8266 does not have a formal partition map like ESP32. It is much more basic. The linker script for ESP8266 defines the areas for the firmware image and Moddable SDK preferences. The space left over is reserved for SPIFFS. The firmware image is basically maxed out. Here's the room of the linker script: https://github.com/Moddable-OpenSource/moddable/blob/public/build/devices/esp/sdk/ld/eagle.flash.4m.ld
    To implement OTA, the first step is to reserve another 1 MB of space for the alternate image. That requires moving preferences and SPIFFS. Using the HTTP and flash modules, you can download a new image to the partition that isn't currently running. Then... somehow (and I haven't looked at this in a while) you set some bits in flash to tell the bootloader to start using the new image on the next restart.
    Jan Van Braeckel
    @janvbraeckel_twitter
    Alright makes sense 😁
    So a device with 1MB storage would be too little? That would give +- 500kb sketch size
    Peter Hoddie
    @phoddie
    1 MB total would be pretty tight. On an ESP8266, hello world builds to (very roughly) 400 KB. That includes contributions from XS (JavaScript engine), the Moddable SDK, the Arduino implementation, and Espressif libraries (mostly Wi-Fi). With some dedication, that can be reduced. But... a device with 2 MB storage would be much better (most ESP8266 boards have 4 MB, though not the ones that use the 8285 module). More than 2 MB doesn't change much, because of the 1 MB limit on ESP8266 for memory mapping flash.
    Jan Van Braeckel
    @janvbraeckel_twitter
    Alright good to know, thanks!
    Peter Hoddie
    @phoddie
    @meganetaaan - If the Twitter Translate feature can be trusted, it seems like you might be looking into an issue with audio playback on ESP32 / M5 Something devices. Please let me know if I can help. The audio output code has changed a bit recently, but the last change that seems relevant is back in July.
    Peter Hoddie
    @phoddie
    We added Release Notes for all the Moddable SDK updates for the last few weeks. Is this sort of thing useful moving forward? Any suggestions about how to make them more useful?
    3 replies
    Shinya Ishikawa
    @meganetaaan
    @phoddie Thank you for helping! Yes I got an issue on the combination of M5Stack family and piuSound module.
    • sound#play does not play the sound
    • startup sound seems to play normally(via audioOut)
    • After calling sound#play several times an exception occurs
      /home/ishikawa/Projects/moddable/modules/pins/i2s/audioout.c (547) # Break: (host): queue full!
    I saw this error in the piu/sound example built with esp32/m5stack_fire target.
    I gonna open an issue after work
    Peter Hoddie
    @phoddie
    OK, thanks. I have an M5Stack Fire at the office. I can look into your report then.
    It is a good sign that the start-up sound plays. Maybe it is just a change in the setup code that is getting in the way.
    Peter Hoddie
    @phoddie

    I'm able to reproduce the problem using the Piu sound example. I'm not certain, but it looks the problem was triggered by the change to enable dual-core by default which changed the timing.

    The start-up sound works. It takes these steps:

    1. Create the audio output instance
    2. Queue the audio sample to play
    3. Start the audio output

    Piu does things a bit differently:

    1. Create the audio output instance
    2. Start the audio output
    3. Queue the audio sample to play

    Both are valid. If audio is started and no samples are available, the output is silent. On ESP32 the silent idle state is implemented by waiting for a notification using the FreeRTOS xTaskNotifyWait API. This is efficient, as the task uses no CPU cycles while it has nothing to do.

    But, when audio samples became available while idle. there was no notification to the playback task. So, it remained waiting forever. The fix is pretty simple. In xs_audioout_enqueue, remember the number of active streams at the start (immediately before xsmcVars(1):

        int activeStreamCount = out->activeStreamCount;

    At the very end of the same function, add the following to awaken the playback task:

        if (out->activeStreamCount != activeStreamCount) {
            uint8_t started = 0 == activeStreamCount;
            if (started) {
    #if ESP32
                xTaskNotify(out->task, kStatePlaying, eSetValueWithOverwrite);
    #endif
    
            }
        }

    An audio stream can be inactive because it has no samples to play or because its volume is set to 0. This change catches both. (It seems possible other device platforms may require a similar notification in the future, so I organized this code to make that convenient.)

    Before committing this, I'd appreciate some independent confirmation that it works. @meganetaaan, would you give it a try with your app? Thank you!

    Shinya Ishikawa
    @meganetaaan
    @phoddie Thank you!
    I tried the fix above. The sounds plays but after calling sound#play 8 times the same "queue full!" error occurs. Thinking elementCount is not properly decremented when playing sound finishes at endOfElement.
    Peter Hoddie
    @phoddie
    Thanks for checking. I thought I tested playing back of many sounds, but I will double check. To be certain we are looking at the same thing, are you using the Piu sound example or something else?
    Shinya Ishikawa
    @meganetaaan
    Sorry, that was my mistake. I did not revert my modification of piuSound.js. I applied exactly only above change and it worked!
    Thank you for your prompt response.
    Peter Hoddie
    @phoddie
    No problem. Happy to know it works. I'll commit that. Thanks again for the help.
    Peter Hoddie
    @phoddie

    FYI - if you have updated in the last day or so, you may have noticed an additional line in the output of your builds that gives counts for instances, keys, colors, and holes:

    # xsl modules
    ### 206 instances, 491 keys, 63 colors, 0 holes
    # cc mc.xs.c
    # ld mc.so

    This is the output of a new optimization phase in the XS Linker. For builds that use the preload feature, XS is able to optimize the look-up of properties of objects in ROM. Property look-up is a classic bottleneck in implementing JavaScript. XS applies a well known technique called Graph Coloring to do this and the new output line summarizes the results. Usually Moddable SDK projects report zero holes. We almost never see otherwise. If you happen to run a project that shows a non-zero number of holes., we'd like to hear about it. The ROM Colors document explains more about the XS implementation of Graph Coloring and links to the original article.