Someone considering porting Espruino to 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?
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.
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem