superseded by 2.2.23

Merge pull request #252 from bademux/tool_dump2ihx_script

replace AWK with python script

simload.sh fix for DOCKER-SDCC:V3.8.4

Merge pull request #251 from TG9541/modbus

fixes #235 sstm8 dump format update

superseded by 2.2.23.pre4

Merge pull request #246 from TG9541/modbus

Modbus

STM8L boards added to release

Somehow I forgot to add the STM8L051F3 and the STM8L-DISCOVERY boards to the last release.

New Features, New boards, More STM8L, Some Fixes

New Features

STM8 eForth can now use the REPL in non-interactive applications. This means that the power of the Forth interpreter can be used, e.g. for implementing text based communication protocols. A set of new features can be combined to this end. Thanks to @VK6TT for the idea!

IDLE Feature

#187 adds a basic IDLE feature. Here is an example:

#require 'IDLE
\ this is "$0066 CONSTANT 'IDLE" (independent of the revision)
VARIABLE TALLY
: testidle TALLY ( -- ) 
  \ idle code must be stack neutral!
  @ 1+ DUP TALLY ! $F000 AND 0= OUT!
;
' testidle 'IDLE !  \   set IDLE execution vector to word testidle

When the console waits for input, testidle makes the board outputs (e.g. LED). An STM8 with 16MHz clock flashes the LED about 34 times per minute. This means that one IDLE loop iteration takes about 8.65µs = 34s/60/65536.

EVALUATE Feature

#185 adds a basic EVALUATE for STM8 eForth. The feature required a minuscule core change that was addressed in #183 (Enable EVALUATE-like feature by using indirect addressing for TIB).

EVALUATE enables interpretation (or compilation!) of code by Forth programs. Consider the following example:

#require EVALUATE
: myString ( -- a )
   $" 2 7 *" 
   ;
: test ( -- )
   myString COUNT EVALUATE
   ;

test . evaluates myString and prints 14 ok. Use cases comprise the implementation of communication protocols, algorithmic auto-configuration, or compiling source code stored in the embedded system.

If used carefully (no concurrent compilation with REPL!), EVALUATE can also be executed in an idle task (solved with Issue #185).

Dictionary entries in the EEPROM

Although the STM8 core can't execute code from the EEPROM it can still be used to store STM8 eForth Aliases. By using the EEPROM for eForth core dictionary entries, Forth applications on low-density device can use up to 500 bytes additional Flash ROM.

With e4thcom the feature is really easy to use :

\ EEPROM MODE Example:
#include EEALIAS

\ define ALIAS words in EEPROM MODE
#require SPACES
#require DIGIT
#require DNEGATE

\ all words defined, return to normal mode, and WIPE RAM
EECLOSE

Please refer to the ALIAS Wiki entry for details.

STM8S High Density Support

Issue #173 adds initial support for STM8S High Density devices. Controllers like STM8S207xB provide up to 32K Flash, 6K RAM, and 2K EEPROM for Forth applications. There are no plans to support compiling Forth code to Flash memory beyond 0x10000. However, up to 96K Flash memory area can be used for C code or for data storage.

Improved STM8L Support

@plumbum greatly improved STM8L support:

• support for the STM8L152C6 (e.g. STM8L Discovery), including LCD control
• SPI master code for STM8L
• driver code for the STM8L RTC (real time clock)

New Boards

All newly added boards are the result of community support: direct contribution, or gentle nudging ;-)

XH-M194

The XH-M194 is a timer relay board with the following features:

• STM8S105S4T6 (16K Flash, 2K RAM, 1K EEPROM, 44pin)
• 6 relays 12V/250VAC w/ 6 red status LEDs
• 6 green status LEDs
• 4 digit digital clock-style 7S-LED display
• 6 keys
• DS1302 RTC, half-duplex SPI, backup battery holder
• 12V AC/DC power supply

Please refer to the XH-M194 Wiki entry and to XH-M194/board.fs. Issue #128 tracked the implementation.

XY-LPWM

@plumbum added board support for the XY-LPWM, a board with the following features:

• STM8L003F3P6
• 2x4 digits LCD display based on HT1621B (with driver code)
• 4 keys
• pads for UART RX/TX
• PWM output

Please note that most likely the Nuvoton µC will have to be replaced by an STM8S003F3P6 or an STM8S103F3P6, and that the docs are not yet complete. However, the board has a full UART port, and it's a generally a good choice for experimenting with STM8 eForth.

XY-PWM (HW-0515)

@plumbum added board support for the board XY-PWM (alias HW-0515), which has the following features:

