PWM on a ESP-12F

[Jos-Ven]

Hi, Attracted by the dictionary in ROM feature I am trying to switch from punyforth to cforth. So far, I found the following for an ESP-12F:

Under punyforth the GPIO numbers are the same as their numbers on the stack. Under cforth you have to use an index to get the GPIO number Here are their numbers: 3 constant GPIO0 10 constant GPIO1 4 constant GPIO2 \ sysled 9 constant GPIO3 2 constant GPIO4 1 constant GPIO5 11 constant GPIO9 12 constant GPIO10 6 constant GPIO12 7 constant GPIO13 5 constant GPIO14 8 constant GPIO15 0 constant GPIO16

PWM works under punyforth. After many trials I cannot get it working on an ESP-12F under cforth No PWM signal is shown on my oscilloscope. Even if the numbers from the index are used in car.fth to get to the right GPIO-pin. (using: GPIO13 and GPIO4 ) After: car-init right-forward 20 right-speed

The ESP-12F ends in right-speed at pwm-duty! and shows:

ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset load 0x40100000, len 24952, room 16 tail 8 chksum 0xdf load 0x3ffe8000, len 944, room 0 tail 0 chksum 0x15 load 0x3ffe83b0, len 8, room 8 tail 0 chksum 0xe1 csum 0xe1

and then it reboots 0 GPIO13 gpio-pin! \ returns 0 V on GPIO13 1 GPIO13 gpio-pin! \ returns 3.3 V on GPIO13

Perhaps it is a little thing I overlooked. How can I get PWM working on an ESP-12F if that is possible?

[MitchBradley]

Just FYI, the number pin numbers are chosen to match the numbers on NodeMCU and D1 Mini modules. The numbers used in car.fth match the shield used in this robot car https://www.banggood.com/Geekcreit-2WD-L293D-WIFI-Smart-Robot-Car-With-NodeMCU-Shield-Kit-For-ESP-12E-Based-On-ESP8266-p-995166.html

The unmodified code works, so it is indeed possible that you overlooked something, but I cannot determine what it might be from the English description of your changes. It is best to include your exact code in the form of a patch against the upstream code. That avoids any possible misunderstanding of what you meant, and might show up any other changes that you forgot to mention - or that you thought were safe but were not.

[Jos-Ven]

\ Hi, I used the following code: vocabulary car also car definitions decimal .( car.fth modified: Steering not activated) cr order

\ DoitCar control program

TRUE constant ESP-12F

ESP-12F [IF] 3 constant GPIO0 10 constant GPIO1 4 constant GPIO2 \ sysled 9 constant GPIO3 2 constant GPIO4 1 constant GPIO5 11 constant GPIO9 12 constant GPIO10 6 constant GPIO12 7 constant GPIO13 5 constant GPIO14 8 constant GPIO15 0 constant GPIO16

0 [IF] nopull gpio-output GPIO13 gpio-mode 0 GPIO13 gpio-pin! \ returns 0 V on GPIO13 1 GPIO13 gpio-pin! \ returns 3.3 V on GPIO13 cr ( End test. ) abort [THEN]

[THEN]

4 constant LED-pin GPIO4 constant left-speed-pin \ PWN GPIO13 constant right-speed-pin \ PWM GPIO12 constant left-direction-pin \ PIN_MOTOR_1 GPIO14 constant right-direction-pin \ PIN_MOTOR_2

5 constant left-s1-pin 6 constant left-s2-pin 7 constant right-s1-pin 8 constant right-s2-pin

[ELSE]

0 constant LED-pin 1 constant left-speed-pin 2 constant right-speed-pin 3 constant left-direction-pin 4 constant right-direction-pin 5 constant left-s1-pin 6 constant left-s2-pin 7 constant right-s1-pin 8 constant right-s2-pin

[THEN]

: pwm-on ( pin -- )

r

1023 #1000 r@ pwm-setup

r@ pwm-start 0 r> pwm-duty! ;

: led-on ( -- ) 0 LED-pin gpio-pin! ; : led-off ( -- ) 1 LED-pin gpio-pin! ;

: left-speed ( n -- ) left-speed-pin pwm-duty! ; : right-speed ( n -- ) right-speed-pin pwm-duty! ;

: left-forward ( -- ) 1 left-direction-pin gpio-pin! ; : left-backward ( -- ) 0 left-direction-pin gpio-pin! ; : right-forward ( -- ) 1 right-direction-pin gpio-pin! ; : right-backward ( -- ) 0 right-direction-pin gpio-pin! ;

variable last-left variable last-right variable left-period variable right-period : left-cb ( level -- ) drop timer@ ( this-us ) dup last-left @ - left-period ! ( this-us ) last-left ! ( ) gpio-int-negedge left-s1-pin gpio-enable-interrupt ; : right-cb ( level -- ) drop timer@ ( this-us ) dup last-right @ - right-period ! ( this-us ) last-right ! ( ) gpio-int-negedge right-s1-pin gpio-enable-interrupt ;

0 constant nopull 1 constant pullup

: car-init left-speed-pin pwm-on 0 left-speed right-speed-pin pwm-on 0 right-speed nopull gpio-output LED-pin gpio-mode led-on nopull gpio-output left-direction-pin gpio-mode nopull gpio-output right-direction-pin gpio-mode

