• 'source scripts/provision.sh BOARDNAME? Did it succeeded?'

    I did at one time but had 'PICO' instead of 'PICO_R1_3' Incidentally, I read in one of the online files, (can't find link) that 'PICO' was an acceptable argument. Maybe not?

    Running the 'Just ran' command an now get:

    LD espruino_2v04.121_pico_1r3.elf
    /home/rgc/source/repos/github/espruino/E­spruino/libs/crypto/mbedtls/include/mbed­tls/ssl_internal.h:385:35: warning: inlining failed in call to 'mbedtls_ssl_own_key': call is unlikely and code
    size would grow [-Winline]
     static inline mbedtls_pk_context *mbedtls_ssl_own_key( mbedtls_ssl_context *ssl )
    libs/crypto/mbedtls/library/ssl_srv.c:30­08:11: note: called from here
         ret = mbedtls_pk_decrypt( mbedtls_ssl_own_key( ssl ), p, len,
    GEN espruino_2v04.121_pico_1r3.lst
    GEN espruino_2v04.121_pico_1r3.bin
    bash scripts/check_size.sh espruino_2v04.121_pico_1r3.bin
    PASS - size of 313488 is under 327680 bytes

    And then on to 'RELEASE'

    rgc@DESKTOP-R7T0VUC:~/source/repos/githu­b/espruino/Espruino$ BOARD=PICO_R1_3 RELEASE=1 make
    make: Nothing to be done for 'all'.
    rgc@DESKTOP-R7T0VUC:~/source/repos/githu­b/espruino/Espruino$ dir
    benchmark           Doxyfile                           libs                    README.md
    boards              doxygen                            LICENSE                 scripts
    ChangeLog           espruino                           make                    src
    CONTRIBUTING.md     espruino_2v04.121_pico_1r3.bin     Makefile                targetlibs
    CURRENT_BOARD.make  espruino_2v04.121_pico_1r3.elf     misc                    targets
    dist_licences.txt   espruino_2v04.121_pico_1r3.lst     NRF_Bootloader.md       tests
    dist_readme.txt     gcc-arm-none-eabi-8-2018-q4-major  README_Building.md      Vagrantfile
    Dockerfile          gen                                README_BuildProcess.md

    So, we are close. I thought I understood where the output would reside, but the files within the structure on the local drive are not updating.

    Running a search for \gen locates the platform_config.h file beneath:


    and I am able to see the .bin file at that location, the parent of \gen


    But, unfortunately, the .hex file isn't being built.

  • My bad, it's the espruino_2v04.121_pico_1r3.bin, you built for an STM32, so you need the .bin file, not .hex like nRF chips.

  • Mon 2019.10.07

    Not being picky, but wanted to validate what I thought I saw for d/l options, as my belief was a .bin and a .hex for all builds.

    From the link 'You can also browse by Git commit hash'
    The most current build 2v04 as of today:

    But, looking at Puck, an nRF52 for instance, actually is d/l as a .zip, containing a .bin and .dat but no .hex, so is there still a qualifier needed in your #9 sentence? I'm still way too new to have enough of an understanding to even make a feeble suggestion here.

    Thank you @AkosLukacs for hanging in there to guide me to a solution. Still tons to learn, but at least I have the basics to dig through the 'C' source and make improvement suggestions. I have now successfully created my own Espruino Build!
    With this limited knowledge however, . . . Watch Out, as I am now dangerous!!

    I'll post some install tips for Win10 later this week.


Avatar for AkosLukacs @AkosLukacs started