.. index:: swdcom-speed,developing,repl,console,terminal,word list .. _swdcom-speed: .. Created swdcom-speed.rst: Wed 13 Jul 2022 20:02:52 AEST .. Full Path: /home/tp/mecrisp-unofficial-doc/swdcom-speed.rst .. Author Copyright 2022 by t.j.porter .. Made by /home/tp/projects/scripts/makerst.sh -->/usr/local/bin/makerst .. license: MIT, please see COPYING Swdcom Debugging Advantages =========================== **SWDCOM provides a Forth REPL for Cortex-M MCU's using the SWD connection.** .. image:: swdcom/swdcom-terminal.jpg :ref:`SWDCOM` is made for and works with :ref:`Mecrisp-Stellaris` providing many indispensable developer features. What may not be immediately obvious is that SWDCOM makes Forth debugging almost instant as it has a 255 byte :ref:`SWDCOM` ring buffer which does not interact with any on chip peripherals. Embedded Forth developers commonly use stack print statements such as *.s* to debug their programs, however just like C printf's, this is totally disruptive to the speed of execution when used over a USART due to the time taken to print to the terminal. GDB over SWD fixed this for C (more or less) but what about Forth which traditionally uses a USART for the REPL ? I decided to test the speed of :ref:`SWDCOM` a long print of 668 Words and compare it to a blocking delay of 100,000 on my STM32F0 Discovery board running at 48 MHz and this is the result. Test Code --------- :: \ ---------------------------------------------------------------------------\ \ Program Name: tperf.fs \ Date: 11 July 2022 AEST \ Copyright 2022 by Terry Porter, MIT Licensed \ For Mecrisp-Stellaris by Matthias Koch. \ https://sourceforge.net/projects/mecrisp/ \ Chip: STM32F051 \ Board: STM32F0 Discovery Board \ All register names are CMSIS-SVD compliant \ Short Program Description: Measure time taken (in ms) to execute any Word. \ ---------------------------------------------------------------------------\ : tperf ( word -- time ) \ ticktime is the register counting ms interrupts from the Systick. zero-ticktime \ Start the ms counter ['] swap execute \ Run the supplied Word ticktime @ \ How long did it take ? cr ." Word time(ms) = " . cr 100000 0 do loop \ start the test delay ticktime @ \ How long did it take ? cr ." 100000 doloop time(ms) = " . cr ; words tperf \ 668 words in this dictionary Results ------- The time to print a long list of 668 words was under the 1ms Systick threshold at 0. :: Word time(ms) = 0 This means that my program was minimally interrupted by the print and the delay no doubt running as my :ref:`SWDCOM` terminal started receiving the Word list. The implications are obvious, :ref:`SWDCOM` allows printing data from running programs with minimal interference to the source code for Forth. I have in the past connected a high speed hardware counter to measure this delay and it was in the low micro seconds, but I don't have that data handy at this time, and will add it here later. Delay Time ^^^^^^^^^^ As expected, around 11 ms. :: 100000 doloop time(ms) = 11 Summary ------- Tools such as :ref:`SWDCOM` bring Forth into the modern embedded age where it can take advantage of advanced debugging facilities such as SWD (on Cortex-M). There is no need to tolerate ancient technology such as slow serial terminals with no flow control, which frankly make Forth embedded development on Cortex-M unusable compared to modern C with GDB. Notes ----- .. note:: SWDCOM only works under Unix, Linux, OSX etc (there is no Windows binary I'm aware of) and for those Cortex-M MCU's supported by ST-LINK .. note:: REPL stands for 'Read-Eval-Print Loop' and is the Forth 'terminal' or 'console'. .. seealso:: :ref:`Swdcom Install` for all the details including installation, connections etc. .. seealso:: :ref:`Swdcom Premade Binaries` For those who don't want to modify the kernel and compile their own. The WordList ------------ This is what took 0 ms to display on the SWDCOM REPL. .. literalinclude:: txt/wordlog.txt