PI Pico pre-alpha #6864
Replies: 1 comment
-
Posted at 2022-05-12 by @fanoush 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 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 Posted at 2022-05-12 by @fanoush 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 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. Posted at 2022-05-12 by JumJum @fanoush, thanks for feedback. Posted at 2022-05-12 by JumJum reading directly from flash works fine
Posted at 2022-05-12 by @fanoush The point of using real address with XIP is to run in place, when you have e.g. string variable pointing to string data ( 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() Posted at 2022-05-18 by JumJum @fanoush, based on your comments I changed adressing. BTW, interest in this port is not really overwhelming ;-) Posted at 2022-06-30 by MariusGundersen Given the new pi Pico W and the wait for the espruino wifi, I'm getting interested in this port :) Posted at 2022-06-30 by MariusGundersen Given the new pi Pico W and the wait for the espruino wifi, I'm getting interested in this port :) Posted at 2022-06-30 by JumJum @user143733 I sent you a message Posted at 2022-07-03 by Stev
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. Posted at 2022-07-20 by yngv126399 Burned how? Posted at 2022-08-24 by @SimonGAndrews @jumjum thanks for sharing this. And well done. Posted at 2022-08-27 by JumJum @SimonGAndrews
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. Posted at 2022-08-27 by @SimonGAndrews Great news, I would like to help. Posted at 2022-08-27 by @SimonGAndrews 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. Posted at 2022-08-27 by @SimonGAndrews 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. Posted at 2022-08-27 by @SimonGAndrews @jumjum , i hope you are well. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-05-12 by JumJum
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.
Beta Was this translation helpful? Give feedback.
All reactions