-
• #2
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/blob/master/README_Building.md#for-espruinoTo 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'
folderI 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\Espruinoand 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.
-
• #3
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/blob/master/README_BuildProcess.md
The link from #2 above
https://github.com/espruino/Espruino/blob/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?
-
• #4
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 tutorialOpen 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
-
• #5
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/github/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 triedBOARD=PICO_R1_3 make
rgc@DESKTOP-R7T0VUC:~/source/repos/github/espruino/Espruino$ BOARD=PICO_R1_3 make CC /home/rgc/source/repos/github/espruino/Espruino/targetlibs/stm32f4/lib/startup_stm32f401xx.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
-
• #6
Okay, getting warmer now,
Under 'Problems' tab
'cannot open source file "platform_config.h" (dependency of "jsi2c.h")'
Web search turned up:
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.pyVerified 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 getcc1: 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/github/espruino/Espruino$
and still have error under 'Problems' tab:
'cannot open source file "platform_config.h" (dependency of "jsi2c.h")'
-
• #7
Did you ran
[source scripts/provision.sh BOARDNAME]
? Did it succeeded?
https://github.com/espruino/Espruino/blob/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
andmake clean && BOARD=PICO_R1_3 RELEASE=1 make
and got a new hex in the root of Espruino repo. -
• #8
'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/Espruino/libs/crypto/mbedtls/include/mbedtls/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:3008: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/github/espruino/Espruino$
And then on to 'RELEASE'
rgc@DESKTOP-R7T0VUC:~/source/repos/github/espruino/Espruino$ BOARD=PICO_R1_3 RELEASE=1 make make: Nothing to be done for 'all'. rgc@DESKTOP-R7T0VUC:~/source/repos/github/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/github/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\CanonicalGroupLimited.Ubuntu16.04onWindows_79rhkp1fndgsc\LocalState\rootfs\home\rgc\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
-
• #9
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. -
• #10
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.
-
• #11
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 :)
Sun 2019.09.29
Spin off from suggestions in a completely separate thread topic started at:
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.
Should I execute from the terminal window within VSCode:
Terminal >> Run Active File
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
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 #8But 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 thegit clone
instructionSo 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
The obvious stand out to anyone?