ndabas

Most recent activity

• Raspberry Pi Pico

  in Porting to new Devices • 3 months, 1 week

  

  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.

• Raspberry Pi Pico

  in Porting to new Devices • 2 years

  

  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 • 2 years, 3 months

  

  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 • 2 years, 3 months

  

  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 • 2 years, 4 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 • 2 years, 4 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.