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
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
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.
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.
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();
flash_range_program(FLASH_TARGET_OFFSET, addr + i * FLASH_PAGE_SIZE, FLASH_PAGE_SIZE);
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.
@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 :)
@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.
@JumJum thanks for sharing this. And well done.
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.
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