Pico hardware questions

Posted on
  • Hi, I saw the Pico on Adafruit recently and it looks great! A few questions that I couldn't figure out from the blurbs and this board so far:

    1) Does the Pico have an RTC that can be accessed through JS? What is the power drain to keep the RTC running and a small amount of ram retention (not necessarily the whole space)? Is there some capacitance on the board (or is it reasonable to add some), to keep the RTC alive through a battery swap?

    2) If I don't need USB plug, is it possible to cut off the connector without messing up the board function, to make the board smaller? The Digispark is made to allow this, I've heard, but it's a much less powerful board.


  • Hi Paul,

    Yes, the Pico has an RTC - the power draw with it sleeping is 20uA (so RTC running, all RAM retained). You can get lower than that by shutting down completely (in which case only 80 bytes of RAM are kept) but that isn't supported by JavaScript at the moment.

    One thing to note there is the Pico has an RTC but doesn't come with an accurate low-speed oscillator. The internal 32k oscillator can be +/- 10%!

    However, there are some unpopulated pads at the end of the boards, and you can solder on a Abracon ABS06-107 crystal. Espruino will then auto-detect that and will run with accurate timings.

    And yes, you can cut the USB plug off. Firmware updates are still possible using the serial bootloader too, but you have to short out a solder jumper on the back of the board for that.

    Hope that helps!

  • Just to add to this, I just tested this again and it looks like there's a software glitch at the moment which means that the Pico sometimes leaves the USB peripheral on, and ends up drawing 250uA when sleeping.

    It'll get fixed in a firmware update soon though.

    ... but even so, it looks to be about 10x better than the DigiSpark, but it's hard to find exact figures on the Digispark.

  • Thanks! I had no idea the Digispark used so much power. I wonder what's going on with that. I'd been thinking of using a tiny Arduino-inspired board for some things (Atmega 328 based) and wonder if it has the same issue.

    My application does need an accurate (xtal) RTC, so it's good that it's doable. It would be great if a version was available with the xtal already on it.

    I also need to do some realtime processing (audio signals) in the app--is it reasonable to do that on the Espruino? I can stand a few msec of delay in the system so the JS either needs to be relatively pause-free with the output clocked out on a timer tick, or the realtime stuff could be in a separate task if there's some kind of RTOS. The realtime stuff would probably be written in C either way, or at least call some C code.

    Separate issue/question: I don't know if this is the right place to ask, but why Javascript? I.e. I wonder what the tradeoffs are between JS, MicroPython, eLua, or various Lisp-ish dialects, all of which could run on this class of hardware.

  • It seems to get the size down the DigiSpark does something strange with USB, but I think the main culprit is the voltage regulator. Bigger voltage regulators tend to waste quite a bit of power - I had to put quite an expensive regulator on the Pico to get a high-ish current while still not drawing much power.

    What kind of sampling speed did you have in mind for the Pico? You can do some very basic processing at ~10kHz speeds (check out http://www.espruino.com/Waveform) in JavaScript, but realistically if you want higher you're going to have to compile your own firmware with C code in it, and maybe access the hardware directly.

    There's no RTOS (well, Espruino is the RTOS) but you can schedule tasks to happen every so often in an IRQ, so it makes life easier for you.

    It's not that bad, but you need to be pretty used to writing embedded code to get that C working nicely.

    As far as the choice of JS: It's just about accessibility - way more people know JavaScript than C, and it works well with a REPL - which was a lot of the point of Espruino. Espruino isn't that fast at execution (MicroPython will be faster) but it is extremely efficient when it comes to memory usage because of the way it executes directly from source.

    If you're interested in the internals, you could look at http://www.espruino.com/Performance and http://www.espruino.com/Internals pages

  • Thanks! It's a voice codec so sampling would be 8khz probably. I'm good at C under Linux though I haven't done any serious embedded C yet. I hope I can deal with it. Yes I'm a big fan of scripting languages because of their interactivity and memory safety compared to C. I had been mostly wondering about the differences between them (JS, Lua, uPy, etc). I'll look at the Espruino JS internals docs! The Pico is the nicest of these boards that I've seen so far (small size is an issue) and I've looked at quite a few. Even if I write the whole application in C, I probably want to use the board as I'm not a hardware guy.

  • Ok, great! If you're fine dealing with buffers that come out of the double-buffered waveform class then you should be sorted - you can write normal C code and you won't have to care about the hardware side of things at all.

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

Pico hardware questions

Posted by Avatar for user58984 @user58984