The SPI who came in from the cold

The film was based on John Le Carre's novel of the same name

“Don't give it to them all at once, make them work for it. Confuse them with detail, leave things out, go back on your tracks" -  John le Carré, The Spy Who Came In from the Cold

I had always wanted a wall clock which self-corrects from the Internet using NTP. A few weeks ago I bought a cheap MAX7219 8-digit 7-segment display. It seems a perfect match for the ESP8266, which will access NTP from my home WiFi. The MAX7219 uses SPI which should link to the ESP-12E and can then be scaled up to wall clock size.

Straightforward project, perfect for IoT. It started well- I linked two ESP-12E using SPI and the sample programs in Arduino IDE. That worked a treat. I may not even need to learn the Lua programming language. Then real life intervened.

It did not work. The Lua sample code had worked when I used ESP-12Es as master and slave. Did I get a bad MAX7219? It certainly was a cheap clone from a no-name China supplier. Was it the level translator, the Lua program or the ESP-12E? 

It was weird- at times it seems to start working (the display comes on) only when I power it off.It seemed to work even when the MAX7219 did not have power - the MAX7219 seemed to be able to leech enough power from its signal lines. Randomly disconnecting a signal cable sometimes produced a fleeting glimpse of a working display.

But after three days, I had to admit- I was stuck. But what is really needed is an admission that the easy way failed. 
I needed to know whether it is a problem with the MAX7129 or the software.One way was to get the MAX7219 working with different software. The other would be to buy another MAX7219 module, preferably from a different supplier. To rule out the ESP-12E's flakey start I need a different controller. 

I had SPI source code for the PIC18F14K50 CPU from Microchip- it came with their development kit. I even have a finished PIC18F14K50 prototype PCB I designed myself some years ago but had not gotten round to testing it.

Testing the SPI PIC18F14K50. Being USB devices they came up in Linux as /dev/ttyACM0 and /dev/ttyACM1

The SPI PIC18F14K50 and their software (sample code from the Microchip MCC18 compiler) did not work either. Time to back off SPI. The PIC18F14K50's SPI pins can be reprogrammed to use the I2C protocol. Maybe I will have better luck - at least it will prove I have working PIC18F14K50.

Fell back to I2C. Did not work either! It is starting to look like I am going backwards. Time to bring up the Death Star, my oscilloscope. Nothing gets by the oscilloscope. I love my scope, but just setting it up takes one day. It forces me to take things real slow, step by steady step, soldering test points, checking voltages pin by pin. Oh, and you now have to read the datasheets. Ugh. Buzzkill. Time to RTFM. 

And true enough, the scope showed problem is the MCC18 code. It does not work. That is quickly fixed, and now I2C between two PIC18F14K50 work. The SPI worked soon after, but the datasheets said there is no real standard for SPI, there can be 4 variants. The timing cycles for the PIC18F14K50 and the MAX7219 needs to be carefully examined for a match.

The 4 SPI modes supported by the PIC18F14K50

Luckily, there is a match: the second mode in the PIC18F14K50 matches:

MAX7219 Timing Diagram. 

Set up the PIC18F14K50 with the MAX7219. It did not work! In fact the symptoms are much the same as the ESP-12E, the display flashes working on power down, the MAX7219 starting up without power. But this time I have the scope. Turned out the PCB labelling was wrong- SPI MISO and MOSI were swapped round. And more MCC18 code needed to be replaced, but eventually it worked:

MAX7219 working with the PIC18F14K50

It's time to get back to the source of my grief- the software in the ESP-12E sample code. Now this is not a reflection on the software quality or the author- SPI simply had too many variants for the code to work right off the bat. Plus the author was interfacing to his SPI device using 32-bit SPI cycles. The MAX7219 needed 16-bit cycles.

Bottom: working SPI  on ESP-12E and MAX7219. Top: the mighty Death Star

You can get lucky most times and have your project work just using Internet resources. Indeed, you should and must use the optimistic approach first. But sometimes you just have to get out the Death Star and do the slow but steady steamroller. 



Later, I found the LEDControl already has working software for the ESP8266. It had not come up with my Google searches becasue it did not mention SPI, just the MAX7219.

The ESP-12E SPI interface to MAX7219 has had twists and turns worthy of a John Le Carre movie. Such is life. Happy Trails.