• STM8L003F3P6
• 3 digits LED display
• 3 keys
• pads for UART RX/TX
• 2xPWM output
• Micro USB connector for power supply

Initial docs are in the XY-PWM/README.md are not yet complete. As the board has a UART port and an easy power supply it's a very good choice for experimenting with STM8 eForth.

STM8L-Discovery

@plumbum added core support for the STM8L152C6, and board support for the STM8L-Discovery, including LCD driver code. Please refer to the STM8L-DISCOVERY/README.md.

Improvements and Other Changes

• Issue #180 SPI register constants fixed PD8544 (Nokia 3310) LCD code
• Issue #189 Enable UART simulation on Port E
• Issue #192 Export arbitrary RAM locations in forth.asm as constants
• Issue #194 improve behavior of serial interface w/ shared LED-Display (e.g. DCDC, W1401)
• Issue #200 codeload.py supports multiple symbols \res export in one line (4ethcom compatibility)
• Issue #212 align SPIon parameters in spi.fs with stml.fs
• code size tweaks

More boards by @plumbum, more STM8L

fixes #202 STM8L: wrong peripherals addresses 7a782a2

xy-lpwm: fix BKEY f8db07e
xy-lpwm: Remap LCD data 262b5f6
xy-lpwm: ascii to 7 seg code converter e1883ca

terminal runner d8cde27
Added makefile rules 'term' for run e4thcom terminal b79ef07

Basic support for XY-PWM/HW-0515 PWM generator board ed1d9c9

Basic functional library for internal RTC of STM8L f018d84

Added support STM8L-Discovery board (STM8L152C6) 390a980
stm8l-discovery: add LCD driver support c3454fa
STM8L-Disco: LCD driver, short usage. a350df1

SPI master for STM8L* f609ad4
fixes #212: SPIon ( baud -- ) SPI clock divider 2^baud dad4e3a

Board XH-M194 with RTC, improved \res and RAM address export

fixes #200 res supports multiple symbols

fixes #192 Export arbitrary RAM locations as constants

issue #128: initial commit for XH-M194 7S-LED, keys, outputs
fixes #128 XH-M194 w/ DS1302 RTC
fixes #128 switch serial console and clock colon dots
fixes #128 RTC burst-mode

fixed #189 Enable UART simulation on Port E

fixes #185 EVALUATE honors COMPILE mode

fixes #194 Improve behavior of serial interface w/ shared LED-Displa…

Board XH-M194

Refer to Wiki and issue #128 for details.

Features IDLE, EVALUATE, EEALIAS

New Features

Basic IDLE Feature

#187 adds a basic IDLE feature. Here is an example:

#require 'IDLE
\ this is "$0066 CONSTANT 'IDLE" independent of configuration
VARIABLE TALLY
: testidle TALLY ( -- ) 
  \ idle code must be stack neutral!
  @ 1+ DUP TALLY ! $F000 AND 0= OUT!
;
' testidle 'IDLE !

When the console is idle, the example code flashes the board outputs (e.g. LED) about 34 times per minute. One IDLE loop iteration thus takes about 34s/(60*65536) = 8.65µs.

Basic EVALUATE Feature

#185 adds a basic EVALUATE for STM8 eForth. The feature required a minuscule core change that was addressed in #183 (Enable EVALUATE-like feature by using indirect addressing for TIB).

EVALUATE enables interpretation (or compilation!) of code independent of the console. Consider the following example:

#require EVALUATE
: myString $" 2 7 *" ;
: test myString COUNT EVALUATE ;

test . evaluates myString and prints 14 ok. Possible use cases comprise the implementation of communication protocols, algorithmic auto-configuration, and compiling source code stored in the embedded system.

If used carefully (no compilation!), EVALUATE can also be executed in an idle task.

Dictionary entries in the EEPROM

#178 adds a method for storing dictionary entries in the EEPROM based on the STM8 eForth ALIAS feature. By using the EEPROM for core code dictionary entries, about 500 bytes Flash ROM can be saved for use in Forth applications.

New STM8S High Density configuration

#173 adds initial support for STM8S High Density devices: up to 32K Flash, 6K RAM, and 2K EEPROM plus up to 96K Flash > 0x10000.

Improvements and Other Changes

fixes #180 SPI register constants

fixes #180 PD8544 LCD code

several code size reductions

New features, improvements, and bug fixes

New Features

New W1209-CA board configuration

@zcsahok provided a board configuration for W1209 clones with common anode LED displays. Read more about different W1209 clones in the Wiki, and in the issues #153 and #156.

Initial Support for STM8L051F3

