Flashing of an LED per timer

Marc Petremann

unread,

Jul 4, 2022, 12:08:54 PM7/4/22

to

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

Zbig

unread,

Jul 4, 2022, 12:44:31 PM7/4/22

to

> 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”.

Zbig

unread,

Jul 4, 2022, 12:59:14 PM7/4/22

to

> 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.

Marc Petremann

unread,

Jul 4, 2022, 1:13:09 PM7/4/22

to

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?

Zbig

unread,

Jul 4, 2022, 2:30:30 PM7/4/22

to

> 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.

Marc Petremann

unread,

Jul 4, 2022, 4:26:23 PM7/4/22

to

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

tp

unread,

Jul 6, 2022, 1:33:47 AM7/6/22

to

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