\ pullup gpio-interrupt left-s1-pin gpio-mode \ pullup gpio-interrupt right-s1-pin gpio-mode

\ ['] left-cb left-s1-pin gpio-callback! \ gpio-int-negedge left-s1-pin gpio-enable-interrupt

\ ['] right-cb right-s1-pin gpio-callback! \ gpio-int-negedge right-s1-pin gpio-enable-interrupt ; : l. left-period @ .d ; : r. right-period @ .d ;

\ car-init

0 [IF]

test after car-init:

The right channel GPIO13 is a real pwm pin behavour after a reboot and car-init :

right-backward \ no pwm pin low right-forward \ runs but no pwm on pin=low 1 right-speed \ speed is unchanged 20 right-speed \ hangs and reboots after 5 seconds

Before it reboots the ESP-12F shows: ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset load 0x40100000, len 24952, room 16 tail 8 chksum 0xdf load 0x3ffe8000, len 944, room 0 tail 0 chksum 0x15 load 0x3ffe83b0, len 8, room 8 tail 0 chksum 0xe1 csum 0xe1

left-backward \ no pwm pin=low left-forward \ runs but no pwm pin=high 1 left-speed \ speed is unchanged pin=high 20 left-speed \ hangs and reboots after 5 seconds

no pwm means there was no block signal seen on my oscilloscope [THEN]

[MitchBradley]

Okay, I remembered what happened. At some point, the platformpwm API in the nodemcu_firmware code changed, breaking the code that uses it. I tried to fix it, but gave up and switched to a different API. The Forth words for that API have underscores in the names, like pwm_init and pwm_start. There is an example of its use in src/app/filler/app.fth - the words from "init-pwm" through "beep".

Ideally, I would clean up car.fth to use the other API, but it is pretty far down on my list.

[Jos-Ven]

Ideally, I would clean up car.fth to use the other API, but it is pretty far down on my list. No need. Thanks for the hint. I will try that one and report back. Kind regards, Jos

[Jos-Ven]

Unfortunately, that did not solve the problem. Here is the code and what happened: vocabulary buzzer buzzer definitions decimal .( buzzer.fth extracted from src/app/filler/app.fth ) cr order

TRUE constant ESP-12F

ESP-12F [IF] 3 constant GPIO0 10 constant GPIO1 4 constant GPIO2 \ sysled 9 constant GPIO3 2 constant GPIO4 1 constant GPIO5 11 constant GPIO9 12 constant GPIO10 6 constant GPIO12 7 constant GPIO13 5 constant GPIO14 8 constant GPIO15 0 constant GPIO16

0 [IF] nopull gpio-output GPIO13 gpio-mode 0 GPIO13 gpio-pin! \ returns 0 V on GPIO13 1 GPIO13 gpio-pin! \ returns 3.3 V on GPIO13 cr ( End test. ) abort [THEN]

GPIO13 constant buzzer-pin

[ELSE]

8 constant buzzer-pin

[THEN]

: init-pwm ( freq pin -- ) 0 0 pwm_init \ Arguments ignored ( freq pin ) 0 rot pwm_set_freq ( pin ) 0 gpio-output 2 pick gpio-mode ( pin ) pwm_add ;

: init-buzzer ( -- ) #1000 buzzer-pin init-pwm ; : buzzer-on ( -- ) buzzer-pin #500 pwm_set_duty pwm_start ; : buzzer-off ( -- ) buzzer-pin 0 pwm_set_duty pwm_start ; : beep ( ms -- ) buzzer-on ms buzzer-off ;

0 [IF]

buzzer.fth extracted from src/app/filler/app.fth context: buzzer forth root current: buzzer \ After init-pwm ok init-buzzer \ no problem ok buzzer-on \ reboots after 5 seconds

ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset load 0x40100000, len 24952, room 16 tail 8 chksum 0xdf load 0x3ffe8000, len 944, room 0 tail 0 chksum 0x15 load 0x3ffe83b0, len 8, room 8 tail 0 chksum 0xe1 csum 0xe1

\ Other tests: After init-pwm buzzer-pin #1 pwm_set_duty pwm_start \ no pwm GPIO13 low buzzer-pin #5000 pwm_set_duty pwm_start \ no pwm GPIO13 high buzzer-pin #200 pwm_set_duty pwm_start \ no pwm cForth reboots [THEN]

[MitchBradley]

You can try

ok 1 set-printf

to get additional messages from the system. It is possible that WiFi might be trying to connect automatically at the time of the crash. You can turn off WiFi autoconnect with

0 wifi-sta-autoconnect!

You can turn off WiFi entirely with

0 wifi-opmode!

In your first description of the failure, you say "After init-pwm", then "init-buzzer", but that is redundant, because init-buzzer calls init-pwm. Is that a typo? I am assuming that you are using #1000 as the frequency.

[MitchBradley]

The rst-cause message indicates a watchdog timer reset. That generally means that something is using too many CPU cycles, leaving not enough for the network stack. That could be related to the PWM frequency. #1000 works for me without crashing, on a WeMos D1 Mini module, but you could try slower frequencies to see if the PWM interrupt handler is using too many cycles.

[Jos-Ven]

"After init-pwm", then "init-buzzer" Sorry for that typo I only use init-buzzer.

I turned WiFi off with: 0 wifi-opmode ! init-buzzer is changed to: : init-buzzer ( -- ) #500 buzzer-pin init-pwm ; Here is the capture after loading buzzer.fth

buzzer.fth extracted from src/app/filler/app.fth context: buzzer forth root current: buzzer ok 1 set-printf ok init-buzzer ok buzzer-on ok ets Jan 8 2013,rst cause:4, boot mode:(3,7)

wdt reset load 0x40100000, len 24952, room 16 tail 8 chksum 0xdf load 0x3ffe8000, len 944, room 0 tail 0 chksum 0x15 load 0x3ffe83b0, len 8, room 8 tail 0 chksum 0xe1 csum 0xe1

\ No extra messages? It still reboots even after: : init-buzzer ( -- ) #100 buzzer-pin init-pwm ;

[MitchBradley]

I am working on a version that uses the esp8266 RTOS SDK instead of the nodemcu build setup. Perhaps it will work better with PWM on your setup. I have an ok prompt now, so perhaps I am close to being ready to push the code. The build infrastructure is almost identical to how cforth works on ESP32, so I am hopeful that things will go smoothly ...

[quozl]

Ooh, nice. I've been using esp8266 lately with PlatformIO, which also uses the RTOS SDK, but hadn't got around to bringing CForth in because of the nodemcu dependency. Your work may spur that on.

[MitchBradley]

I too am using platformio for an ESP32 CNC project. Getting CForth to compile with pio would be really nice.

[Jos-Ven]

Thank you. Sounds great. I will certainly try it.

[Jos-Ven]

Hi, I saw the new branch at GIT, so I tried it. Here is what happened:

cd cforth/build/esp8266-rtos XTGCCPATH=~/esp/esp-open-sdk/xtensa-lx106-elf/bin/ make CROSS /home/pi/esp/xtensa-lx106-elf/bin/xtensa-lx106-elf- CROSS /home/pi/esp/xtensa-lx106-elf/bin/xtensa-lx106-elf- CC ../../src/cforth/makename.c CPP ../../src/cforth/forth.c MAKENAME TCC ../../src/app/esp8266-rtos/tmain.c make: /home/pi/esp/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc: Command not found make: [../../src/common.mk:30: ttmain.o] Error 127 pi@HPDEBIAN:$ XTGCCPATH=~/esp/esp-open-sdk/xtensa-lx106-elf/bin/ make CROSS /home/pi/esp/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf- TCC ../../src/app/esp8266-rtos/tmain.c TCC ../../src/app/esp8266-rtos/fileio.c TCC ../../src/cforth/forth.c TCC ../../src/cforth/compiler.c TCC ../../src/cforth/syscall.c TCC ../../src/cforth/floatops.c TCC ../../src/cforth/lineedit.c TCC ../../src/cforth/embed/startapp.c TCC ../../src/app/esp8266-rtos/consio.c CC ../../src/cforth/forth.c CC ../../src/cforth/compiler.c CC ../../src/cforth/syscall.c CC ../../src/cforth/floatops.c CC ../../src/cforth/makeccalls.c CC ../../src/cforth/extend.c CC ../../src/cforth/main.c CC ../../src/cforth/io.c CC ../../src/cforth/nullbi.c CC ../../src/cforth/dictfile.c CC ../../src/cforth/mallocl.c CC ../../src/cforth/lineedit.c CC ../../src/cforth/linux-kbd.c MAKING FORTH CC main.o io.o nullbi.o dictfile.o mallocl.o lineedit.o linux-kbd.o forth.o compiler.o syscall.o floatops.o extend.o -lm -o forth CC ../../src/cforth/meta.c CC ../../src/cforth/getc-kbd.c CC meta.o ./meta ../../src/cforth/interp.fth kernel.dic ./forth kernel.dic ../../src/cforth/load.fth .( isn't unique ./makeccalls <../../src/app/esp8266-rtos/extend.c >tccalls.fth CBP=/home/pi/esp/cforth/src ./forth forth.dic tccalls.fth ../../src/app/esp8266-rtos/app.fth CC ../../src/cforth/embed/makebi.c ./makebi app.dic TCC ../../src/cforth/embed/rodict.c TLD tembed.o TCC ../../src/app/esp8266-rtos/extend.c const char version[] = "bc988a9"; const char build_date[] = "2020-10-31 11:07"; TCC tdate.o Linking app.o ... Makefile:3: /home/pi/esp/ESP8266_RTOS_SDK/make/project.mk: No such file or directory make[1]: No rule to make target '/home/pi/esp/ESP8266_RTOS_SDK/make/project.mk'. Stop. make: *** [Makefile:36: forth.elf] Error 2

Could that be solved?

[MitchBradley]

You will have to install the SDK and the compiler. That is the step I have not yet automated. You can either wait for me or try to figure it out yourself from ESP8266 documentation on the internet. Automating it is not "hard", but it is time consuming because there are a lot of failure modes to consider, and each test is time consuming because it requires re-downloading and unpacking one or two big wads of stuff, then possibly recompiling the whole set of libraries. Very tedious work. In the last few days several time-critical tasks got stacked up on top of this work.

[quozl]

Still, it's a fascinating application. :grin:

[andrewtholt]

Hi,

I thought I would give this a try. I got a little further than Jos:

xtensa-lx106-elf-gcc -nostdlib -u call_user_start_cpu0 -Wl,--gc-sections -Wl,-static -Wl,--start-group -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/app_update -lapp_update -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/aws_iot -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/bootloader_support -lbootloader_support -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/cjson -lcjson -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/esp8266 -lesp8266 -L/home/andrewh/esp/ESP8266_RTOS_SDK/components/esp8266/lib -lgcc -lhal -lcore -lnet80211 -lphy -lpp -lsmartconfig -lssc -lwpa -lespnow -lwps -L /home/andrewh/esp/ESP8266_RTOS_SDK/components/esp8266/ld -T esp8266_out.ld -T esp8266_common_out.ld -Wl,--no-check-sections -u call_user_start -T esp8266.rom.ld -T esp8266.peripherals.ld -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/espos -lespos -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/freertos -lfreertos -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/heap -lheap -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/jsmn -ljsmn -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/log -llog -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/lwip -llwip -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/mqtt -lmqtt -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/newlib /home/andrewh/esp/ESP8266_RTOS_SDK/components/newlib/newlib/lib/libc.a /home/andrewh/esp/ESP8266_RTOS_SDK/components/newlib/newlib/lib/libm.a -lnewlib -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/nvs_flash -lnvs_flash -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/pthread -lpthread -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/smartconfig_ack -lsmartconfig_ack -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/spi_flash -lspi_flash -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/spiffs -lspiffs -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/ssl -lssl -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/tcpip_adapter -ltcpip_adapter -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/util -lutil -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/vfs -lvfs -L/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/wpa_supplicant -lwpa_supplicant -lgcc -lstdc++ -lgcov -Wl,--end-group -Wl,-EL -o /home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/esp8266-rtos.elf -Wl,-Map=/home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/esp8266-rtos.map /home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/esp8266/libesp8266.a(startup.o):(.literal.user_init_entry+0x30): undefined reference to app_main' /home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/esp8266/libesp8266.a(startup.o): In functionuser_init_entry': /home/andrewh/esp/ESP8266_RTOS_SDK/components/esp8266/source/startup.c:63: undefined reference to `app_main' collect2: error: ld returned 1 exit status make[1]: [/home/andrewh/Source/Forth/ESP8266_RTOS_SDK/make/ project.mk:406: /home/andrewh/Source/Forth/cforth-mitch/build/esp8266-rtos/sdk_build/build/esp8266-rtos.elf] Error 1 make: [Makefile:36: forth.elf] Error 2

On Sat, 31 Oct 2020 at 17:22, Mitch Bradley notifications@github.com wrote:

You will have to install the SDK and the compiler. That is the step I have not yet automated. You can either wait for me or try to figure it out yourself from ESP8266 documentation on the internet. Automating it is not "hard", but it is time consuming because there are a lot of failure modes to consider, and each test is time consuming because it requires re-downloading and unpacking one or two big wads of stuff, then possibly recompiling the whole set of libraries. Very tedious work. In the last few days several time-critical tasks got stacked up on top of this work.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MitchBradley/cforth/issues/64#issuecomment-719962937, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYVWSLGMJHQH5IC7UWWJ23SNRBWLANCNFSM4S6FPILA .

[MitchBradley]

Andrew's result is easy to fix - I just have to check in a couple of files that I forgot to stage.... Done

[MitchBradley]

I am working on the SDK install automation. It is substantially similar to the ESP32 version, but even so, testing it is quite tedious. Just downloading the SDK .zip file will take something like 10 minutes, and then the toolchain will need to be downloaded, and every mistake may mean starting over...

[MitchBradley]

Okay, the latest version of the WIP branch automates the toolchain installation.

There is a potential problem with a python version glitch in the SDK. See https://github.com/espressif/ESP8266_RTOS_SDK/issues/999 for a workaround.

[Jos-Ven]

Hi Mitch, That is great news! Thank you. So, I immediately tried it. It seems there is still a little problem. Here is what happened after cloning:

pi@HPDEBIAN:$ cd cforth/build/esp8266-rtos pi@HPDEBIAN:$ XTGCCPATH=~/esp/esp-open-sdk/xtensa-lx106-elf/bin/ make Getting ESP8266_RTOS_SDK (cd /home/pi/esp \ && git clone https://github.com/espressif/ESP8266_RTOS_SDK.git \ && python -m pip install --user -r /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt \ ) Cloning into 'ESP8266_RTOS_SDK'... remote: Enumerating objects: 194, done. remote: Counting objects: 100% (194/194), done. remote: Compressing objects: 100% (142/142), done. remote: Total 28177 (delta 74), reused 108 (delta 47), pack-reused 27983 Receiving objects: 100% (28177/28177), 61.17 MiB | 6.48 MiB/s, done. Resolving deltas: 100% (16288/16288), done. Requirement already satisfied: setuptools in /usr/lib/python2.7/dist-packages (from -r /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt (line 4)) (40.8.0) Requirement already satisfied: click>=5.0 in /home/pi/.local/lib/python2.7/site-packages (from -r /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt (line 8)) (7.1.2) Requirement already satisfied: pyserial>=3.0 in /usr/lib/python2.7/dist-packages (from -r /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt (line 9)) (3.4) Requirement already satisfied: future>=0.15.2 in /home/pi/.local/lib/python2.7/site-packages (from -r /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt (line 10)) (0.18.2) Requirement already satisfied: cryptography>=2.1.4 in /usr/lib/python2.7/dist-packages (from -r /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt (line 11)) (2.6.1) Requirement already satisfied: pyparsing<2.4.0,>=2.0.3 in /home/pi/.local/lib/python2.7/site-packages (from -r /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt (line 12)) (2.3.1) Requirement already satisfied: pyelftools>=0.22 in /home/pi/.local/lib/python2.7/site-packages (from -r /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt (line 13)) (0.27) CC ../../src/cforth/makename.c CPP ../../src/cforth/forth.c MAKENAME TCC ../../src/app/esp8266-rtos/tmain.c TCC ../../src/app/esp8266-rtos/fileio.c TCC ../../src/cforth/forth.c TCC ../../src/cforth/compiler.c TCC ../../src/cforth/syscall.c TCC ../../src/cforth/floatops.c TCC ../../src/cforth/lineedit.c TCC ../../src/cforth/embed/startapp.c TCC ../../src/app/esp8266-rtos/consio.c CC ../../src/cforth/forth.c CC ../../src/cforth/compiler.c CC ../../src/cforth/syscall.c CC ../../src/cforth/floatops.c CC ../../src/cforth/makeccalls.c CC ../../src/cforth/extend.c CC ../../src/cforth/main.c CC ../../src/cforth/io.c CC ../../src/cforth/nullbi.c CC ../../src/cforth/dictfile.c CC ../../src/cforth/mallocl.c CC ../../src/cforth/lineedit.c CC ../../src/cforth/linux-kbd.c MAKING FORTH CC main.o io.o nullbi.o dictfile.o mallocl.o lineedit.o linux-kbd.o forth.o compiler.o syscall.o floatops.o extend.o -lm -o forth CC ../../src/cforth/meta.c CC ../../src/cforth/getc-kbd.c CC meta.o ./meta ../../src/cforth/interp.fth kernel.dic ./forth kernel.dic ../../src/cforth/load.fth .( isn't unique ./makeccalls <../../src/app/esp8266-rtos/extend.c >tccalls.fth CBP=/home/pi/esp/cforth/src ./forth forth.dic tccalls.fth ../../src/app/esp8266-rtos/app.fth CC ../../src/cforth/embed/makebi.c ./makebi app.dic TCC ../../src/cforth/embed/rodict.c TLD tembed.o TCC ../../src/app/esp8266-rtos/extend.c const char version[] = "5799a18-dirty"; const char build_date[] = "2020-11-03 07:36"; TCC tdate.o Linking app.o ... Python requirements from /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt are satisfied. GENCONFIG App "esp8266-rtos" version: esp32-v1.0-120-g5799a18 WARNING: Toolchain version is not supported: crosstool-ng-1.22.0-60-g37b07f6f-dirty Expected to see version: esp-2020r3-49-gd5524c1 Please check ESP-IDF setup instructions and update the toolchain, or proceed at your own risk. WARNING: Compiler version is not supported: 4.8.5 Expected to see version(s): 8.4.0 Please check ESP-IDF setup instructions and update the toolchain, or proceed at your own risk. CC build/bootloader/main/bootloader_start.o AR build/bootloader/main/libmain.a CC build/bootloader/bootloader_support/src/efuse.o CC build/bootloader/bootloader_support/src/bootloader_flash.o CC build/bootloader/bootloader_support/src/flash_qio_mode.o CC build/bootloader/bootloader_support/src/secure_boot_signatures.o CC build/bootloader/bootloader_support/src/bootloader_init.o CC build/bootloader/bootloader_support/src/bootloader_common.o CC build/bootloader/bootloader_support/src/secure_boot.o CC build/bootloader/bootloader_support/src/bootloader_clock.o CC build/bootloader/bootloader_support/src/bootloader_random.o CC build/bootloader/bootloader_support/src/flash_partitions.o CC build/bootloader/bootloader_support/src/esp_image_format.o CC build/bootloader/bootloader_support/src/bootloader_sha.o CC build/bootloader/bootloader_support/src/flash_encrypt.o CC build/bootloader/bootloader_support/src/bootloader_utility.o AR build/bootloader/bootloader_support/libbootloader_support.a CC build/bootloader/spi_flash/src/spi_flash.o CC build/bootloader/spi_flash/src/spi_flash_raw.o CC build/bootloader/spi_flash/port/port.o AR build/bootloader/spi_flash/libspi_flash.a CC build/bootloader/log/log.o AR build/bootloader/log/liblog.a CC build/bootloader/esp8266/source/ets_printf.o CC build/bootloader/esp8266/source/crc.o CC build/bootloader/esp8266/source/esp_fast_boot.o AR build/bootloader/esp8266/libesp8266.a LD build/bootloader/bootloader.elf esptool.py v2.4.0 Building partitions from /home/pi/esp/cforth/build/esp8266-rtos/sdk_build/partitions.csv... WARNING: Missing submodule components/json/cJSON... Attempting 'git submodule update --init components/json/cJSON' in esp-idf root directory... Submodule 'components/json/cJSON' (https://github.com/DaveGamble/cJSON.git) registered for path 'components/json/cJSON' Cloning into '/home/pi/esp/ESP8266_RTOS_SDK/components/json/cJSON'... Submodule path 'components/json/cJSON': checked out '3c8935676a97c7c97bf006db8312875b4f292f6c' WARNING: Missing submodule components/lwip/lwip... Attempting 'git submodule update --init components/lwip/lwip' in esp-idf root directory... Submodule 'components/lwip/lwip' (https://github.com/espressif/esp-lwip.git) registered for path 'components/lwip/lwip' Cloning into '/home/pi/esp/ESP8266_RTOS_SDK/components/lwip/lwip'... Submodule path 'components/lwip/lwip': checked out '4fd84abace0cd8a5a709c194fa54afb3cd39b3f7' WARNING: Missing submodule components/mbedtls/mbedtls... Attempting 'git submodule update --init components/mbedtls/mbedtls' in esp-idf root directory... Submodule 'components/mbedtls/mbedtls' (https://github.com/espressif/mbedtls.git) registered for path 'components/mbedtls/mbedtls' Cloning into '/home/pi/esp/ESP8266_RTOS_SDK/components/mbedtls/mbedtls'... Submodule path 'components/mbedtls/mbedtls': checked out '9ef92c551eb8d92677034c3ec8078a8076febf41' WARNING: Missing submodule components/mqtt/esp-mqtt... Attempting 'git submodule update --init components/mqtt/esp-mqtt' in esp-idf root directory... Submodule 'components/mqtt/esp-mqtt' (https://github.com/espressif/esp-mqtt.git) registered for path 'components/mqtt/esp-mqtt' Cloning into '/home/pi/esp/ESP8266_RTOS_SDK/components/mqtt/esp-mqtt'... Submodule path 'components/mqtt/esp-mqtt': checked out '566b0349843edaedce9ad958bd47cd328b66ffbf' App "esp8266-rtos" version: esp32-v1.0-120-g5799a18 CC sdk_build/build/app_update/esp_ota_ops.o CC sdk_build/build/app_update/esp_app_desc.o AR sdk_build/build/app_update/libapp_update.a CC sdk_build/build/bootloader_support/src/efuse.o CC sdk_build/build/bootloader_support/src/bootloader_flash.o CC sdk_build/build/bootloader_support/src/flash_qio_mode.o CC sdk_build/build/bootloader_support/src/secure_boot_signatures.o CC sdk_build/build/bootloader_support/src/bootloader_init.o CC sdk_build/build/bootloader_support/src/bootloader_common.o CC sdk_build/build/bootloader_support/src/secure_boot.o CC sdk_build/build/bootloader_support/src/bootloader_clock.o CC sdk_build/build/bootloader_support/src/bootloader_random.o CC sdk_build/build/bootloader_support/src/flash_partitions.o CC sdk_build/build/bootloader_support/src/esp_image_format.o CC sdk_build/build/bootloader_support/src/bootloader_sha.o CC sdk_build/build/bootloader_support/src/flash_encrypt.o CC sdk_build/build/bootloader_support/src/bootloader_utility.o AR sdk_build/build/bootloader_support/libbootloader_support.a AR sdk_build/build/coap/libcoap.a CC sdk_build/build/console/linenoise/linenoise.o /home/pi/esp/ESP8266_RTOS_SDK/components/console/linenoise/linenoise.c: In function 'linenoiseEdit': /home/pi/esp/ESP8266_RTOS_SDK/components/console/linenoise/linenoise.c:883:9: error: implicit declaration of function 'fbufsize' [-Werror=implicit-function-declaration] if (fbufsize(stdout) > 0) { ^ /home/pi/esp/ESP8266_RTOS_SDK/components/console/linenoise/linenoise.c: At top level: cc1: warning: unrecognized command line option "-Wno-frame-address" [enabled by default] cc1: some warnings being treated as errors make[2]: [/home/pi/esp/ESP8266_RTOS_SDK/make/component_wrapper.mk:292: linenoise/linenoise.o] Error 1 make[1]: [/home/pi/esp/ESP8266_RTOS_SDK/make/project.mk:571: component-console-build] Error 2 make: *** [../../src/app/esp8266-rtos/targets.mk:91: sdk_build/build/esp8266-rtos.elf] Error 2

---

Changing pyparsing>=2.0.3 in the file ESP8266_RTOS_SDK/requirements.txt and running: python -m pip install --user -r ESP8266_RTOS_SDK/requirements.txt did not help.

pi@HPDEBIAN:$ python --version Python 2.7.16

[MitchBradley]

You are using the wrong C compiler, per these messages from your output:

WARNING: Toolchain version is not supported: crosstool-ng-1.22.0-60-g37b07f6f-dirty
Expected to see version: esp-2020r3-49-gd5524c1
Please check ESP-IDF setup instructions and update the toolchain, or proceed at your own risk.
WARNING: Compiler version is not supported: 4.8.5
Expected to see version(s): 8.4.0

The final error message

cc1: warning: unrecognized command line option "-Wno-frame-address" [enabled by default]
cc1: some warnings being treated as errors

Is exactly the sort of problem that can happen when you try to compile new source code with an old compiler.

The file src/app/esp8266-rtos/sdk.mk is supposed to install the correct compiler. I'm not sure why that did not work. I wonder if you have any overrides in your environment that are forcing it to use your old compiler instead of installing the new one.

[Jos-Ven]

Thank you for the explanation. That is hard to tell for me. For the non-forth parts I am only a kind of monkey trying to follow the installation instructions. Before I tried to switch to cforth I installed punyforth. That also involves the installation of the toolchain. Then I did an attempt to install the compiler after the first attempt of installing esp8266-rtos failed. Perhaps somewhere down this road a mistake was made. I just tried to update the compiler following the page at: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/linux-setup-scratch.html That did not help. Is there a simple way to force an installation of the right compiler?

[MitchBradley]

The right compiler is probably already installed, because sdk.mk installs it automatically. I suspect that the problem is caused by your previous install. The "linux-setup-scratch" instructions say: export PATH="$HOME/esp/xtensa-esp32-elf/bin:$PATH" That has the effect of putting the old compiler at the beginning of the search path, where it will be found first, before it finds the new compiler. I just pushed a change that might solve the problem.

[Jos-Ven]

Sorry, the warning and the error are still there after cloning and XTGCCPATH=~/esp/esp-open-sdk/xtensa-lx106-elf/bin/ make

[MitchBradley]

Just type make. The XTGCCPATH= thing is overriding the compiler.

[Jos-Ven]

Ok, now I get:

pi@HPDEBIAN:$ cd /home/pi/esp/cforth/build/esp8266-rtos pi@HPDEBIAN:$ make CC ../../src/cforth/makename.c CPP ../../src/cforth/forth.c MAKENAME TCC ../../src/app/esp8266-rtos/tmain.c /home/pi/esp/toolchain-gcc8_4_0-esp-2020r3/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc: 1: /home/pi/esp/toolchain-gcc8_4_0-esp-2020r3/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc: Syntax error: "(" unexpected make: *** [../../src/common.mk:30: ttmain.o] Error 2 pi@HPDEBIAN:$

[MitchBradley]

Uh, are you using a 32-bit host computer? That message looks like what you get if you try to run a 64-bit executable on a 32-bit computer. I didn't put in support for installing 32-bit compilers because I thought that the steam power to run them was no longer available.

[Jos-Ven]

Yes, I am not sure if a 64 bits linux OS is able to run on my PC. If that is the problem I will try a 64 bits version.

[MitchBradley]

You can change src/app/esp8266-rtos/sdk.mk to install the 32 bit compiler:

Replace the line XTGCC_ARCHIVE = $(TOOLPREFIX)-$(XTGCC_VERSION)-linux-amd64.tar.gz with XTGCC_ARCHIVE = $(TOOLPREFIX)-$(XTGCC_VERSION)-linux-i686.tar.gz

You will then need to remove the directory /home/pi/esp/toolchain-gcc8_4_0-esp-2020r3 and re-run make. It should then install the 32-bit toolchain.

[Jos-Ven]

Thank you! The 1st make succeeded and ended with: LD sdk_build/build/esp8266-rtos.elf esptool.py v2.4.0 Python requirements from /home/pi/esp/ESP8266_RTOS_SDK/requirements.txt are satisfied. To flash all build output, run 'make flash' or: python /home/pi/esp/ESP8266_RTOS_SDK/components/esptool_py/esptool/esptool.py --chip esp8

The make download failed. Here is what happened: pi@HPDEBIAN:$ sudo COMPORT=/dev/ttyUSB0 make download make: *** No rule to make target 'download'. Stop. pi@HPDEBIAN:$

[MitchBradley]

Use "make flash" instead of "make download"

[MitchBradley]

The next problem that you will encounter is that the PWM driver is broken in the latest version of ESP8266_RTOS_SDK. I have managed to make it work by reverting to an older version. I am still working on the scripting to use that version.

[Jos-Ven]

That works! I will wait patiently for your next update. Many thanks for all the efforts.

[MitchBradley]

I found the source of the PWM problem and submitted this ticket https://github.com/espressif/ESP8266_RTOS_SDK/issues/1001 . As time permits, I will add a patch for the problem in the CForth code, as we wait for espressif to fix the problem in the SDK.

[andrew-playbrush]

Just thought I would let you know.

ESP8266-rtos is working nicely for me.

I have already extended it by adding the nvs (key value database) I need for a hobby project, saved me having to write one.

Regards, Andrew

[MitchBradley]

I pushed improvement to the WIP branch, with toolchain and SDK auto-installation, and SDK patches to fix the PWM bug.

[Jos-Ven]

Thank you. After cloning I get the following:

pi@HPDEBIAN:$ make CC ../../src/cforth/makename.c CPP ../../src/cforth/forth.c MAKENAME TCC ../../src/app/esp8266-rtos/tmain.c /bin/bash: /xtensa-lx106-elf-gcc: No such file or directory make: *** [../../src/common.mk:30: ttmain.o] Error 127

The line: XTGCC_ARCHIVE = $(TOOLPREFIX)-$(XTGCC_VERSION)-linux-amd64.tar.gz is gone in src/app/esp8266-rtos/sdk.mk Removing /home/pi/esp/toolchain-gcc8_4_0-esp-2020r3 did also not help.

[MitchBradley]

The new version automatically installs ESP_RTOS_SDK, and in the process of doing so, uses scripts inside the SDK to install the toolchain and find where it has been installed. Furthermore, that auto-installation process also applies a patch to the SDK to fix the bug that I found in its PWM driver.

My guess is that your problem will be solved if you remove (or move to another location) the copy of the SDK that you have already installed, so that the auto-installation process can perform the steps above. The SDK should be the directory ESP8266_RTOS_SDK, in the same toplevel directory that contains cforth.

[MitchBradley]

In an earlier post, I complained about how tedious it can be to automate and test toolchain installation. As you can see, I wasn't wrong about that. There are many steps involved, most of which depend in intricate fashion on what is already present on the system. Dealing with existing partial installations can be quite tricky. Many (most?) open source projects eventually die because the author cannot keep spending inordinate amounts of time doing uncompensated grunt work.

[Jos-Ven]

Hi Mitch, you are right. As soon as I moved to another location the installation went smoothly. The missing packs were downloaded and installed. Nice!

PWM is still a problem When I look a bit closer the words: nopull gpio-output pwm_add pwm_set_freq and pwm_init are not present in the dictionary.

The system led does not shine when 0 1 4 gpio-mode 0 4 gpio-pin! 0 1 2 gpio-mode 0 2 gpio-pin! are used.

The only SDK I found in the directory where now cforth is located is ESP8266_RTOS_SDK In the old locations there is also: esp-open-sdk

In an earlier post, I complained about how tedious it can be to automate and test toolchain installation. I am impressed that you managed to do so.

[MitchBradley]

Look at src/app/esp8266-rtos/test-pwm.fth

[MitchBradley]

Regarding the gpios, look in the file src/app/esp8266-rtos/gpio.fth for pin names. There are native names like GPIO5 and NodeMCU/D1Mini names like Pin-D2 .

To setup a GPIO, instead of gpio-mode, use one of:

    gpio-is-output ( i.gpio# -- )
    gpio-is-output-open-drain ( i.gpio# -- )
    gpio-is-input ( i.gpio# -- )
    gpio-is-input-pullup ( i.gpio# -- )
    gpio-is-input-pulldown ( i.gpio# -- )

You can still use gpio-pin@ and gpio-pin! as before. There is also a new function gpio-toggle ( gpio# -- )

[Jos-Ven]

Thanks again. PWM works! Also thanks you for GPIO.fth and the hint you sent. It seems PWM is solved. I still need to test I2C and the previous known tcpnew.fth As soon as the tests are complete than I will report that to you. Kind regards, Jos

[MitchBradley]

The tcp stuff will need to follow the esp32 version. The old esp8266 version uses the horrible callback interface from the NONOS SDK.

[MitchBradley]

A recent checkin fixes a problem in which some GPIOs would work and others would not.

[MitchBradley]

The latest checkin has working HTTP. See src/app/esp8266-rtos/test-http.fth . You will need to configure the wifi SSID and password as shown in that file

[MitchBradley]

I2C is working as of the recent checkin. See test-oled.fth for an example.

[Jos-Ven]

Thank you for all the updates.

The GPIOpins and I2C work. A test with a VL53L10X returned correctly: Model VL53L10X:ee Revision:10

I could not connect to my wifi router. When I paste SSID and the password from the router in: :noname " ssid" ; to wifi-sta-ssid :noname " 9char-password" ; to wifi-sta-password

Then I got the following after wifi-sta-on:

ok wifi-sta-on abort" Cannot connect to WiFi" I (26540) system_api: Base MAC address is not set, read default base MAC addresE I (26543) system_api: Base MAC address is not set, read default base MAC addresE phy_version: 1163.0, 665d56c, Jun 24 2020, 10:00:08, RTOS new I (26599) phy_init: phy ver: 1163_0 I (28791) wifi:state: 0 -> 2 (b0) I (28793) wifi:state: 2 -> 3 (0) I (28794) wifi:state: 3 -> 0 (1200) Then it keeps repeating the wifi:state.

[MitchBradley]

I checked in a change to allow accepting weaker authentication modes. Since I have not the slightest idea about how your WiFi access point is configured, that is the best that I can do.

If the new version does not work, you could try running some of the wifi example programs in ESP8266_RTOS_SDK to see if they work.

[Jos-Ven]

Hi, The following was found: When my router is set to 11bgn mixed mode there is no problem. As soon as I switch to the mode 11 only then the ESP-12F cannot connect. In the security settings WPA2-PSK and AES are used. Note: In the previous /esp8266 version that was not a problem for station-connect. ipaddr@ .ipaddr also work. The 11bgn mixed mode on my router is all right for me.