Skip to content
  • 2.2.26
  • e9f7a61
  • Compare
    Choose a tag to compare
    Search for a tag
  • 2.2.26
  • e9f7a61
  • Compare
    Choose a tag to compare
    Search for a tag

@TG9541 TG9541 released this Oct 23, 2020

About the release

This is release is very much about fully supporting STM8L devices (i.e. the likes of STM8L051F3, STM8L151C6 or STM8L152R8).

While STM8S peripherals are simple and the pin and clock configuration is trivial, the STM8L designers clearly had both "larger" and "many more" spec sheets. The "many more" one can be seen in the number of configuration dependencies the programmer has to infer when trying to use one of the many features of the peripherals. For STM8 eForth this means that things that were implicit or hard-coded needed to be restructured and tested. The device families STM8S and STM8L now are on equal footing and the generalizations gained when adding STM8L support now also makes supporting STM8S variants easier.

This release (finally) adds support for the low-end RM0013 STM8L device STM8L101, and, at the other end of the spectrum, STM8L "High density" devices like STM8L152R8 (also STM8L162 devices can be expected to work).

Configuration folders with docs for "Low", "Medium" and High density" devices in both families have been added. Based on the hypothesis that memory and peripheral properties are the same across a range of package and memory specs variants the devices for which these "6+1 device types" should work were listed. This should be seen as an aid to the user as to see clear in the "small world" of STM8 devices. There is no evidence that it's much more complicated than that. If you have reason to believe that a device doesn't fit in this simple schema please file an issue.

Devices in the following device families have not been examined:

  • STM8L RM0312 family touch sensing MCUs, e.g. STM8TL5xxx
  • STM8S STLUX lighting MCUs and STNRGxxxA power conversion MCUs (including wireless charging STWBC)

It shouldn't be big problem to get a Forth console on any of these devices, but for using the specialized peripherals it's maybe a good idea to apply ST's proprietary C-code libraries and configuration tools.

New Features

STM8L: Peripheral addresses

New or improved register address (efr-) files for e4thcom and codeload.py are now available. @Eelkhoorn first provided an improved STM8L151.efr file, and in #342 efr files for specific STM8L variants were created.

STM8L "Medium" and "High density" should work with the generic STM8L151.efr.

Peripheral register addresses of RM0031 "Low density" devices differ from STM8L "Medium density" and "High density" devices. Constants should be imported with \res MCU: STM8L051.

The final group is RM0013 "Low density" devices like STM8L101F3 or STM8L001J3: here \res MCU: STM8L101 should be used.

STM8 Timers and interrupts

Some applications, like XY-LPWM, need to use a different timer than TIM2 for the background task.
Issue #369 adds this option to the STM8L device families.

By setting BG_USE_TIM3 = 1 in globconf.inc the Background task (BG) timer will use TIM3 instead of TIM2 in STM8L "Low density" devices. STM8L "Medium" and "High density" devices can also set BG_USE_TIM1 = 1 for using TIM1. There is currently no support for TIM5 in STM8L "High density" devices.

A conflict between a simulated serial port and the background task in an STM8L051F3 device was discovered and fixed in issue #340 STM8L interrupt priority of BG task.

STM8S UART and STM8L USART configurations

STM8L devices in the RM0031 family support USART GPIO function remapping. This can easily lead to a mismatch between the USART GPIO mapping an the GPIO output initialization.

The following issues provide a solution:

  • #358 USART options for STM8L High Density devices
  • #364 STM8L: general options for USART configuration
  • #360 half-duplex USART console option for STM8L devices

Common elements in boardcore.inc of all STM8L devices, together with docs in the target folders, that also show the default mapping, make the configuration easy.

STM8S "Low" and "High density" devices use matching configuration items. STM8L152R8 has the most options.

Configuration of STM8 memory variants

Issue #330 made EEPROMBASE, the EEPROM start address, a target.inc configuration item which can be used to write device independent code.

