Close

Release STM8 eForth 2.2.24 - Has it really been a year?

A project log for eForth for cheap STM8S gadgets

Turn cheap modules from AliExpress into interactive development kits!

ThomasThomas 07/04/2020 at 06:158 Comments

"Has it really been a year?" isn't a question - it's the name of the latest release. It's been more than a year since the last release, and there are certainly many reasons for that.

There were so many changes in the build infrastructure ("modular build"), supported by modularization and some generalizations, that there have been no less than four pre-releases.

The motivation behind it was a number of STM8 eForth applications that each required some kind of "board support" in drivers, vocabulary selections, peripherals usage and whatnot while the STM8 eForth core itself hardly changed at all.

On the other hand, configuration options for the following things have improved by a lot:

And feature creep, of course. I'll have to spend some time to document all new features ;-)

Now there is finally some stability as the following POCs showed the desired results:

It's safe to say that STM8 eForth is now quite mature and that it will support a range of applications with little effort. Future developments are planned for exploring options in less frugal systems.

Discussions

Eelco wrote 07/07/2020 at 13:29 point

Thanks for all the all the effort you have put in this project. It has become very useful indeed. I now have several STM8 applications operating.
I recently made a PCB for a solar charge controller to use on hiking trips, designed around STM8L051. It has an i2c OLED display to show voltages and currents and two push buttons to start interrupt tasks. It seemed to work at first, but the interrupt tasks stopped functioning and I still don't know why. But your latest release (2.2.24) seems to have solved the issue.
Btw, is there a way to use openocd/gdb to step trough forth code? I can get assembly translations but link addresses and word names are also translated into mnemonics. Or is there a better way to debug forth?

  Are you sure? yes | no

Thomas wrote 07/07/2020 at 19:20 point

Hi Eelco, it's always a please to see that it can be put to good use, or at least it creates some fun! STM8L is still a big construction area - I'm only now learning the fine print in the manual (clock tree config in the initialization sequence, fun things like ADC tIdle...). 
When I was in the hot debug phase of the STM8 core openocd/gdb was still experimental. Usually I did pin debugging, logic analyzing and other types of sleuthing. Once in a while I used uCsim. Luckily the patterns of execution and stack usage are rather regular and interactive approaches are often successful. The STM8L peripherals are more software driven then the STM8S' and things can get ugly. If you gain experience with openocd/gdb I would love to hear about it.

  Are you sure? yes | no

Travis Bemann wrote 07/06/2020 at 19:02 point

My question is why didn't you just bump it up to 2.3.0?

  Are you sure? yes | no

Thomas wrote 07/06/2020 at 19:11 point

Well, that has something to do with the eForth versions out there - C.H. Ting's last version was "STM8EF, Version 2.1, 13jul10cht" - I pumped that to 2.2 (once) and started counting. Dr. C.H. still "owns" the semantics as long as it's an eForth ;-)

  Are you sure? yes | no

Travis Bemann wrote 07/06/2020 at 16:04 point

That makes me wonder what kinds of feeping creatures I can add to zeptoforth. ;)

  Are you sure? yes | no

Thomas wrote 07/06/2020 at 19:12 point

It shouldn't be too hard to find some. These critters come in all shapes and sizes.

  Are you sure? yes | no

Travis Bemann wrote 07/08/2020 at 15:41 point

My latest feeping creatures are a set of math routines; however, they are not complete, as sin doesn't work (and neither does a bunch of stuff based on it) and ln, well, is slow, so I'm told, but I don't really understand the example code I was given for a better ln at the moment.

  Are you sure? yes | no

Thomas wrote 07/08/2020 at 18:34 point

The STM8 here gets to do humble table lookups and interpolation - that way many problems can be solved using simple '+' and "*/".  Functions of multiple variables, of course, require exponentially more memory, and there is a point where more math should be built in.

  Are you sure? yes | no