Hello
LED flashing is arguably the very first development project that most ARDUINO or ESP32 programmers try. If this exercise is interesting, however, it is interesting to see its variant which exploits the timers on ESP32.
https://esp32.arduino-forth.com/article/timers_blink
BR

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le lundi 4 juillet 2022 à 18:59:14 UTC+2, Zbig a écrit :

Not knowing definition of LED_STATE I have no idea, how to „marry” that „state” to present „led”.

Oh, it's VALUE; so (probably) nothing more we can do here.

Hello,
The purpose of the article is not to make "good FORTH code", but FORTH code as readable as possible.
The interest of the article is above all to show the interest of timers on ESP32forth....
Are you programming with ESP32forth?
If so, do you share your contributions somewhere, like on GitHub for example?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Not knowing definition of LED_STATE I have no idea, how to „marry” that „state” to present „led”.

Oh, it's VALUE; so (probably) nothing more we can do here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

LED flashing is arguably the very first development project that most ARDUINO or ESP32 programmers try. If this exercise is interesting, however, it is interesting to see its variant which exploits the timers on ESP32.
https://esp32.arduino-forth.com/article/timers_blink

18 constant myLED
0 value LED_STATE

: led.on ( -- )
HIGH myLED pin
-1 to LED_STATE
;

: led.off ( -- )
LOW myLED pin
0 to LED_STATE
;

„Avoid hyphenated words” („Thinking Forth”). So the better words would be, for example:

: on -1 HIGH ;
: off 0 LOW ;
: led ( ? state -- )
myLED pin
to LED_STATE
;
And from now on you'll use elegant:
on led
off led

If HIGH is the same as -1 -- of course it can be simplified further, like:
: on -1 ;
: off 0 ;
: led ( ? -- )
dup
myLED pin
to LED_STATE
;
Not knowing definition of LED_STATE I have no idea, how to „marry” that „state” to present „led”.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The purpose of the article is not to make "good FORTH code", but FORTH code as readable as possible.

What can be more readable than good Forth code? You mean: bad Forth code is more readable?

The interest of the article is above all to show the interest of timers on ESP32forth....
Are you programming with ESP32forth?

Just wrote my first program in ESP32forth -- so yes, it seems I do.

If so, do you share your contributions somewhere, like on GitHub for example?

No, because you published your example here, not on GitHub.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le lundi 4 juillet 2022 à 20:30:30 UTC+2, Zbig a écrit :

The purpose of the article is not to make "good FORTH code", but FORTH code as readable as possible.

What can be more readable than good Forth code? You mean: bad Forth code is more readable?

The interest of the article is above all to show the interest of timers on ESP32forth....
Are you programming with ESP32forth?

Just wrote my first program in ESP32forth -- so yes, it seems I do.

If so, do you share your contributions somewhere, like on GitHub for example?

No, because you published your example here, not on GitHub.

My codes are on Github: https://github.com/MPETREMANN11/ESP32forth/blob/main/timers/blink.txt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 04 Jul 2022 09:08:53 -0700, Marc Petremann wrote:

Hello LED flashing is arguably the very first development project that
most ARDUINO or ESP32 programmers try. If this exercise is interesting,
however, it is interesting to see its variant which exploits the timers
on ESP32.
https://esp32.arduino-forth.com/article/timers_blink BR

Hi All, it's been a few years since I last posted here...

Good to see some embedded tips, especially related to using hardware
timers compared to the more common spinner blocking delays.

Lately I have been experimenting with using a polled hardware timer to
more closely match the delay times of a tethered forth in emulation mode compared to a binary image on the target. Why polled? because the emulator cannot use interrupts.

In actual use the emulator, (Mecrisp-Stellaris on a STM32F407 Discovery
Board running Mecrisp-Across.fs) can be up to several times slower than
the MSP430 Target running the final compiled binary.

https://mecrisp-across-folkdoc.sourceforge.io


--
To me, good Embedded Forth code is all about readability, traceability and maintainability with respect to the *hardware*.
Maintainer: https://mecrisp-stellaris-folkdoc.sourceforge.io and https:// mecrisp-across-folkdoc.sourceforge.io

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)