I recently backed an interesting SPIdriver project on Crowd Supply . For as little as $27 you can have your very own SPI debugging tool!


First, it should be noted what this device is, and what it is not. As clearly stated by the name - it is a driver and not a monitor. There's an open issue on GitHub regarding monitoring , I'm interested in seeing what happens with that. But really, for monitoring, that would be the job of an oscilloscope - ideally a DSO, or even better: a logic analyzer.

There was a (slightly misleading) but otherwise interesting review by the folks over at linuxgizmos that mentions the word "monitor" several times when describing the SPIdriver.

Still, I had hoped to see how complex of an undertaking it might be to add the monitoring feature.  When I looked at the source for the firmware, I kinda just stared in bewilderment for a few moments: "What is this strange language?"- but then back in the README, I noticed in the first line: "It uses the MyForth compiler written by Charley Shattuck and Bob Nash". wow. Forth! And not just any Forth :
This version is intended for embedding in small 8051 based projects. They currently feel the product is not commercial worthy as it has too many personal enhancements, and is more an exploration of concepts than a real product.
Really - I'm impressed that not only someone could code something in this language, but as noted on the documentation page:
This version is intended for embedding in small 8051 based projects. 
So even more impressive is that this code is compiled and loaded into... (?) what specific chip: "Silicon Labs automotive-grade microcontroller"? I'm not really sure, but have requested the schematic be made available. The article mentioned above claims the controller is an EFM8 8051-based 8-bit MCU . The text on chip includes 8810 and 1743; not much luck when googling this. So I have not confirmed the exact processor being used. I've not coded for the 8051 in quite some time, and certainly never in Forth. It is good to know this chip is still around if that's what's here.

Not only do I have pretty much no Forth-programming skills; further, I have no idea how the binary, once compiled, would even get on the chip itself. Perhaps something like avrdude is used? I wonder if the code comes in via the serial port, or perhaps the bi-directional SPI port? (Hopefully not another vendor specific, proprietary IDE)

In any case, the code seems to work well for the intended purpose: The FTDI chip acts like a serial port talking the to SPIdriver controller. The device works some magic converting serial port text commands into SPI control signals - and displays them!

The initial out-of-box experience was quite good; I had the device working almost immediately thanks to the great documentation page . It would have been sooner, had my Ubuntu VM not been in the middle of an update. (thus preventing me from installing anything new). The Windows command-line does not work quite as documented, since the ports are not named /dev/ttyUSB[n]. Fortunately the parameters accept Windows-style port names:



>>> from spidriver import SPIDriver
>>> s = SPIDriver("com16")
>>> s.sel()
>>> s.write([0x9f])
>>> list(s.read(3))
[127, 255, 255]
>>> s.unsel()>>> quit()

Very cool. Moving on from the initial test, I played a bit with the pre-compiled Windows executable. Minor stumble here, as my 64-bit Windows 10 installed the app into the x86 directory, thus the sample command-line was slightly different than the docs: 



C:\workspace>"c:\Program Files\Excamera Labs\SPIDriver\spicl.exe" COM16 i
The system cannot find the path specified.
C:\workspace>"c:\Program Files (x86)\Excamera Labs\SPIDriver\spicl.exe" COM16 iuptime 61  5.029 V  0 mA  29.0 C


The Windows GUI makes it ridiculously easy to send SPI commands. Up to two hex digits can be entered and sent with each "Transfer" button press:

SPIdriver Windows GUI

Resulting in the display on the SPIdriver to look like this:


SPIdriver sample SPI signal
Note that if you exit the SPIdriver Windows app, you may need to wait a few moments for the process to be completely killed; Otherwise when starting a new instance, I found that the data entry box would sometimes not accept any characters.

On to a more impressive and complex, sending an entire picture to another SPI display ! Here too, I had a minor stumble, as the docs claim that  the command looks like this:


python -h /dev/ttyUSB0 st7735s.py grace.png


This brought up the python help for me, and ignored the rest of the parameters. On Windows the command was this one (also note different picture): 


python st7735s.py -h COM16 spidriver.png


Resulting in this:

SPIdriver talking to an SPI display
Sadly, I could not find a convenient SPI memory device laying around (at least not one I was willing to possibly fry), so I could not continue with the sample SPI flash. But while digging through my parts, I found an ENC28J60 SPI Ethernet board like this one that I've been meaning to play with. Coming soon...

Other notes:


Please leave comments, ideas, suggestions below (moderated, sometimes delayed) or send me a message at gmail, or find  me on twitter .



Copyright (c) gojimmypi all rights reserved. Blogger Image Move Cleaned: 5/3/2021 1:35:54 PM