The new feature was used in issue #339 which removed hard-coded addresses in EEALIAS so that offloading a part of the dictionary to the EEPROM now works for both STM8S and STM8L devices. STM8L "Low density" devices have a much smaller EEPROM than those in the STM8S family, of course.

Issue #355 introduced a PAGESIZE constant so that device independent code for "Flash ROM page write" can load it with #require PAGESIZE.

Note that memory variants should be defined in the configuration folder's target.inc based on the device type (STM8L or STM8S, "Low", "Medium" or "High density"). If you're engineering a product you should care for selecting the device with the right specs. For casual use memory specs are most likely not that important (if there is evidence of the opposite please share it and file an issue).

Make target for OpenOCD / stm8-gdb

OpenOCD and stm8-gdb can be of great help, especially when dealing with new devices. Issue #350 added support for an ELF target so that binaries that can be loaded into stm8-gdb can be built with make BOARD=<boardname> debug.

There are notes about using OpenOCD and stm8-gdb is in this Gist which also contain OpenOCD target configuration files for STM8L101 and STM8L051 "Low density" devices.

Experimental debug console

At times it's interesting to examine the state of a Forth program in the middle of the execution. Issue #372 introduces a very simple debug console with the words OUTER and BYE.

Here is a simple example:

#require BYE

: test ( n -- )
  FOR
    I DUP . 2 MOD 0= IF
      CR ."  Break - mind the stack - continue with BYE" CR
      OUTER THEN
  NEXT ."  done"
;

A debug session on a STM8S003F3, where a FOR ... NEXT loop is terminated manually by changing the loop counter on the return stack ($3FF growing down), looks like this:

66 7 test 7 6
 Break - mind the stack - continue with BYE
$03F0 10 dump
 3F0  23  0  0  A 8D 1E 8D 12  1 1D  0  6 8D 1E 8D 12  1_______________ ok
bye 5 4      
 Break - mind the stack - continue with BYE
$03F0 10 dump
 3F0  23  0  0  A 8D 1E 8D 12  1 1D  0  4 8D 1E 8D 12  1_______________ ok
$3FA ? 4 ok
0 $3FA ! ok  
bye done ok
. 66 ok

Note that a single misspelled word will clear both the data and the return stacks. This will not only reset the console but it will terminate the program and typing BYE in this situation will crash the system! There is clearly room for improvement.

Boards and target support

STM8L101F3 Low density support

Several differences between the STM8L101 and other STM8L devices (e.g. option bytes) delayed STM8 eForth support for a long time. STM8 eForth now supports RM0013 devices with NVM, the TIM2 based BG task and also the simulated serial interface. A binary release is available and the ordinary STM8 eForth workflows can be used.

Please refer to the docs in the configuration folder STM8L101F3 and the following issues:

  • #349 Add support for STM8L101 and STM8L001
  • #356 improve STM8L101 docs and efr file
  • #356 STM8L101F3: improve target.inc and docs Documentation

Note that statements in the Wiki and other docs that the STM8L101 would not be supported have been changed. Using OpenOCD and gdb-stm8 were instrumental for adding support of this MCU.

STM8L051F3 Low density support

Support for RM0031 STM8L "Low density" devices has long been available. Test results with STM8L devices from applications in the community were used to revise support. Configuration options (e.g. USART, BG timer, simulated serial interface) and docs are now consistent with other STM8L devices.

Please refer to the docs in the STM8L051F3 configuration folder.

STM8L Medium density support

