Problems setting up Windows Linux Subsystem with esp-idf

[PaulFreund]

I have written down the overall steps I did here https://esp32.com/viewtopic.php?f=2&t=4166#p21876 but it is really important to follow each and every step, especially in the linux setup guide from Espressif.

If you took the hello_world from IDF examples the Makefile contains the line:

Code: Select all

include $(IDF_PATH)/make/project.mk

make only sees '/make/project/mk' so the $IDF_PATH variable is not defined.

The reason for this is that you started make with sudo. Sudo will by default not preserve your environment (to do this you can use -E). In this case there is no reason to invoke make as root because all the files accessed are belonging to your user. for make flash and make monitor I suggest to change the rights of the tty as I described in my linked post.

[gnorkus]

Well,

What a boondoggle that was! Problem partially solved...

By the way, if you look at the example, I tried both "make" and "sudo make", and neither worked. Now I understand why the "sudo make" could never work the way I tried it. Thank you PaulFreund.

I decided to go to the kolban-esp32.pdf book, and followed the recipe to the "tee". Voila! It worked!

The problem, I think, came in me putting my script files to setup PATH and IDF_PATH in /etc/profile.d. For some strange reason, it just wouldn't resolve those paths correctly, even though I used $(HOME). It will also not allow me to put the export commands, mentioned in the Kolban_ESP32.pdf book, into a script and run it. Any suggestions?

Also noticed, my SparkFun ESP32 Thing doesn't connect as well in Debian as it did MSYS2. I have to toggle the GPIO_0 button to get the flash to complete it's connection. Never had to do that in MSYS2. Probably a make menuconfig setting.

GJN




P.S.
My Linux must be just about as good as my German. The wife and I went there, and I could converse, but when we went to the restaurant to order food, I couldn't translate the menu to her. Her comment, "if you can't translate the food, you've missed the most important point of translating! Food, lodging, and restrooms, in that order...".

[ESP_igrr]

$(HOME)

I think this is Make syntax. In shell, it's either $HOME or ${HOME}.

[mikemoy]

I am just curious...
I have just started to try to learn Linux, but so far I see how scrips are a great thing. Why hasn't some of the Linux guys, made a script that would perform all these steps. Seems to me it would be far better to run one thing that handles all this, than doing copy and pasted from the docs line by line, and keeping the documents updated all the time. Just update the script.

[kolban]

Howdy,
Good question.
In a Linux environment, we have a file called ".profile" that is a script that is run when we login. This is commonly edited by Linux types. In mine, I added the exports of the environment variables:

IDF_PATH
PATH (Augmented with the xtensa toolchain)

and that's it. Nothing else needed (for me). Now when I enter a directory that contains an ESP-IDF project, all I need run is "make" and compilation proceeds. No bigger scripts needed, just the configuration of my variables to instruct the environment of the location of my ESP-IDF components.

[mikemoy]

Thanks for the kind reply. I should have been more clear in my post.
Could there not be a script that performs all the install requirements on a Linux box ?
I.E. Page 69 from the great Kolban's ESP32 book

Small Snippet...

cd ~
mkdir esp32
cd esp32
sudo apt-get install git wget make libncurses-dev flex bison gperf python python-serial

[gnorkus]

Hi nkolban!

Well... I added the following to my profile (using nano, to avoid permissions issues, before I submitted my previous post). At first, the make didn't like it. But strangely, it now does. Likely I missed something along the way.

Now, I'm onto somehow getting my WROVER kit to give me openocd tracing...yikes! But your guide has gotten me a little further than the Espressif guide in MSYS. Now it's only trying to figure out the driver location, I think. I've used the zadig-2.3 exe. The interface (1) is actually the first in the list and is using the FTDI driver. So, I changed the second in the list, interface (0) to use the WinUsb driver.

Code: Select all

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
	. "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

export PATH=/opt/xtensa-esp32-elf/bin:$PATH 
export IDF_PATH=~/esp32/esp-idf
sudo chmod 666 /dev/ttyS8

[kolban]

@mikemoy

When working in our fun space we have individuals with all kinds of skills and all kinds of preferences. We have new users who are just starting and we have old timers that are happy to work on punch card. We have Windows enthusiasts and Linux proponents. It will never be possible to satisfy everyone.

Instead, what we might want to do is educate to common denominators.

For example ... any sequence of Linux shell entered commands that one wants to run multiple times can entered into a text file and then that text file executed. This makes the text file a shell script. Now when we document commands, we can anticipate that if we list all the commands to be run, a reader can read them and say "Ok ... got it" while someone who wants to run them multiple times can copy/paste them into a script file.

The question now becomes ... should someone pre-provide the scripts with the commands already entered ... and I for one don't have a thought on that. For me .... and me alone ... I'm happy to see a list of commands that I can contemplate rather than a single command which encapsulates much in a script.

[mikemoy]

I'm happy to see a list of commands that I can contemplate rather than a single command which encapsulates much in a script.

Still just curious
But doesn't the script accommodate both, the ones that like the single command, and those that want the list. One could always just look at the script say in nano to see the "lists".

Anyways... Thanks again for the informative answer.

[kolban]

I have another hope

A couple of decades ago one might have laughed at the idea of Windows including the ability to run a distribution of Linux. However, in my opinion, one very important thing changed to make WLS a reality ... that one thing is Docker. I am a firm believer in the power of docker and dockerization of applications. I am of a belief that WLS is a stepping stone on the way to full Docker support on Windows (if it isn't there already). When that becomes a reality, one will be able to download a docker image that contains the ESP-IDF as well as the tool-chain and simply run a command that runs the docker image that compiles your local source and results in a compiled program. At no-time would there be a need for you to construct, setup, or prepare a build environment for your target ESP32 apps. You would just run the "black box" docker image and "poof" ... your executable would be there for you.

Just musing ...