Raspberry Pi Pico

Someone considering porting Espruino to Raspberry Pi Pico?
https://www.raspberrypi.org/products/raspberry-pi-pico/

:) I'm amazed it took this long for someone to ask!

I don't really have the time to spend on it at the moment, but getting it running shouldn't be too painful since it's just a pretty standard ARM core. It's just getting peripheral support done that might take some time.

I'm amazed about that too :) I'm going to try my hand at this port.

It looks like a great candidate, with lots of flash, great IO, and an M0+ core. I have a few Picos (RPi, not Espruino) on backorder so I should have the hardware to test in a week or two I think.

Well, did not ask because the answer was more or less obvious :-)

What's not that clear is - they will sell also bare chips, adafruit, sparkfun, arduino are already making boards with it, would it be worth it for some espruino board? The PIO stuff looks nice, they generated two DVI signals concurrently by this and overclocking the Cortex M0+ cores to 252MHz.

Well, technically, any board can be an Espruino board with the right firmware :)

As for an official Espruino board -- Gordon can answer that, but personally, I'd keep the focus on STM32 and NRF52. RP2040 has some very interesting capabilities, but for me, Espruino isn't about having the most powerful/versatile/etc. board around -- it's about a very short idea-to-implementation distance.

The major thing that sticks out for me is that RP2040 does not have very low power modes -- the current crop of official Espruino boards (and even ESP32/ESP8266) can go down to microamps in sleep, while the published numbers for RP2040 say the least it can go down to is about a milliamp.

In any case, I'm going to give porting Espruino a shot, as soon as I get the hardware.

Thanks - I'd be really interested to hear how you get on with a port.

As @ndabas says really - I'm struggling to see a reason to use RP2040 in an official board at the moment. I feel like Espruino's really big win right now is in low power stuff (especially Bluetooth) and the RP2040 doesn't do either of those.

However I do love the idea of programmable IO. It'd be great to be able to poke a few registers with Espruino (which isn't that fast) and then program the actual hardware to do time-critical stuff.

There still the whole business problem that there is with ESP8266/ESP32 - would anyone actually buy a £20 Espruino RP2040 board when the official Pi one is £3. If not I'd just be stuck supporting a bunch of users that never paid me anything :(

The DVI out is very impressive though - I'm still wondering about the use case though. At some point if you're pushing high-res graphics (especially if you also want internet) you're better off looking at an actual Linux Pi.

Let us know if you already have something, any fork on Github that we can follow or help. Mine just arrived (yes in Brazil things take a long time to arrive, and with an import fee that $4 turns into $20). If I can help with something let us know, I'm tired of just seeing python running on it.

I started messing with it a little. (not a c++ dev) the Pico uses cmake and doesn't look like it plays nice without it. But the way python works on it seems like if we get it compiled you just drop it on the file storage. Let me know if you get anywhere @ndabas and I'll do the same :-) .

I'm working on the port, got sidetracked a bit -- I built this first to easily set up a dev env on Windows: https://github.com/ndabas/pico-setup-windows :)

Anyhow, yes, the major thing that I had to sort out was that the pico-sdk uses CMake. I ended up with a) compiling all of the Espruino files using Espruino's makefile as usual, and then b) using the port-specific makefile to call CMake, which generates makefiles for us, so that we can then compile the RP2-specific files and generate the targets by calling those makefiles.

The description sounds more complicated than it is. It took me a few days to get this part from 'hack that works' to 'almost elegant.'

I'll work a bit more on this over the coming weekend and then post my WIP files.

Cool, thanks. Wondering how micropython port is done regarding cmake, did you check how they solved it?
Maybe the SDK is just bunch of sources and headers like nordic SDK, could it work without cmake at all? But that would mean all needed files would need to be listed like e.g. in https://github.com/espruino/Espruino/blob/master/make/common/NRF5X.make + https://github.com/espruino/Espruino/blob/master/make/family/NRF52.make for nrf52 port, which is a pain. Or you mean you can generate that one via cmake (once? at provision.sh step?) so it can be included like NRF5X.make is?

Micropython is also doing something similar to what I've described. Like I said, it's really not that complicated once you figure it out, see their Makefile: https://github.com/micropython/micropython/blob/master/ports/rp2/Makefile

I'd like to give you all a big round of applause for making the effort, an Espruino build for RP2040 will be fantastic (and save me from having to fragment my Covid-fogged brain into supporting Python as well all the other things).