The STM8L family has two main groups: the STM8L101x variants (including the upcoming STM8L001J3), and the other STM8L devices, to which also the STM8L051F3 belongs.

The STM8L support added the STM8L051.efr for e4thcom \res mcu, and the stmtldevice.inc for the STM8 eForth core forth.asm.

The interrupt vector numbers for in main.c now come from stm8device.h.

A new generic board folder for STM8L051F3 was added.

See issue #137 for details!

VOC for STM8 eForth

Manfred Mahlow contributed the VOC namespace feature which is based on the wid-tags dictionary extension. The dictionary extension works by patching the STM8 eForth core. This patching is done by loading CURRENT with #require CURRENT in e4thcom or with tools/codeload.py.

Note: patching requires some STM8 eForth core addresses which are board dependent - please make sure that you either set configure the e4thcom search path option for CWD/target or that ./target is a symlink to ./out/<yourBoard>/target (e.g. rm -f target ; ln -s out/<yourBoard>/target target, or simply make BOARD=<yourBoard>).

First automated test for CURRENT and VOC have been implemented. The following is now part of the tests executed by TRAVIS-CI:

\ compile CURRENT and VOC as a test
COLD

#require CURRENT
#require VOC

#include utils/tester.fs

T{ : a 1 ; -> }T
T{ : b 11 ; -> }T
T{ VOC abc -> }T
T{ abc DEFINITIONS -> }T
T{ : a 2 ; -> }T
T{ : b 22 ; -> }T
T{ FORTH DEFINITIONS -> }T
T{ a b -> 1 11 }T
T{ abc a abc b -> 2 22 }T

Note: the release contains the fix for issue #150 (an issue of the CURRENT patch)

WIPE and Dummy Word in RAM

For using dictionaries in RAM as a scratch-pad, M.Mahlow implemented the library function lib/WIPE. The implementation created a dummy dictionary entry in RAM, which makes the behavior of MARKER consistent. However, it doesn't take care of claiming RAM for VARIABLE, and it didn't initialize the NVMCONTEXT pointer.

Implement an internal RAM dictionary initialization function based on the WIPE that can be exposed with an ALIAS.

WIPE introduces a dummy word in the RAM dictionary, and it's well worth the 3 bytes of RAM it requires. The implementation of OVERT is now a bit simpler (issue #163).

RESET ok
: a 2 . ; ok
NVM ok
: b 1 . ; ok
RAM ok
WORDS
 a  b IRET SAVEC RESET RAM NVM WORDS .S DUMP IMMEDIATE ALLOT VARIABLE CONSTANT CREATE ] : ; OVERT ." AFT REPEAT WHILE ELSE THEN IF AGAIN UNTIL BEGIN NEXT FOR LITERAL C, , ' CR [ \ ( .( ? . U. TYPE SPACE KEY DECIMAL HEX FILL CMOVE HERE +! PICK 0= ABS NEGATE NOT 1+ 1- 2+ 2- 2* 2/ */ */MOD M* * UM* / MOD /MOD M/MOD UM/MOD WITHIN MIN MAX < U< = DNEGATE 2DUP ROT ?DUP BL BASE - 0< OR AND XOR + UM+ I OVER SWAP DUP 2DROP DROP NIP >R R@ R> C! C@ ! @ 2@ 2! EXIT EXECUTE EMIT ?KEY 'BOOT COLD ok

Note: in the example code, the dictionary dump has a double whitespace between the word in RAM a and the word in NVM b. This is due to the zero-length dummy word at the beginning of the dictionary.

I hereby declare the whitespace a "dictionary structuring" feature ;-)

Prevent RAM word to be compiled into NVM code

While using IMMEDIATE RAM words in NVM mode makes sense, compiling them into ROM code creates, as M. Mahlow reported, "high quality bugs".

Compilation of words in RAM into NVM code with CALL, now aborts with the error message target?.

Improvements and Other Changes

Serial Console Options Improved

Some use-cases, like using the UART for a Modbus interface, require an independent configuration of the UART simulation when used together with the UART (e.g. half duplex on one interface, and full duplex on the other).

The following configuration in a ./<BOARD>/globconfig,inc file provides a 2-wire console on PD1/SWIM, and console independent UART words TX! and ?RX:

        HALF_DUPLEX      = 0    ; Use UART in full duplex mode
        HAS_TXUART       = 1    ; UART TXD, word TX!
        HAS_RXUART       = 1    ; UART RXD, word ?RX
        HAS_RXSIM        = 2    ; Enable RxD via GPIO/TIM4, word ?RXGP
        HAS_TXSIM        = 2    ; Like HAS_RXSIM, word TXGP!, use for console if > HAS_TXUART
        PSIM     = PORTD        ; Port for UART simulation
        PNRX             = 1    ; Port GPIO# for HAS_RXDSIM
        PNTX             = 1    ; Port GPIO# for HAS_TXDSIM