Although there has long been the STM8L-Discovery configuration by @plumbum requests for a more active support of STM8L "Medium density" devices like STM8L151K4 was a recurrent issue (e.g. #218, #267, #268 or #287).

@Eelkhoorn finally sent an STM8L151K4 breakout board to @TG9541 and contributed to configuration files and to testing. Issue #354 implemented support for RM0031 STM8L "Medium density" devices, independent of "Medium+" and "High density" devices.

Please refer to the docs in the STM8L151K4 configuration folder where console configuration options are listed.

STM8L High density support

STM8L "High density" devices have a rather rich feature set and more memory than other STM8L devices. Issue #358 added support for these devices and also describes the various console options. It's possible that this configuration also works for "Medium+ density" devices like the STM8L152R6 but no samples have been tested and feedback would be appreciated.

Please refer to the docs in the STM8L152R8 configuration folder.

STM8S configuration folders

The configuration folders STM8S001J3, STM8S105K4 and STM8S207RB now contain docs with a common range of information.

STM8S103F3 Low density support

Issue #371 added an STM8 eForth configuration with standard features and plain UART console settings and for STM8S "Low density" devices. STM8S103F3 includes docs in a similar form as for all the other base configurations and a binary release is provided.

Alternative configurations are MINDEV, SWIMCOM, DOUBLECOM and CORE.

STM8S207RB default serial interface

In order to support the STM8S207K8 issue #334 changed the UART used by the console by default from the first UART (UART1) to the 2nd UART (UART3).

This can be changed by setting USE_UART2 = 0 in globconf.inc.

Improvements and Other Changes

#295 extended memory access with FC@ and FC!
#336: factored solution for BF! abd LEBF! using B!
#353 Add BTJT/ BTJF spin loop enhancement
#337: FC! and FC@ added
#346 Add COMPONLY to the library
#344 STM8L: fix interrupt number naming error

Assets 5
Pre-release

@TG9541 TG9541 released this Sep 26, 2020

New Features

This release will be about STM8L devices (i.e. the likes of STM8L051F3, STM8L151R6 or STM8L162R8).

While STM8S peripherals are simple and the pin and clock configuration is trivial, the STML designers clearly had both many more, and much larger, spec sheets. Many more one can clearly see in the number of configuration dependencies one has to infer when configuring one of the many features of the peripherals. For STM8 eForth this means that some things that were implicit or hard-coded need to be reviewed and restructured, and tested.

This pre-release also (finally) adds support for low-end RM0013 STM8L devices like STM8L101.

Until the release, high-end devices, like the High Density STM8L152R8 should be tested (at least initially, see issue #359).

Changes so far

@frantony
STM8L-DISCOVERY: enable UART output
1f6a8e2

@TG9541
fixes #331 start of 2.2.26 development cycle
5713b7c

@TG9541
fixes #330 Move EEPROMBASE from forth.asm to target.inc
2ceb70d

@TG9541
fixes #334 STM8S207: use UART3
a9e1b61

@TG9541
#295 extended memory access with FC@ and FC!
911d4ae

@TG9541
fixes #336: factored solution for BF! abd LEBF! using B!
5abf97e

@TG9541
fixes #337: FC! and FC@ added
a83bd6b

@TG9541
fixes #339 make EEALIAS compatible with STM8L
40d0156

@TG9541
fixes #340 STM8L interrupt priority of BG task
symbols for interrupt number

@TG9541
fixes #342 improve STM8L efr files

@TG9541
fixes #344 STM8L: fix interrupt number naming error

@TG9541
#346 Add COMPONLY to the library

@TG9541
#349 Add support for STM8L101 and STM8L001

@TG9541
#350 Support ELF target for OpenOCD / stm8-gdb

@TG9541
#353 Add BTJT/ BTJF spin loop enhancement

@TG9541
#354 Add STM8L151K4 board support for RM0031 STM8L Medium Density Devices enhancement

@TG9541
#355 Export constant PAGESIZE to indicate the size of a Flash page enhancement

@TG9541
#356 STM8L101F3: improve target.inc and docs Documentation

Assets 5
Pre-release

@TG9541 TG9541 released this Aug 21, 2020

Superseded by 2.2.26.pre3

Assets 5
Pre-release

@TG9541 TG9541 released this Aug 21, 2020

Deprecated - please use 2.2.26.pre2 or later

Assets 5
  • 2.2.25
  • db67ed8
  • Compare
    Choose a tag to compare
    Search for a tag
  • 2.2.25
  • db67ed8
  • Compare
    Choose a tag to compare
    Search for a tag

@TG9541 TG9541 released this Jul 10, 2020

New features

A bug-fix and an extra.

Buffered RX with INTRX

Buffered RX, e.g. using INTRX, speeds up the console quite a bit: STM8 eForth can feel really snappy if it's not slowed down by a 9600 baud console interface.

An important use case for buffered RX is interactive applications with background or idle task execution times that exceed a console char time (about 1ms at 9600 baud). A discussion is in this HaD log.

STM8 UART register addresses and names depend on the device. STM8 eForth works around this by providing a default UART, but selecting the device is still necessary:

\ select the generic STM8S controller first

\ alternatively specify STM8S103, STM8S105 or STM8S207
\res MCU: STM8S103

\ load (or define) device independent constants
\res export INT_UARTRX UART_DR UART_CR2

\ define the UART buffer length
8 CONSTANT RBLEN

\ then load the controller independent code
#require INTRX

\ put it to work
#require WIPE
#require :NVM
#require OSCFREQ
#require UART_DIV
#require UARTBRR

NVM
  'BOOT ( xt )
  :NVM
    INTRX
    ( xt ) LITERAL EXECUTE
  ;NVM 'BOOT !

  \ calculate UART_DIV settings for 3840*10 = 38400 baud @ CPU clock rate
  3840 OSCFREQ UART_DIV UARTBRR !
WIPE RAM

\ make it survive a RESET command
#require PERSIST
PERSIST

This code can be placed in {BOARD}/board.fs} and needs to be executed only once. The baud rate can be set using UART_DIV - of course the terminal program (e.g. e4thcom) needs to be set to the matching baud rate, here 38400 baud.

For example, compiling and executing the 66 lines tree traversal demo with e4thcom shows the following transfer time at different baud rates:

baud RAM NVM
9600 2s 4s
115200 1s 2s

The faster console interface can do nothing about the time needed for compilation, especially to Flash memory, but interactive words like WORDS or DUMP feel really fast.

Bug Fix

The reason for this release is #328 - 2.2.24 was long in the making bit the release was a bit too fast.

The bug was introduce when the background timer reload value BGTIMREL was exposed as an "NVM parameter" (see table here). Doing that is now no longer possible.

@Eelkhoorn proposed setting the background task rate in the application init:

  \ change the background task rate to 0.36s:
  7 TIM2_PSCR C! $AFC8 TIM2_ARRH 2C!

This procedure also allows setting the pre-scaler.

Assets 5
  • 2.2.24
  • 98ccbd3
  • Compare
    Choose a tag to compare
    Search for a tag
  • 2.2.24
  • 98ccbd3
  • Compare
    Choose a tag to compare
    Search for a tag

@TG9541 TG9541 released this Jul 4, 2020

New features

Target builds in downstream projects

Adding more boards to STM8 eForth is nice but creating new GitHub repositories for applications, while keeping the core lean, is better.

A new feature supports downstream projects with "target boards": a STM8 eForth release archive contains all source code required for a target build and the Makefile was split in two parts, one with the overal configuration (Makefile), the other for building a board folder (forth.mk).

The release archives are still much smaller since the post-linker list file forth.rst, formerly used by symload.sh, has moved to the release archive stm8ef-rst.tgz. It will only be needed if you'd like to know what exactly went into a binary condiguration.

Support for projects that separate generic from hardware dependent code comes from issue #298: by changing the search order for Forth code in simload.py hardware target folders can used as the "configuration root" that provides initialization and abstractions for multiple targets ({BOARD}/board.fs now comes first, main.fs is second).

Here are some of the GitHub projects that use the new method:

GitHub Project Notes
STM8 eForth Modular Build template repository and cookbook in one
stm8ef-modbus the project targeting the C0135 that first required this feature
W1209 Data-Logging Thermostat a solution for the still growing number of W1209 variants
XY-LPWM timers and 7S-LED code
stm8l051led simulated serial interface and other things for STM8L

Refer to #272 for details.

Move more out of the Core

#282, #285 and #289 make the STM8 eForth Core leaner: the idea is to move more potentially board specific code to include files so that it can be "overwritten" by adding a specific solution to a board folder.

An example is the specialized sser_fdx.inc in stm8l051led which works around a one-sided inverter in a serial link.

Configurable Timer for Background Task

Since introduction of the background task almost 4 years ago it was limited to TIM2. The issues #304 and #305 changed that.

It's now possible to use BG_USE_TIM1 = 1 or BG_USE_TIM3 = 1 in globconf.inc to select TIM1 or TIM3 instead of TIM2. So far the code only works on STM8S.

There is currently no support for STM8L (what's at least missing is configuration of the clock tree for TIM3 and support for TIM1).

Priority feature for EEALIAS using "un-link tags"

With #265 tagging un-linked dictionary entries was introduced. #263 cleaned up old feature selection options. Both contribute to building the aliaslist.fs file in the target folder so that they can be loaded into the EEPROM with the EEALIAS feature.

With this method (#266) up to half a KiB of Flash memory an be saved compared with a STM8 eForth binary that has the same feature set. This is particularly useful for tweaking memory usage in downstream projects.

Improved support for STM8S Low Density Devices with UART remapping

Certain STM8S Low Density Devices (i.e. STM8S001J3, STM8S903 and certain STM8AF devices) have a UART remapping feature: the UART can be mapped to PA3/PF4 instead of the usual PD5/PD6.

#288 and #290 makes sure that by setting HALF_DUPLEX = 2 in globconf.inc the init code in COLD check OPT2 for STM8S "Low Density Device UART remapping" to set either PA_CR1 or PD_CR1.

Improved Support for STM8S High Density Devices

High density devices had a number of feature gaps:

  • #292 required a solution for using the 2nd UART - this is now possible by setting USE_UART2 = 1 in globconf.inc.
  • #298 also adds Forth stack primitives (rp@, rp!, sp! and sp@).
  • #293 fixes a bug that broke simulated console port with TIM4

Future releases will add more support for High Density devices, e.g. access of Far memory for data storage.

Better UART support

Work on STM8EF-MODBUS created some need for non-console use cases of the UART. #302, #303, core exports like OSCFREQ or library words like UART_DIV.

#320 introduces a baud rate parameter for codeload.py.

While the console works fine and feels snappy at 115200 baud, using background tasks can be a challenge (at 9600 baud the background task can take up to 1ms but). A spin-off was code for "buffered RX" (INTRX). This is surprisingly simple and it works very well. The code will be added to the library in the next release.

Better support for the simulated serial interface

The following changes address the simulated serial interface:

  • #293 the simulated interface compatible with STM8S High Density devides, and
  • #319 did the same for STM8L devices
  • #305 adds support for Port E.

There are now configuration parameters for setting the baud rate of the simulated serial interface: TIM4_ARR and TIM4_PSCR.

The following table shows parameter values for a range of baud rates:

Rate CTIM4ARR CTIM4PSCR sser-fdx sser-hdx
600 7 0xCF yes* yes*
1200 6 0xCF yes* yes*
2400 5 0xCF yes* yes*
4800 4 0xCF yes yes
9600 3 0xCF yes yes
19200 2 0xCF yes yes
38400 1 0xCF yes yes
57600 1 0x89 (yes) yes
115200 0 0x89 no (yes)

*) untested but very likely to work - due to a 4 bit pre-scaler index STM8L devices can also use 300, 150, 75 downto 2.34375 baud - maybe that's useful for communication using a flashlight ;-)

Full-duplex at 115200 baud was too much for the combined TIM4 Rx/Tx state machine, and it stopped working. 115200 with half-duplex worked fine (using the new "-r" option of codeload.py, see #320) but I didn't test it with e4thcom since the baud rate in version 0.8.0.64 appears to be limited to 57600.

To be on the safe side it's best to limit the simulated serial in full-duplex to 38400 baud and in half-duplex to 57600 baud. It might also be necessary to introduce tuning for the HSI or using a crystal.

More core information export in target

Some use-cases, e.g. writing code that extends the core, requires knowledge of internal constants, variables or CALL targets. Certain improvements togenconst.awk enable export of information from annotated RAM allocation, constant definitions and targets (e.g. #311, $316, #317, #323 and #326).

The following table shows names exported from STM8 eForth 2.2.24 on:

Word in target type notes
'?BGKEY NVM xt-parameter xt of ?KEY for BG task
'BGEMIT NVM xt-parameter xt of EMIT for BG task
PC_?UNIQUE NVM patch target patch target for CURRENT
PC_BOARDINIT NVM patch target patch target for board initialization
PC_LEDMPX NVM patch target patch target for 7S-LED multiplex
PC_NAME? NVM patch target patch target for CURRENT
PC_WORDS NVM patch target patch target for CURRENT
BGPAD NVM parameter address of the empty PAD for BG task
BGSPP NVM parameter address of the empty data stack for BG task
BGTIMREL NVM parameter timer reload value for BG task
ISPP NVM parameter address of the empty data stack for interrupt task
SPP NVM parameter address of the main data stack
TIB NVM parameter address of Terminal Input Buffer (TIB)
UARTBRR NVM parameter UART baud rate generator value (see UART_DIV)
C_BSPP constant address of the empty data stack for BG task
C_ISPP constant address of the empty data stack for interrupt task
C_RPP constant address of the return stack
C_SPP constant address of the main data stack
C_TIB constant address of Terminal Input Buffer (TIB)
C_UPP constant offset of UPP user area
OSCFREQ constant clock frequency in kHz as defined in target.inc
KEYREPET RamByte key repetition counter for board keys
LED7FIRST RamBlck buffer for 7S LED/LCD patterns
OUT RamWord register for board output
TIM4RXBUF RamByte RX buffer from simulated serial interface
TIM4RXREG RamByte RX shift register of sim. serial interface
TIM4TCNT RamByte sequence counter of simulated serial interface
TIM4TXREG RamByte TX shift register of sim. serial interface
TOKEN_$,n ALIAS patch target for CURRENT
aborq ALIAS runtime word for ABORT" (renamed from abort")

Note that "parameters" point to locations in NVM (Flash memory) that can be changed as needed. That's especially useful for changing I/O words for background tasks by writing to '?BGKEY and 'BGEMIT.

Abstraction of peripheral addresses in the core

Across the STM8S family, the reference manual RM0016 describes peripherals such as GPIOs, timers, UARTS, I2C, SSC, ADC, watchdog timers and control of interrupt or control. Variants of these peripherals are often described in great detail, and the variants are given names such as USART, UART1, UART2, UART3, UART4 or even USART and LINUART. Sometimes the same peripheral has a different name in the datasheet of commercial/industrial and automotive grades of the same chip.

It turns out that subsets of peripheral register addresses are almost always the same. Almost. Timers TIM2 and TIM4 have the same register names in LD (Low Density) as in MD (Medium Density) and HD (High Density) devices but the addresses differ a bit.

UART irregularities are of a different kind: there are two sets of address and interrupt vectors, let's call them 1st UART and 2nd UART. An "LD" device has a 1st UART, "MD" a 2nd UART and "HD" has both of them.

For writing device independent low-level code some workarounds can be used:

  • provide a symbol file that contains a shared functional sub-set of peripheral register addresses
  • provide identical symbols for peripheral registers with common functionality in different symbol files
  • first define device independent symbols in low-level application code from device specific symbol files, first then load device independent code

For UART addresses there is an implementation of workaround 2 in STM8S103.efr, STM8S105.efr and STM8S207.efr: a default UART can be accessed using the alias UART (which is wither the 1st UART or the 2nd UART).

Code that implements workaround 3 turned out to be quite ugly and difficult to maintain but a combination of the first two options based on the use case (common peripheral addresses or peripheral register alias) appears to be manageable.

#302 implements the 1st workaround for the core include files. #307 introduces generic device type identifiers, e.g. for Low or Medium Density and #313 added STM8s.efr. Using this file in \res MCU: STM8S should work for most applications that use common peripherals (e.g, GPIOs, I2C or SSC) and for almost all peripherals of STM8S MD or HD devices (e.g. STM8S105K4 or STM8S207RB).

The release now also contains an mcu definition file STM8L.efr which can be used for all kinds of STM8L devices except STM8L101 (with a caveat, of course).

Yet another W1209 Variant

#275 & #277 adds support for the W1209 CA V2. Please refer to the docs in the board folder.

Other changes

  • #259, #260, #261, #262, #263 better understanding of ASxxxx macro string quirks improves HEADERs and genalias.awk
  • #281 makes the behavior of 'IDLE similar to BG: setting it to 0 stops Idle Task execution
  • #299 adds ]BCPL for direct bit complement (like ]B! etc.)
  • #309 adds automated tests for background and for IDLE tasks

Bug Fixes

  • #270, #271 fixes the Rx GPIO CR1 settings if the simulated UART doesn't use PD1 (SWIM)
  • #279 fixed GPIO settings for the STM8L-Discovery board
  • #300 fixes a bug in genconst.awk which broke features like 'IDLE and which was on master for about 5 weeks - fortunately release 2.2.24.pre1 was unaffected and 2.2.24.pre2 only lasted for hours.
Assets 5
Pre-release

@TG9541 TG9541 released this May 10, 2020

Still experimental

Refer to #302 and #304.

Assets 5
Pre-release

@TG9541 TG9541 released this Apr 13, 2020

New features

Target builds in downstream projects

An experimental feature allows downstream projects building new "target boards" using only STM8 eForth "release archives". To enable this all source code that's necessary for a target build is now contained in the release archive, and the Makefile is now more modular (see forth.mk).

Additionally, the forth.rst post-linker list file, previously used by symload.sh, has been moved into an independent release archive (stm8ef-rst.tgz).

#298 changed the simload precedence for Forth code: {BOARD}/board.fs now comes first, main.fs is second. Maybe that's not the best solution for all use cases but it solves the problem of loading "board code" first.

Refer to #272 for details.

Move more out of the Core

#282, #285 and #289 make the STM8 eForth Core leaner: the idea is to move more potentially board specific code to include files so that it can be "overwritten" by adding a specific solution to a board folder.

Priority feature for EEALIAS using "un-link tags"

With #265 tagging un-linked dictionary entries was introduced. #263 cleaned up old feature selection options. Both contribute to building the aliaslist.fs file in the target folder so that they can be loaded into the EEPROM with the EEALIAS feature.

With this method up to half a KiB of Flash memory an be saved compared with a STM8 eForth binary that has the same feature set.

Improved Support for STM8S High Density Devices

  • #298 also adds Forth stack primitives (rp@, rp!, sp! and sp@) - maybe this will be the default also for Medium Density devices.
  • #293 fixes a bug that broke simulated console port with TIM4

Note: the final release will also provide a solution for #292.

Yet another W1209 Variant

#277 adds support for the W1209 CA V2. Please refer to the docs in the board folder.

Other changes

  • #281 makes the behavior of 'IDLE similar to BG: setting it to 0 stops Idle Task execution
  • #299 adds ]BCPL for direct bit complement (like ]B! etc.)

Bug Fixes

  • #270 fixes the Rx GPIO CR1 settings if the simulated UART doesn't use PD1 (SWIM)
  • #279 fixed GPIO settings for the STM8L-Discovery board
  • #300 fixes a bug in genconst.awk which broke features like 'IDLE and which was on master for about 5 weeks - fortunately release 2.2.24.pre1 was unaffected and 2.2.24.pre2 only lasted for hours.
Assets 5
Pre-release

@TG9541 TG9541 released this Apr 13, 2020 · 120 commits to master since this release

Please don't use this one - refer to issue #300.

Assets 3
Pre-release

@TG9541 TG9541 released this Oct 19, 2019

2.2.24.pre1

fixes #272 Deliver forth.asm and other source files in release archive
Assets 5
You can’t perform that action at this time.