PI Pico pre-alpha

Some weeks ago, I started a project to get Espruino running on PI Pico (RPI2040)
I had no idea how to do, but gave it a try.
Target was, not to change Espruino code itself, no additional ifdef etc.
Right now I'm somewhere around pre-alpha. Simple version is running.
Development is based on pico-examples, not on Espruino make
https://github.com/jumjum123/Espruino4Pico

As expected tons of problems/question are on the road.
In my implementation flash starts at virtual addr 0, which is translated to 2nd MB in flash
This makes Flash-commands easy to understand. Require("flash") runs fine.
Actual problem, one of a lot is jsfGetFileHeader.
Unfortunally addr is tested with this line: if (!addr) return false which stops some other functions.
Any idea, how to get around without changes in jsflash.c ?

BTW, if some body wants to help in this project, you are welcome.

I see no real advantage in having it at address 0. I would see it 'easy to understand' if it would not conflict with any existing memory.

The address map of RPI2040 is here - Chapter 2.2. Address Map
https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf#page=25

ROM | 0x00000000
XIP | 0x10000000
SRAM | 0x20000000
APB Peripherals | 0x40000000
AHB-Lite Peripherals | 0x50000000
IOPORT Registers | 0xd0000000
Cortex-M0+ internal registers | 0xe0000000

nrf52 has spi flash at virtual 0x60000000 because it does not conflict with anything there too

And BTW thanks for picking it up, maybe @ndabas could share his attempt mentioned here http://forum.espruino.com/conversations/359042/#15983946

Well maybe using the XIP region where flash is actually mapped would be good idea.

https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf#page=150
2.6.3. Flash

Not sure how writing to flash works when XIP is enabled, it will probably block executing from flash in similar way as on nrf5x where any execution is halted when erasing/writing.
How does it work on ESP32/8266? It is exactly the same problem there.

@fanoush, thanks for feedback.
Advantage in my eyes is handling of flash.
Moving calculation of real addresses in flash from Firmware to each Javascript project adds burden to the user.
I'm pretty sure only a few guys will know XIP-address, or are willing to search for
Anyway, I don't see the reason for this test.
IMHO testing for negative numbers would be a good solution.

reading directly from flash works fine
writing needs disabling of irq
If somebody has a better solution, you are welcome

mask = getIrqMask();
  irq_set_mask_enabled(mask,false);
  flash_range_program(FLASH_TARGET_OFFSET, addr + i * FLASH_PAGE_SIZE, FLASH_PAGE_SIZE);
  irq_set_mask_enabled(mask,true);

The point of using real address with XIP is to run in place, when you have e.g. string variable pointing to string data (var s="whatever") or js function variable pointing to the start of the code to interpret, it can use address pointing directly to the address in flash managed by XIP so CPU can directly read the data from flash without any copy in RAM.

That's how the Storage module on top of Flash module works (on nrf5x and STM32 at least). Not sure how this works in ESP port in this regard, whether js code stored in flash in Storage file can be directly used for variable data and is directly accessible by CPU or it must be loaded to RAM first.

for NRF the flash addresses from Flash.getFree() is either real memory address for internal flash memory which is directly accessible by CPU or with Bangle watches the SPI flash is mapped to 0x60000000 and direct access is faked as there is no XIP but still there is a hack to use data 'in place' via specific JSV_FLASH_STRING type https://github.com/espruino/Espruino/blob/master/src/jsvar.h#L75 so data does not take RAM but it loaded from flash on demand when iterating over it.

Anyway what I wanted to say is that having flash storage starting from flash location zero and then having real memory mapping of flash data where CPU really sees it in different place can make things more confusing.

So as Pico/RP2040 can see whole 2-16MB SPI flash directly mapped starting at 0x10000000 I'd use that.

Testing for negative value can be used too but it may cause bugs when using unsigned type somewhere.

Anyway maybe I don't understand the topic at all because the 'calculation of real addresses in flash from Firmware to each Javascript project adds burden to the user' issue you mentioned is a mystery to me. Why should users care about that? And those who use Flash API directly to read/write/erase blocks should use areas returned by Flash.getFree()

@fanoush, based on your comments I changed adressing.
Flash.getFree now returns real address in Flash.
Flash.erasePage, .read and .write also use real address and are recalculated to match API
Sideeffect: found and fixed a problem in jshWriteFlash and got save() running.

BTW, interest in this port is not really overwhelming ;-)

Given the new pi Pico W and the wait for the espruino wifi, I'm getting interested in this port :)

https://t.co/2leMu87zwC

Given the new pi Pico W and the wait for the espruino wifi, I'm getting interested in this port :)

https://t.co/2leMu87zwC

@user143733 I sent you a message

BTW, interest in this port is not really overwhelming ;-)

Just got a few Pico Ws and got burned by MicroPython right away. So... very interested in a port. Given the wireless support of the new chip, there might be quite some potential.

Everything without an event model/loop will have to rely on archaic multi/dual core distribution approach and the RasPico's GPIO features. Not really a replacement for a neatly generalized run loop.

Burned how?

@JumJum thanks for sharing this. And well done.

@SimonGAndrews
Good news

• got a pico w
  
• got it connected from Espruino to my wireless
  Bad news
  
• don't get my hands on a http-server. There is a first step in Github, but my understanding is poor. My way right now is a mix of trial/error and copy/paste
  
  

BTW, Gordon already offered to help changing from cmake to espruino like make, once the port is kind of stable. For me this port is having some fun, don't have to make money for the family.

Great news, I would like to help.

I have got your port building using VSCode on Windows. Espruino is firing up in the Espruino IDE. Interactive is executing but save to flash and execute is not. Im going to try and setup a Debug test rig (with RP Pico W) as per https://community.element14.com/products/raspberry-pi/b/blog/posts/debugging-the-raspberry-pi-pico-on-windows-10

Please can you share any updates when you can.

I would be interested to help setup USB (both device (HID etc) as existing Espruino and new host functionality). Testing the mapping of console to serial etc as I go.

@JumJum , i hope you are well.
Do think you will be sharing anything further on this ?
No pressure just interested in seeing this happen one day, and supportig if needed.