So I spent this sunday afternoon doing some field research and soldering in order to be able to drive a #LEGO #train #motor via #ESP32forth using a #L293D motor driver and a nifty #rechargable #9V Lo-Ion #battery that holds a whooping 1300 mAh. I use this to power the #ESP32 (with a #LM2596 regulator) and the motor (via L293D).
And the best thing: the setup works, the code works and yes the motor runs.
The window pane thermometer 2.0 - now featuring the #M5Stack #Cardputer running my #ESP32forth code ... (moving pictures!)
lots of fun here ...
I evenutally got myself a #M5Stack #Cardputer and installed the ESP32forth variant for it right away ...
This little device is quite amazing! Now I can tinker with #ESP32forth everywhere!!
.oO(my wife's gonna hate it!)
In Germany there we have this saying that talking about music is like dancing to architecture.
In a simillar way, I find it rather difficult to describe to people why I prefer coding in a language which is usually considererd one or all of the following: old / outdated / dead / feeding-to-a-niche / hard-to-understand - but I will give it a last try:
One of the things I like about the Forth programming language - in this case #esp32forth - is that you can easily add hardware specific words from the Arduino library.
I was missing analogWrite, analogWriteFrequency and analogWriteResolution so I just added those.
But aside from that, using Forth on the ESP32 makes prototyping so much easier: you save yourself the endless cycle of "code, compile, upload, test, code..." since you can actually write your code interactively on the device (using either the Block Editor or the Visual Editor).
Being able to remotely connect to this development environment via either #Http or #Telnet just rounds it up for me.
Maybe it's because it brings me back to the times when I was coding BASIC on my bedsit, but maybe it really is because it is a very efficient way to code ... 🤷♂️
Yay! 🥳
I just made my #TTGO #VGA32 use the #esp32forth variant with #fabgl enabled (a.k.a. #ESP32forthStation ) *and* properly recognize the onboard #sdcard !!
In the end the modification was quite simple, I had to tell the TTGO VGA32 the proper SPI pin configuration for the sd card via SPI.begin() and added that code to the SD.begin word definition.
By default, SD.begin would use the #esp32 default SPI pin configuration which is not being used on the TTGO VGA32 (see TTGO VGA32 pinout).
EDIT: but it took me hours to realize that I used a video resolution which consumed too much memory, causing each attempt to do a "SD.begin" in ESP32forth to fail ... lowering the resolution to 640x200@60 did do the trick! 😎
Time to go to bed ... 🥱
One of the things that annoyed me when using #ESP32forth is that with recent versions of the #ArduinoIDE it is no longer possible to use plugins for uploading additional files to the #SPIFFS partition of the ESP32.
There is a workaround solution for ESP32forth that allows a user to copy-paste code into the terminal, which is then stored on the filesystem - but that didn't convince me.
So I spent the last two days tinkering with mkspiffs and esptool.py and finally found a way to not only upload files to the SPIFFS partition but also dumping files *from* that partition back to your computer. All from the command line, no ArduinoIDE and plugins required - see here:
The little adaption of the #Snake game that I ported from the example on the #EasyForth website also runs in a terminal on #ESP32forth - I had to use a different implementation for the random number generation, but now it works!