Those pictures you’ve been seeing in recent articles, with over a dozen boards by now, all have the same configuration in common: boards with a USB port on them, connected and powered through anything but that USB port…
There is some value in this hookup - in fact, either this or an SWD-based setup using a Black Magic Probe or an ST-Link is required to be able to upload the core Mecrisp Forth 2.2.2 image onto the board (once). All the STM32F013 µC models support only the serial port in “ROM boot loader mode”, which is all you’ve got as starting point on a blank chip.
But after that, not having the USB port as “normal” serial device is a major inconvenience.
This highlights what is probably the main drawback of using Mecrisp Forth on microcontrollers such as the STM32 series: Forth cannot be combined with C or C++ - not easily, anyway.
On the one hand, this is no big deal: as the recent “Dive into Forth” article series has shown, it has been surprisingly easy to implement most of the features offered by C runtimes such as the Wiring/Arduino library. Digital I/O, ADCs, DACs, PWM, I2C, SPI were all created with little effort. Even advanced DMA and LCD & memory chip interfaces were added with relative ease.
But USB is a completely different creature: it’s the combination of a fairly complex protocol, with “enumeration”, “endpoints”, and a hefty specification guide, intended to support a huge range of hardware, with lots of different USB modes and speeds. On top of all that, there’s STM32F103’s own USB hardware implementation, which appears to be a fairly early version of what has been greatly enhanced and improved in later STM32 chip series. Things like a 512-byte buffer which has to be accessed as 2-byte words while their addresses start on 4-byte boundaries don’t make the task particularly straightforward. STM32F1’s USB hardware looks like one big kludge…
There is a lot of sample code in C to use as guideline, but it tends to consist of layer upon layer of definitions, headers, and “low-level” vs “high-level” API calls, spread out over dozens of files. It looks more like an example of how to bury the logic of an implementation than anything else!
To put this in perspective: USB is not essential for remote wireless sensor nodes, since they are going to be used un-tethered anyway, but for development it sure would be convenient to just plug that board in, for both power and serial communication. Especially since Mecrisp Forth is entirely driven and uploaded via a serial connection. With USB in Full Speed (FS) mode, i.e. 12 Mbit/sec, a serial connection could also be faster than the current 115,200 baud serial link.
Nevertheless, the plan here at JeeLabs, is to work on getting a USB device implementation in Forth working. This might take a while - the C-based open source examples out there are all too large to make this task simple. Fortunately, the latest beta version of the Saleae Logic Analyser supports USB-FS decoding - this is going to be a huge help during debugging. Another option is to use Linux on the host side: it supports extensive logging and the USB traffic can be examined with WireShark.
A similar situation will arise with Ethernet. There are several examples of a “TCP/IP stack” in Forth, but getting it to work on STM32F107’s and STM32F407’s will probably require some serious time investment and sleuthing…
The good news: these issues do not reduce Forth’s usability for the JET project - stay tuned…