• Sun 2019.09.29

    Spin off from suggestions in a completely separate thread topic started at:

    http://forum.espruino.com/conversations/­337198/#comment14873557

    From that link,
    A special Thank You @Wilberforce #6, @Gordon #17, and @AkosLukacs #8 for the step-by-step detail.

    Had a bit of down time to make my first pass attempt, and quite frankly a bit overwhelmed, mostly from new terms and new language obstacles not having experience with WSL, Linux, Python and VSCode. Made tremendous progress thanks to @AkosLukacs, but still stuck at a possible basic setup issue.

    https://www.espruino.com/Extending+Espru­ino+1
    https://github.com/espruino/Espruino/blo­b/master/README_BuildProcess.md

    Should I execute from the terminal window within VSCode:

    Terminal >> Run Active File

    > Executing task: echo Hello <
    
    Hello
    
    Terminal will be reused by tasks, press any key to close it.
    

    So, first guess is that VSCode is allowing WSL to function.

    Then on to executing a Python file in the same manner.

    Should I execute from the terminal window BOARD=PICO_R1_3 make

    Terminal >> Run Build Task

    rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/D­ocuments/Espruino$ /mnt/c/Users/robin/Documents/Espruino/sc­ripts/build_board_json.py
    -bash: /mnt/c/Users/robin/Documents/Espruino/sc­ripts/build_board_json.py: /usr/bin/python: bad interpreter: No such file or directory
    rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/D­ocuments/Espruino$ BOARD=PICO_R1_3 make
    /bin/sh: 1: python: not found
    make: Nothing to be done for 'all'
    

    But, the Python script ran, so the Python Extension for VSCode should be functioning. (only uninstall visible) and the file build_board_json.py is present from the clone process.



    So, it appears I'm stuck at the same 'Rookie' mistake, @AkosLukacs warns about perhaps?

    To keep things tidy in Windows10, I attempted cd ~ as in step 3 from AkosLukacs #8
    But that placed the contents in the 'Users' folder, and code isn't easily backed up as compared to when within the 'Documents' folder

    I changed that to cd Documents then ran the git clone instruction

    So from the Windows point of view, the cloned files are now at C:\Users\robin\Documents\Espruino\

    and from WSL are at /mnt/c/Users/robin/Documents/Espruino



    Also looked over @JumJum 's 'C' extension tutorials for hints ideas etc

    http://forum.espruino.com/conversations/­291695/#comment13174227



    The obvious stand out to anyone?

  • Looks like you don't have python (and possibly other things) installer in your WSL. Did you install the required software?https://github.com/espruino/Espruino/blo­b/master/README_Building.md#for-espruino­

    To keep things tidy in Windows10, I attempted cd~ as in step 3 from
    AkosLukacs #8 But that placed the contents in the 'Users' folder, and
    code isn't easily backed up as compared to when within the 'Documents'
    folder

    I changed that to cd Documents then ran the git clone instruction

    So from the Windows point of view, the cloned files are now at
    C:\Users\robin\Documents\Espruino

    and from WSL are at /mnt/c/Users/robin/Documents/Espruino

    You can try that, but bash scripts failed for me if I didn't clone to a WSL-only path.

  • Tue 2019.10.01

    BINGO! @AkosLukacs, that appears to be what was missed!

    While in the vain attempt to not make the 'Rookie' mistake, I introduced and now own today's 'Knucklehead' award. As I installed Python as I have always done, I was convinced scripts were running within VSCode. Never could get passed the following line though:

    'and follow the Linux instructions :)'   (bullet 6 from previous mentioned link #8)

    Was wondering what the 'Linux' reference was.

    Then today, . . . Aaahhhhh, now the following line makes sense now:

    The page I grabbed was the first one below. Note the subtle page name difference!

    https://github.com/espruino/Espruino/blo­b/master/README_BuildProcess.md

    The link from #2 above

    https://github.com/espruino/Espruino/blo­b/master/README_Building.md#for-espruino­

    Although I haven't followed through, a task for this weekend, I'm sure that will get me back on track.


    'but bash scripts failed for me if I didn't clone to a WSL-only path'

    Are you able to suggest a 'WSL-only' path, and where Windows then places the repository in the Windows file space then?

    I believe the intent is still to create a folder using the Terminal window inside VSCode, and then install Python there?

  • Are you able to suggest a 'WSL-only' path, and where Windows then
    places the repository in the Windows file space then?

    I believe the intent is still to create a folder using the Terminal
    window inside VSCode, and then install Python there?

    Yes, so WSL is a separate linux running in your windows, so you have to install things like python separately.
    You can just use WSL without VS Code, but having an editor that can interact with your "linux" file system makes things much easier IMO. Here is a VS Code remote WSL tutorial

    Open a remote WSL in code.

    Open a terminal in the remote WSL window, if it's not open.
    git clone espruino inside the remote wsl (it will be at your WSL home by default i think)
    And follow the linux build preparation instructions.
    After you cloned, you can open the folder with espruino in the remote WSL window, and start editing.


    2 Attachments

    • wsl.png
    • wsl2.png
  • Sun 2019.10.06

    At it again, but still struggling. Followed the step-by-step VSCode WSL terminal window entry using the lines beneath the 'for Espruino' heading, starting with:

    rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin$ cd ~
    rgc@DESKTOP-R7T0VUC:~$

    sudo apt-get update

    Am able to edit a .c file and observe that it changes the local file at:

    C:\Users\robin\Espruino\src

    and, Python installed correctly this time along with git and pip

    but, running the make command line, isn't providing a .hex file in:
    make clean && make

    C:\Users\robin\Espruino\gen

    Confirming the above is the folder where the .hex and .bin files will end up?

    rgc@DESKTOP-R7T0VUC:~/source/repos/githu­b/espruino/Espruino$



    Is this terminal window output what is observed during the 'Rookie' mistake? That is, the install is still in the wrong location?



    EDIT:
    Just tried BOARD=PICO_R1_3 make

    rgc@DESKTOP-R7T0VUC:~/source/repos/githu­b/espruino/Espruino$ BOARD=PICO_R1_3 make
    CC /home/rgc/source/repos/github/espruino/E­spruino/targetlibs/stm32f4/lib/startup_s­tm32f401xx.o
    make: arm-none-eabi-gcc: Command not found
    Makefile:763: recipe for target '/home/rgc/source/repos/github/espruino/­Espruino/targetlibs/stm32f4/lib/startup_­stm32f401xx.o' failed
    make: *** [/home/rgc/source/repos/github/espruino/­Espruino/targetlibs/stm32f4/lib/startup_­stm32f401xx.o] Error 127
    

    1 Attachment

    • VSCode20191006RookieErr.jpg
  • Okay, getting warmer now,

    Under 'Problems' tab

    'cannot open source file "platform_config.h" (dependency of "jsi2c.h")'

    Web search turned up:

    http://forum.espruino.com/comments/14308­300/

    I opened the \gen folder and only a 'README' file exists.

    Searching for instructions as to whether I need to create that file or if it is (failed) as a result of not all extensions in the correct place yet.



    EDIT: (hour later)
    From post #14 link to GitHub output shows file is auto gen'd

    // Automatically generated header file for STM32F100CB
    // Generated by scripts/build_platform_config.py

    Verified that file 'build_platform_config.py' is within the tree both inside VSCode and within the local file system.

    Re-ran make clean && make
    but get

    cc1: warning: unrecognized command line option ‘-Wno-expansion-to-defined’
    gen/jswrapper.c: In function ‘jswOnCharEvent’:
    gen/jswrapper.c:1901:34: warning: unused parameter ‘channel’ [-Wunused-parameter]
     bool jswOnCharEvent(IOEventFlags channel, char charData) {
                                      ^
    gen/jswrapper.c:1901:48: warning: unused parameter ‘charData’ [-Wunused-parameter]
     bool jswOnCharEvent(IOEventFlags channel, char charData) {
                                                    ^
    gen/jswrapper.c: In function ‘jswGetBuiltInJSLibrary’:
    gen/jswrapper.c:1905:48: warning: unused parameter ‘name’ [-Wunused-parameter]
     const char *jswGetBuiltInJSLibrary(const char *name) {
                                                    ^
    cc1plus: warning: unrecognized command line option ‘-Wno-expansion-to-defined’
    gen/jswrapper.c: At top level:
    cc1: warning: unrecognized command line option ‘-Wno-expansion-to-defined’
    LD espruino
    rgc@DESKTOP-R7T0VUC:~/source/repos/githu­b/espruino/Espruino$
    

    and still have error under 'Problems' tab:

    'cannot open source file "platform_config.h" (dependency of "jsi2c.h")'

  • Did you ran [source scripts/provision.sh BOARDNAME]? Did it succeeded?
    https://github.com/espruino/Espruino/blo­b/master/README_Building.md#easy-method-­-provisionsh That should install all dependencies (like ARM compiler, or Espressif SDK) for the given board.

    Just ran source scripts/provision.sh PICO_R1_3 and make clean && BOARD=PICO_R1_3 RELEASE=1 make and got a new hex in the root of Espruino repo.

  • '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
    rgc@DESKTOP-R7T0VUC:~/source/repos/githu­b/espruino/Espruino$
    

    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
    rgc@DESKTOP-R7T0VUC:~/source/repos/githu­b/espruino/Espruino$
    

    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:

    C:\Users\robin\AppData\Local\Packages\Ca­nonicalGroupLimited.Ubuntu16.04onWindows­_79rhkp1fndgsc\LocalState\rootfs\home\rg­c\source\repos\github\espruino\Espruino

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

    espruino_2v04.121_pico_1r3.bin

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


    1 Attachment

  • 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.

    https://www.espruino.com/Download
    From the link 'You can also browse by Git commit hash'
    http://www.espruino.com/binaries/travis/­?C=M;O=D
    The most current build 2v04 as of today:
    http://www.espruino.com/binaries/travis/­1a4f2864e3a15a60f91040ce2ad52e844c238fd8­/

    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.

  • Ok, I was wrong: The zip is the DFU package to be used when updating the Puck / Pixl / MDBT40Q breakout.
    recently I used .hex files to upload code to the nRF52840 dongle :)

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

Espruino Build issues using README_BuildProcess.md and Extending+Espruino+1 within Windows10 environment

Posted by Avatar for Robin @Robin

Actions