HOWTO: Running Espruino on the EFM32

Posted on
  • Thought I'd do a quick write-up on how to get Espruino up running on the EFM32:

    So, after a couple of nights I got the basic support running. It supports timekeeping in EM2, wake-ups from EM2 and basic flashing and communication. If you want to try it out, download the attached binary and flash it on your Giant Gecko starter kit. Then open the web IDE and connect to the COM-port of the kit.

    If you want some simple examples, you can for example try:

    var state=0;
    
    function led_swap() {
      state = !state;
      LED1.write(state);
    }
    
    setWatch(led_swap, BTN1, {edge:'falling',repeat:true});
    setDeepSleep(true);
    

    Or:

    var Clock = require("clock").Clock;
    var clk = new Clock(2016,0,27,17,0,0,0);
    
    function setLed() {
      LED1.write(clk.getDate().getSeconds() & 0x1);
      LED2.write(clk.getDate().getSeconds() & 0x2);
    }
    
    setInterval(setLed,1000);
    setDeepSleep(true);
    

    If you ever save something to flash (using save()) or send it to EM2 and want to recover the console, just hold down BTN1 (marked as PB0 on the kit) when resetting. There's also a bug that caused the console not to recover after loading from or saving to flash.

    Here's two Energy Profiler shots of the examples above:
    Example 1, You can see it's using about 2.8 uA when waiting for pin-wakeup and the LED consuming ~0.5mA. You can also see that it actually triggers on both edges (rising & falling) with Espruino validating the trigger.

    Example 2:
    Again, you can see normal timekeeping at 2.8 uA, and the LEDs consuming 0.5 mA each..

    If you want to save something with setDeepSleep() I recommend using the below stub to go to deep sleep after 5 secs, so you have enough time to type save() after uploading the code:

    //Go to deep sleep after 5 secs, so we have time to do save()
    setTimeout(function() {setDeepSleep(true)}, 5000);
    

    Lastly, if you want to contribute just get the code from github, there is a Simplicity Studio project located in the targets/efm32 folder. What's currently missing:

    • PWM
    • SPI
    • Analog functionality
    • Serial over USB (Right now it's using the serial over the debug USB-cable. Should move this to the on-chip USB)

    1 Attachment

  • That's great - thanks for all your work on this! Really good to see some Energy Profiler graphs too - is that part of the Gecko starter kit?

    As you saw already, watches trigger on both edges - mainly because it just simplifies things (and it's needed if debouncing is enabled).

    Does the Gecko kit have RTS/CTS on the USB->Serial interface part of it? Potentially we could look at modifying the existing flow control code such that it could work with deep sleep.

    Having said that, right now using it is as simple as:

    setWatch(function(e) {
     CTS.write(e.state);
     setDeepSleep(!e.state);
    }, RTS, { edge:"both", repeat:true });
    
  • The Energy Profiler is included in Simplicity Studio, and yes, it uses the hardware that's on all the Gecko starter kits. While originally only for Gecko devices, you can use it to profile any other device you want.

    No, the USB->Serial is just a plain UART. I think the long term solution is to move it to the in-device USB, not sure if it makes too much sense to spend time on implementing something in-between.

  • Yes, that's what I do on the Pico, and nobody seems too upset about Serial RX not working in deep sleep :)

  • Yup, I do however think that we should find a way of debugging when it actually goes to deepsleep. Not sure how to do that yet, because now the terminal is only available if it doesn't go to deepsleep.

    The way I have it now is actually kind of sweet for that, because it allows me to go to deepsleep and still print stuff whenever I want (it can't accept anything though, just print). For example:

    Also, I updated the timekeeping function, and you can now see that the clock-example is operating much more energy efficiently (spending much less time awake):

  • Great! For the timekeeping, was it just some mismatch between the IRQ produced by the utility timer and the RTC?

  • No, it was just me doing a sloppy integration the first time, with only 1 second resolution on the jshGetRTCSystemTime(). This caused it to wake up, then wait for the 1 second tick, so it could update the LEDs. The time it actually spent awake was highly dependent on the sync between the sleep-timer and the 1 second tick.

    Now that the jshGetRTCSystemTime() has sub-ms resolution it wakes up and immediately sees that it's the time to update the LEDs.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

HOWTO: Running Espruino on the EFM32

Posted by Avatar for LaplaceG @LaplaceG

Actions