ndabas

Most recent activity

• Raspberry Pi Pico

  in Porting to new Devices • 1 month, 1 week

  

  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.

• Raspberry Pi Pico

  in Porting to new Devices • 3 months, 3 weeks

  

  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/micropyth­on/blob/master/ports/rp2/Makefile

• Raspberry Pi Pico

  in Porting to new Devices • 3 months, 3 weeks

  

  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-win­dows :)

  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.

• Raspberry Pi Pico

  in Porting to new Devices • 5 months

  

  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.

• Raspberry Pi Pico

  in Porting to new Devices • 5 months

  

  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.