ESP32 Forum

When we build solutions using the ESP32, we need a development environment on which to build those solutions. We also need some infrastructure for testing. For example if we are using I2C, SPI, UART or other protocols, we may wish to test that those are working. In the current DevKitC I have, it doesn't automatically cause the ESP32 to enter flash mode when I wish to flash. I also like to watch my serial console during development. And of course, the ESP32 needs to be powered.

With these thoughts in mind, I wondered if we could use a Raspberry Pi 3 to assist with some or all of these tasks. The result is a bread-boarded DevKitC connected to the Pi as shown in the following picture:



The Pi can now control all aspects of I/O on the ESP32 ... including serial access and reboots into different modes. From there, we have a lot of choices. Here is a screen shot of a simple browser based app connecting to a Node.js server running on the Pi that is controlling boots and console output:



We can also run the full compile tool-chain on Pi including the Espressif IDF. So in principle, no need for any desktop PCs. I'm working with some folks on porting software to ESP32 and those folks don't yet have ESP32s ... so now we have a "cloud hosted" environment ... and when all is said and done, they could even write their code, perform their compiles, flash to ESP32 and see the console ... all from a browser ... anywhere on the Internet.

Notes on using the Raspberry Pi as a development environment can found in a free downloadable PDF available here:

https://leanpub.com/ESP8266_ESP32

A download of a compressed tar file containing the binaries of a build of the Xtensa tool chain for the ARM processors (specifically the Raspberry Pi 3) can be downloaded here:

http://www.neilkolban.com/esp32/downloa ... elf.tar.gz

I recommend the content be extracted to the /opt directory.

A YouTube video illustrating the story is available here:

https://www.youtube.com/watch?v=jt0aaMQD1WI


*** this post contains some edits made over time ***

Sounds like a nice standalone dev environment! You may even be able to integrate a JTAG debugger in there. The Raspberry Pi GPIO can be used as a JTAG host interface that OpenOCD can control. (https://github.com/synthetos/PiOCD/wiki ... TAG-Dongle for an example). So, with four or five extra wires, you should be able to live-debug your ESP32 from the Pi as well.

I'm very interested in learning more about "JTAG" which I know nothing about and will start studying that. I built the toolchain from your instructions in the IDF ... compiled without incident ... however it needed nearly 4GBytes of storage space to build and as such I had to use an NFS mount which slowed things considerably. All in all in took over 10 hours to build. The resulting toolchain is under 100MBytes which is fine. Would Espressif consider hosting a compiled build for developer download to save us having to build an ARM based toolchain ourselves? If not, in your experience, is there a place where community members like myself may upload the compiled binaries for distribution?

In these early days of ESP32 experience, I find myself concerned when I find something that doesn't work as expected. Using this ARM based environment ... I now no longer know if an issue with an ESP32 is my own coding, my mis-understanding of the APIs/environment, something not working yet in the early code drops of the ESP32 framework or ... and this would be new ... something I have introduced because I am compiling and uploading from an ARM device.

Regarding ESP32 toolchain for Linux ARM hosts: thanks for a reminder, I will add it to the list of pre-built toolchains.

I've been using Neils prebuilt toolchain and it works a treat on my Raspberry Pi 3. But, since there has been newer releases lately I thought I'd complie one myself using the walkthrough provided.
Problem is that it freezes up after ~20- 25 minutes and the whole thing becomes unresponsive.
Any ideas of what I can do to get around that? Alternatively, It would be nice if Espressif provided up-to-date prebuit toolchains for ARM Linux?!

MANY thanks for the pointer ... I wrote the article of running builds on the PI when I first got my ESP32 but after some experience, I found that building on a desktop was (not unsurprisingly) much faster. I had assumed that most everyone was now doing the same. If you still have need for Pi development, post back ... and I'll partner with you to try and get the latest Xtensa tool chain built for the Pi.

Async_Awayt wrote:I've been using Neils prebuilt toolchain and it works a treat on my Raspberry Pi 3. But, since there has been newer releases lately I thought I'd complie one myself using the walkthrough provided.
Problem is that it freezes up after ~20- 25 minutes and the whole thing becomes unresponsive.
Any ideas of what I can do to get around that? Alternatively, It would be nice if Espressif provided up-to-date prebuit toolchains for ARM Linux?!

I commented Neil's video on YouTube two weeks ago. I'm adding it here as well in case it will help anybody.

I had the same issue on my Raspberry PI 3. It either freezes or 'internal compiler error: Segmentation fault'. Neither changing/reformatting SD card nor compiling to external USB HDD helped to resolve this issue. I noticed that issue occurred when all of 4 cores were fully utilized 100%. I came to conclusion that there could be some conflict during parallel build. Thus I disabled parallel jobs. You can do it either by Or After that building toolchain succeeded. It took 200 minutes to build the toolchain.
Another issue I ran into was "'Serial' object has no attribute 'is_open'" during make monitor. I had to update pyserial:

Great Neil,

I would very much appreciate your help. The main reason I am trying this is that it is a relatively cheap and accessible platfrom. My son and his mates are really into ESP32s now, we have plenty of Raspberry Pi 3s around and even more ESP32 boards. The bottleneck is availability of computers to actually be let alone and program.

Anyhow, this is what i am doing:

- Start off from a Raspbian Jessie out of the box
- sudo apt-get update
- sudo apt-get upgrade
- sudo apt-get install gawk gperf grep gettext automake bison flex texinfo help2man libtool libtool-bin git wget make libncurses-dev python python-serial python-dev
- cd ~/esp
- git clone -b xtensa-1.22.x https://github.com/espressif/crosstool-NG.git
- cd crosstool-NG
- ./bootstrap && ./configure --enable-local && make install
- ./ct-ng xtensa-esp32-elf
- ./ct-ng build ( THIS IS AS FAR AS I GET. After 20-25 minutes the Pi becomes irresponsive.. . )
So I never get around to run the last line below...
- chmod -R u+w builds/xtensa-esp32-elf

Is there anything I could try differently to get around this?

Regrards!

sergiy wrote: I had the same issue on my Raspberry PI 3. It either freezes or 'internal compiler error: Segmentation fault'. Neither changing/reformatting SD card nor compiling to external USB HDD helped to resolve this issue. I noticed that issue occurred when all of 4 cores were fully utilized 100%. I came to conclusion that there could be some conflict during parallel build. Thus I disabled parallel jobs. You can do it either by

Code: Select all

>./ct-ng build build.1

Or

Code: Select all

Before invoking ct-ng build
>nano ./.config
Find CT_PARALLEL_JOBS=0 and change 0 to 1

After that building toolchain succeeded. It took 200 minutes to build the toolchain.
Another issue I ran into was "'Serial' object has no attribute 'is_open'" during make monitor. I had to update pyserial:

Code: Select all

>sudo apt-get install python-pip
>sudo pip install pyserial

[

Thanks for the support, but I tried both editing the ./.config file and changing the ./ct-ng command according to your instructions and it did not work.

Now I am trying to do both at the same time and later I will try to do it by ssh from another computer in case it might be the desktop overhead that somehow consumes processing power.

I will keep you posted.

Finally! The solution was to make all additions suggested by sergiy here is the whole walktrhrough:
-- > Find CT_PARALLEL_JOBS=0 and change 0 to 1 The build took forever so I suggest running it overnight.

Then feel free to move the files to ~/esp/xtensa-esp32-elf for future compatibility with the "readthedocs" tutorial.

Thanks guys!