Is there any other update available on the status of this thread?

Thanks!

I did give this a shot but didn't quite get where I wanted to. If there's somebody else who wants to pick up this work, I'd be happy to have a quick chat about what I know so far.

I estimate that a couple of weeks of solid effort will get the port through. I unfortunately do not have that kind of temporal availability at the moment.

The major issue that got me stuck was that while a lot of the Espruino code is modular with respect to ports, much of it isn't, with #ifdefs in many places to put in architecture-specific code. There are also assumptions about what an ARM has and does, and the Pico is a bit different in terms of how their custom C/C++ SDK is structured, and importantly, abstracted.

if its just fixing a bunch if ifdefs i can take a stab at it. Im not a C++ dev but any pointers on the correct direction would be awesome

I'm just let you know that there is a JavaScript runtime already ported to RP2040 (Raspberry Pi Pico).
https://github.com/kaluma-project/kaluma

Sun 2021.09.05 - resp post #16

Yes, while one may use JS however, it still isn't Espruino!

2nd bullet

ECMAScript 5.1/2015(subset) standard compliant (Powered by JerryScript)

I just completed a little project with the RasPi Pico, Kaluma and a 16x16 Neopixel matrix. While I had to write a Neopixel driver myself (see GitHub), I was really impressed by the overall performance of the RP2040 running Kaluma (roughly 5x compared to an MDBT42Q)

The Kaluma Web IDE technically resembles that of Espruino (Web Serial API used for communication, REPL, integrated Editor with syntax highlighting, code folding and linting) Note: you do not have to sign up in order to use the Kaluma IDE.

There also seems to exist some kind of (yet undocumented) code ecosphere that allows to "require" external modules.

Concerning the business aspects of having Espruino boards with the RP2040: Arduino also already sells such boards (incl. Wifi, BT and sensors) for much more than a single RasPi Pico costs.

I'll still use my Espruino boards (and the Bangle.js, of course) but having RP2040s and Kaluma raises the limit of what is possible without having to program in C/C++ or Python

Interesting, thanks! I hadn't see that before (seems it's JerryScript under the hood)

I noticed on the Kaluma github page:

Small footprint. Runs minimally on microcontrollers with 300KB ROM with 64KB RAM.

So resource wise, an Espruino port would likely allow more user code.

Looks like Raspberry Pi Pico W (wireless) is also to get Bluetooth LE support very soon according to this .
On another thread @JumJum wrote last year on his efforts on a port to the Pi Pico W but has gone quiet now.

I’m very intrigued. But also recognise the challenge to Espruino commercial model.
I had a look at how to build on all the above, but can’t quite see the way through.

Behold!

https://github.com/raspberrypi/pico-sdk/releases/tag/1.5.0

Bluetooth Support for Pico W (BETA)

Key changes:
The following new libraries are provided that expose core:

BTstack functionality: pico_btstack_ble - Adds Bluetooth Low Energy
(LE) support. pico_btstack_classic - Adds Bluetooth Classic support.
pico_btstack_sbc_encoder - Adds Bluetooth Sub Band Coding (SBC)
encoder support. pico_btstack_sbc_decoder - Adds Bluetooth Sub Band
Coding (SBC) decoder support. pico_btstack_bnep_lwip - Adds Bluetooth
Network Encapsulation Protocol (BNEP) support using LwIP.

and more!

News of simpler solution to install tool chain for developing for Raspberry Pi Pico using C or C++ on Windows in VS Code. https://www.raspberrypi.com/news/raspberry-pi-pico-windows-installer/

Also new debug probe for £12. https://www.raspberrypi.com/news/raspberry-pi-debug-probe-a-plug-and-play-debug-kit-for-12/

I'm the author of that Pico for Windows installer :) It's funny how I started out wanting to make a port of Espruino for Pico, got sidetracked trying to set up the toolchain on Windows, built an installer to automate the process, and now that installer has been picked up by Raspberry Pi as their official Pico setup for Windows installer!

The debug probe is great, and is basically a CMSIS-DAP compliant device, so it could probably be used as a debugger for Espruino and other boards that support SWD.

Ah … funny indeed … I missed the link. Well done on the tools. Hopefully these will inspire a few to get involved in a port of espruino. I’m still up for supporting but can’t manage it on my own. I’ll be trying the out the probe soon. Cheers