The code got manually tested in the following configurations:

Board	Console Configuration
W1209-FD	3-wire simulated (TxD:PC5, RxD:PC4)
W1401	2-wire simulated (PD1)
SWIMCOM	2-wire simulated (PD1)
MINDEV	3-wire hardware UART
STM8S003J	2-wire hardware UART
DOUBLECOM	simulated 2-wire (PD1), 3-wire hardware UART

Board-IO and ADC Code in Include Files

Issue #167 moved board-io code from forth.asm to include files:

• the 7S-LED and board key translation code is now in inc/board_io.inc
• ADC code is now in inc/stm8_adc.inc

The background is that STM8L has a 12bit instead of a 10bit ADC, and thus requires different ADC routines.

The related code is now in the inc/ folder so that it can be replaced by target code in board folders.

Improved codeload.py

The new option --target-base can be used for setting a base folder instead of CWD for the CWD/target include, e.g. out/CORE.

The Forth source loader codeload.py now supports e4thcom stype transfer level block comments. It's possible to temporarily comment out blocks of code using curly brackets. Comment-to-EOF is now also fully supported (all text from \\ to the EOF is skipped).

Here is a comment example for e4thcom and codeload.py:

{
  never transfer this to the target 
}

\\ 
skip this text,
too

Change to CONTEXT

The core word CONTEXT now always returns the current USRCONTEXT. The NVM/RAM mode dependency that's necessary for linking dictionary changes in RAM to those in NVM memory is now more transparent to the user.

Assembly words with DOXCODE

The core feature DOXCODE for coding assembly words with X as the working register has been exposed as an ALIAS. Using the X register in assembly improves code density.

The following example provides a dense, and relatively fast, CRC-16 computation routine (i.e. not using a 512 bytes table):

\ STM8: CRC-16-ANSI,  polynomial x16 + x15 + x2 + 1
\ refer to github.com/TG9541/stm8ef/blob/master/LICENSE.md

\ reversed implementation ($A001), for Modbus start with "-1" 
#require DOXCODE

  : CRC16 ( n c -- n )
  \ CRC-16-ANSI (seed with -1 for Modbus CRC)
    XOR DOXCODE [
      $A608 ,  \         LD      A,#8
      $54 C,   \ 1$:     SRLW    X
      $2407 ,  \         JRNC    2$
      $01 C,   \         RRWA    X   ; XOR X,#0xA001
      $A801 ,  \         XOR     A,#0x01  
      $01 C,   \         RRWA    X
      $A8A0 ,  \         XOR     A,#0xA0
      $01 C,   \         RRWA    X
      $4A C,   \ 2$:     DEC     A
      $26F3 ,  \         JRNE    1$
    ] ;

\\ Test

#require utils/tester.fs

\ https://www.lammertbies.nl/comm/info/crc-calculation.html
: testCRC -1 58 49 DO I CRC16 LOOP ;

T{ testCRC -> $4B37 }T

Word ]C! added to lib

The "macro" [ c a ]C! makes using mov addr,#c for initializing peripherals very convenient:

\res MCU: STM8S103
\res export BEEP_CSR

: beep-on [ $A8 BEEP_CSR ]C! ;
: beep-off [ $1F BEEP_CSR ]C! ;

Simplified Address Range Test in STM8 eForth Core

The assumption that execution of code from EEPROM was not substantiated. As the simple destinction between RAM (address < 0x8000) and Flash (address >= $8000) is sufficient CALL NVMQ was replaced with a simple TNZ USRCP.

Tests for Double Words

Issue #168 added automated tests for double stack, comparison, and math words .

Bug Fixes

Fix #154 "PICK is off by one"

Issue #154 deals with an error in the STM8 eForth kernel that was already present in Dr. Ting's initial release: 1 PICK equaled DUP, and 0 PICK was undefined. M.Mahlow reported that bug which, by now, was almost a feature. Some of the code in the library had to be fixed.

Fix #161 RAM words not shown in NVM Mode

Words compiled in RAM are not listed by WORDS in NVM mode. Using the words, however, is still possible, and that's why this bug was not detected by automated tests.

Fix #170 MARKER Compatibility with CORE

Issue #170 makes the library function MARKER work with CORE (again).