Avatar for fanoush

fanoush

Member since Jul 2018 • Last active May 2022
  • 11 conversations
  • 954 comments

Most recent activity

  • in Other Boards
    Avatar for fanoush

    Just a small followup - I found aliexpress store that sells those STLink V2 dongles (board photo https://ibb.co/m4MpRhB) with Geehy APM32F103CBT6 https://www.geehy.com/apm32?id=14

    This APM32F103CBT6 is somewhat interesting STM32F103 clone that has 128KB of flash and can run at 96MHz with usb working (real STM32F103 can only do 72MHz). It even has interesting memory mapped single precision FPU that seems to work. So I made Espruino build that run on that chip at 96MHz.

    These dongles are cheap, small and versatile but the ram/flash is pretty small (20KB,128KB) so the Espruino build is stripped down but still it can be used for small USB to GPIO/SPI/I2C projects. The usb stick like form factor with metal case and pin header on the other side can be handy.

    The shop is here https://www.aliexpress.com/item/10050016­21626894.html but no guarantee you'll get same chip too. I got it twice and made third order. Anyway, it is no big deal, just small heads up.

    And btw this one is also nice because it has two LEDs, no strong pull resistors on B6/B7 and even have extra A9/A10 and BOOT0 pads available on PCB so apart from SWD can be flashed via serial bootloader and those two more GPIOs are also readily available for extra HW uart.

  • in JavaScript
    Avatar for fanoush

    Thanks for answer, looks like it might be still worth it then even if being simple. The variable/function address lookup and possibly other stuff known only at runtime cannot be done on server indeed.

  • in JavaScript
    Avatar for fanoush

    I'm not sure if here is good place or github issue is better place. I've noticed there is beginning of JIT feature merged in this commit
    https://github.com/espruino/Espruino/com­mit/b75a36a6da7c8c330d795e56ef977d9adbf4­2ac6

    There is also old closed issue here https://github.com/espruino/Espruino/iss­ues/73 describing some pluses/minuses.

    There is also the inline C and JS compiler https://github.com/gfwilliams/EspruinoCo­mpiler described here https://www.espruino.com/InlineC and https://www.espruino.com/Compilation

    When I saw the JIT is a Kickstarter goal I was curious how this could fit together.
    Looks like current implementation starts from scratch with doing the JIT directly on the device.

    I just wonder is it really needed to have this on the device? What is target device regarding available flash/ram/cpu speed for this? I'd guess even bangle 2 could be too slow and small for this to be an improvement - I fear the compiler would always be too simple and possibly slow.

    Couldn't the inline server based compiler be improved so that it would run as part of some minification phase? If we are talking only Bangle apps stored in repo maybe this could be done on the server somehow automatically so the loader would load already compiled bits to the device?

    I know it is not exactly JIT in the traditional sense but maybe it could offer very similar JIT like flexibility without bloating the device firmware and burning CPU time?

  • in Puck.js, Pixl.js and MDBT42
    Avatar for fanoush

    and if you really need it queued and received later you can trigger sending notification from queue by writing. this can result in same amount of traffic as reading the value also means sending ble packet to puck and getting the result value back

    Edit: in fact this might be more efficient if you have more entries accumulated in the queue, by triggering notification by write you can then send more entries from queue via notifications at once (based e.g. on value written). this is less traffic/faster than reading values one by one

  • in Puck.js, Pixl.js and MDBT42
    Avatar for fanoush

    what about notification? central subscribes to notifications from characteristics, each button press fires notification with new value, central gets it when it happens without a need to ask at random moment by reading it

  • in Porting to new Devices
    Avatar for 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 (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()

  • in Porting to new Devices
    Avatar for fanoush

    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.

  • in Porting to new Devices
    Avatar for 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
    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

Actions