Skip to content

A bit too fast!

Compare
Choose a tag to compare
@TG9541 TG9541 released this 10 Jul 11:28
db67ed8

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.