Flowcode Support Board

Hi Jan.
I have just updated the Flowcode Wiki So the ESP32 toolchain can be installed in 2023, since Expressive keeps moving the goalposts.
You can find the page here
I first uninstalled everything related to the ESP32 toolchain e.g. Python, ESP-IDF tools 2.3, etc.
I then reinstalled everything taking screenshots as I went along.
It all worked the first time.

Hi Martin, that's good news!
I'll do that as soon as I get home.
As far as pointing FC to the ESP compiler, I guess we set the Location for the ESP toolchain to c:\esp-idf in this example.

Jan

Hi Jan yes.
it should show you on the wiki page step by step.
If there is anything that's not clear (or missing), then if you would like to point it out, I will edit the Wiki entry.

Good afternoon gentlemen,

It seems I (we) have been barking up the wrong tree all along.
I mentioned that on my little miniPC that I hadn't touched in several months, the chart for the ESP_wroom_32 compiled succesfully. Following a hunch (the beach does that to you sometimes) I also compiled a few of the later charts I developed since I used this miniPC last time. Lo and behold, several of them failed with the familiar CMake fail.
So, some charts compiled fine, others not. Since the install is the constant, it appeared that the failure came from something in the flowchart, not the install.

Next step is obvious: take a chart that fails and start to dismember it until it no longer fails. At the end I got to the rudimantary chart attached: it fails, unless the first calculation block with the log() operation is disabled. The conclusion must be that the log() statement causes the failure.

Doublecheck: I took one of the charts that compiled without error and inserted the log calculation block of the attached in its Main() and sure enough, compile failed. QED.

It would be useful if someone could verify that this log() statement would also lead to a fail in their ESP environment, closing the circle. And opening up another one, of course.

Jan

Hi Jan.
I have replied to your PM
it looks like the project is wrong rather than the ESP32 toolchain.

With Martin/medelec35's help the root cause was finally discovered: at one spot in the failing charts, the log() function was written with a capital L, Log(). As soon as that was changed to lower case log() all compiled without fail.

This was a very protacted and frustrating journey for me. In hindsight, it is understandable why the attention went to the install, because it is flaky and doing unexpected things. But I should not have taken that for granted, and should have looked into the charts themselves as well, if only to close that off. It's only when I got to this machine that ran some of the charts without failure that I thought about looking elsewhere.
A lot of learning moments for me that I missed.

Anywy, I'm happy that with all your help my project now can proceed.
I do apologize for all the time spend on this, but I would not have gotten to this finish line without all your inputs.
Appreciated very much.

Enjoy your weekend,

Jan

Hi Jan
The posts are not in vain as I'm sure they will be helpful to others.
Great to hear you are up and running again.
Regards

Phew - glad it's working...

Martin

Yes.
I still have to get the install right at the home PC but that should work OK now with all the tips from you guys!

Jan

Not quite there yet. Downloaded and installed using Marttin's procedure as described in the Wiki.
First of all, that shows version 2.3 of the Toolchain, both in the download and the opening screen, but when I download the install file linked to, it *looks* like 2.3 but the opening screen says 2.9. So it appears that for some reason, the download has been changed between Martin putting it up and me downloading it.
This 2.9 version does no longer ask for a Python or Git install but has it 'embedded' in the download/install (Python 3..8.7 and Git 2.30.1).
It does do some pre-installation system checks for instance for allowed long pathnames which I haven't seen in the previous version.
I installed 4.2.4 release. Used all defauld boxes ticked. At the end you can make it register with Windoze Defender.
It then runs a couple of Command prompt scripts adding stuff to Path, see attached.

But when I look in the Environment Path variables I see:

c:\users\jandi\appdata\local\programs\python\python37\scripts\
c:\users\jandi\appdata\local\programs\python\python37\
c:\users\jandi\appdata\roaming\python\python37\scripts\
c:\users\jandi\appdata\roaming\python\python37\

That is some old stuff, but why don't I see the newly-added Paths?

So, when I run a compile, this is the error info, which seems related to the Path although it specifically mentions a 'click'function, which I checked is the first command in the Diagnostic information:
IDF_PYTHON_ENV_PATH: (not set)
Python interpreter used: C:\Users\jandi\AppData\Local\Programs\Python\Python37\python.exe
Warning: python interpreter not running from IDF_PYTHON_ENV_PATH
PATH: C:\users\jandi\Espressif\tools\xtensa-esp32-elf\esp-2020r3-8.4.0\xtensa-esp32-elf\bin;C:\users\jandi\Espressif\tools\xtensa-esp32s2-elf\esp-2020r3-8.4.0\xtensa-esp32s2-elf\bin;C:\users\jandi\Espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\users\jandi\Espressif\tools\esp32s2ulp-elf\2.28.51-esp-20191205\esp32s2ulp-elf-binutils\bin;C:\users\jandi\Espressif\tools\cmake\3.16.4\bin;C:\users\jandi\Espressif\tools\openocd-esp32\v0.11.0-esp32-20211220\openocd-esp32\bin;C:\users\jandi\Espressif\tools\ninja\1.10.0\;C:\users\jandi\Espressif\tools\idf-exe\1.0.1\;C:\users\jandi\Espressif\tools\ccache\3.7\;C:\users\jandi\Espressif\tools\dfu-util\0.9\dfu-util-0.9-win64;C:\Users\jandi\esp-idf\tools;C:\Program Files\Common Files\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Users\jandi\AppData\Local\Programs\Python\Python37\Scripts\;C:\Users\jandi\AppData\Local\Programs\Python\Python37\;C:\Users\jandi\AppData\Roaming\Python\Python37; C:\Users\jandi\AppData\Roaming\Python\Python37\scripts
Traceback (most recent call last):
File "C:\Users\jandi\esp-idf\tools\idf.py", line 45, in <module>
from idf_py_actions.tools import (executable_exists, idf_version, merge_action_lists, realpath) # noqa: E402
File "C:\Users\jandi\esp-idf\tools\idf_py_actions\tools.py", line 1, in <module>
import click
ModuleNotFoundError: No module named 'click'

Build Failed

So then I removed all traces of Python (and Git) I could find, cleaned the registry, restarted and re-installed.
I then copied manually the path I think is right, into the environment variables, like this, as it appears in my folder system:

C:\Users\jandi\.espressive\python_env\idf4.2_py3.8_env\scripts\
C:\Users\jandi\.espressive\python_env\idf4.2_py3.8_env\

(I noticed that in my system I have C:\users\jandi\esp-idf, C:\users\jandi\.espressive, and C:\users\jandi\.espressive.
But not the previous:
c:\users\jandi\appdata\local\programs\python\python37\scripts\
c:\users\jandi\appdata\local\programs\python\python37\
c:\users\jandi\appdata\roaming\python\python37\scripts\
c:\users\jandi\appdata\roaming\python\python37\
Is that correct?

Cleaned and restarted, niow it compiles with this error:

C:\Users\jandi>REM DIR: FCD\ESP\Batch\esp32_build.bat
Building ESP32 wroom switch test ...
The system cannot find the batch label specified - error_missing_requirements
'idf.py' is not recognized as an internal or external command,
operable program or batch file.

Open to suggestions ...

Jan