PI Pico pre-alpha

Posted on
  • 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/Espruino4Pi­co

    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/rp204­0/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/rp204­0/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/blo­b/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?

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

PI Pico pre-alpha

Posted by Avatar for JumJum @JumJum

Actions