STM32F4 uses SPI for the MAX6966 LED driver

The STM32F4xx devices are not short of pins and they can be more flexibly used than on the STM32F1xx types. On a micromouse though, there is not a lot of physical space and I am not good at routing lots of traces around a board. Since I had already decided to add an SPI driven LED dot matrix display, I went hunting for a suitable LED driver and came across the Maxim MAX6966 10 channel LED driver.

This device has 10 ports, each with PWM capable of constant current drive that can be set at one of several maximum levels up to 20mA. It has an SPI interface that I can share with the dot matrix display and so gives me up to 10 indicator LEDs for the cost of only a couple of traces running to the back of the mouse. It seems ideal and, since the ports on it can be configured as either inputs or outputs is well worth a look.

You can find out more about these at the Maxim site here: http://www.maxim-ic.com/datasheet/index.mvp/id/4539. I wired one of these to a small piece of perfboard and then connected that up to my test setup with an STM32F4Discovery. This is where all the peripheral development will be done for the micromouse so I have connected up buttons, displays, sensors and motor drivers so that I can write the basic drivers to be sure that my boards will work properly.

Although the ports on the MAX6966 can be used as inputs, I decided to use them for output only so relieving me of the need to add an MISO line to the SPI port connection. Now, I only need the Chip Select, MOSI and SCK connections to drive up to 10 LEDs. Originally, it had been my hope to use DMA to transfer all 10 LED settings at once but a careful read of the datasheet showed that the CS line had to be brought high after each command and it was not worth the overhead of servicing the DMA interrupt for each 16 bit instruction. That meant that all I needed was a relatively simple polling mode driver for the chip.

Although I had written one before for the STM32F103, the ‘F4 has a few subtle changes to the setup and use of just about everything.

First job is to define and setup the various pins for the SPI.

#define SPI_PORT                  SPI2
#define SPI_PORT_CLOCK            RCC_APB1Periph_SPI2
#define SPI_PORT_CLOCK_INIT       RCC_APB1PeriphClockCmd

#define SPI_SCK_PIN              GPIO_Pin_13
#define SPI_SCK_GPIO_PORT        GPIOB
#define SPI_SCK_GPIO_CLK         RCC_AHB1Periph_GPIOB
#define SPI_SCK_SOURCE           GPIO_PinSource13
#define SPI_SCK_AF               GPIO_AF_SPI2

#define SPI_MOSI_PIN             GPIO_Pin_15
#define SPI_MOSI_GPIO_PORT       GPIOB
#define SPI_MOSI_GPIO_CLK        RCC_AHB1Periph_GPIOB
#define SPI_MOSI_SOURCE          GPIO_PinSource15
#define SPI_MOSI_AF              GPIO_AF_SPI2

Nothing too special here. I like to define everything about the device as macros in a hardware configuration header file to make it easier to move it to another project later. The SPI port can now be configured as single direction master using polled mode with software slave select. Actually there is nothing in the configuration about polled mode. That is just how it works by default. For DMA you need to do a bunch of different things as well. There will be another post about that later. Note that the MAX6966 uses the more common arrangement of clock polarity and phase:

void HardwareSPI_init(void) {
  SPI_InitTypeDef SPI_InitStructure;
  GPIO_InitTypeDef GPIO_InitStructure;
  // enable the SPI peripheral clock
  SPI_PORT_CLOCK_INIT(SPI_PORT_CLOCK, ENABLE);
  // enable the peripheral GPIO port clocks
  RCC_AHB1PeriphClockCmd(SPI_SCK_GPIO_CLK | SPI_MOSI_GPIO_CLK, ENABLE);
  // Connect SPI pins to AF5 - see section 3, Table 6 in the device datasheet
  GPIO_PinAFConfig(SPI_SCK_GPIO_PORT, SPI_SCK_SOURCE, SPI_SCK_AF);
  GPIO_PinAFConfig(SPI_MOSI_GPIO_PORT, SPI_MOSI_SOURCE, SPI_MOSI_AF);
  // now configure the pins themselves
  // they are all going to be fast push-pull outputs
  // but the SPI pins use the alternate function
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_InitStructure.GPIO_Pin = SPI_SCK_PIN;
  GPIO_Init(SPI_SCK_GPIO_PORT, &GPIO_InitStructure);
  GPIO_InitStructure.GPIO_Pin = SPI_MOSI_PIN;
  GPIO_Init(SPI_MOSI_GPIO_PORT, &GPIO_InitStructure);
  // now we can set up the SPI peripheral
  // Assume the target is write only and we look after the chip select ourselves
  // SPI clock rate will be system frequency/4/prescaler
  // so here we will go for 72/4/8 = 2.25MHz
  SPI_I2S_DeInit(SPI_PORT);
  SPI_StructInit(&SPI_InitStructure);
  SPI_InitStructure.SPI_Mode = SPI_Mode_Master;
  SPI_InitStructure.SPI_Direction = SPI_Direction_1Line_Tx;
  SPI_InitStructure.SPI_NSS = SPI_NSS_Soft;
  SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_8;
  SPI_Init(SPI_PORT, &SPI_InitStructure);
  // Enable the SPI port
  SPI_Cmd(SPI_PORT, ENABLE);
  spiConfigured = 1;
}

The spiConfigured global flag makes it easy to simply initialise a device and have it initialise the SPI port if it has not already been done. The most obvious difference between this code and that needed for the STM32F103 chip is the way that Alternate Functions are allocated. There is much more flexibility but the code has to be different.

The MAX6966 itself gets similar treatment to define the hardware:

#define MAX6966_CS_PIN               GPIO_Pin_11
#define MAX6966_CS_GPIO_PORT         GPIOB
#define MAX6966_CS_GPIO_CLK          RCC_AHB1Periph_GPIOB
#define MAX6966_CS                   MAX6966_CS_GPIO_PORT, MAX6966_CS_PIN
#define MAX6966_SELECT()             GPIO_ResetBits(MAX6966_CS)
#define MAX6966_DESELECT()           GPIO_SetBits(MAX6966_CS)
#define MAX6966_IS_SELECTED()        GPIO_ReadOutputDataBit(MAX6966_CS)

Since I am going to be sharing this device with other things on the SPI port, I will be using software defined Slave Select pins and it makes sense to define all that here.

Initialising the MAX6966 is now quite straightforward:

void MAX6966_init(void) {
  GPIO_InitTypeDef GPIO_InitStructure;
  int i;
  if (!spiConfigured) {
    HardwareSPI_init();
  }
  RCC_AHB1PeriphClockCmd(MAX6966_CS_GPIO_CLK, ENABLE);
  // now configure the pins themselves
  // they are all going to be fast push-pull outputs
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_InitStructure.GPIO_Pin = MAX6966_CS_PIN;
  GPIO_Init(MAX6966_CS_GPIO_PORT, &GPIO_InitStructure);
  MAX6966_putWord(0x1005); // place device in run mode
  MAX6966_putWord(0x0AFF); // all ports as high impedance
  for (i = 0; i < 10; i++) {
    setLED(i, 0); // set each port to active LED but off
  }
  currentLED = 0;
};

Only the Chip Select line needs actual setting up. The SPI connections are handled in the SPI setup code. A array of 10 bytes hold the current intensity for each LED and a helper function, setLED() allows easy setting of the intensity for each channel. The variable currentLED is used as part of the background task that maintains the display.

Before that, look at how data is sent to the chip. In the chip driver there is a simple function that selects it, write a word out over SPI and then deselects it:

void MAX6966_putWord(uint16_t data) {
  MAX6966_SELECT();
  spiPutWord(data);
  MAX6966_DESELECT();
}

The code in the SPI driver assumes that the appropriate Slave Select line has been asserted and can concentrate on just putting data out over the SPI:

void spiPutWord(uint16_t data) {
  // make sure the transmit buffer is free
  while (SPI_I2S_GetFlagStatus(SPI_PORT, SPI_I2S_FLAG_TXE) == RESET);
  SPI_I2S_SendData(SPI2, data / 256);
  // be sure that the character goes to the shift register
  while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_TXE) == RESET);
  SPI_I2S_SendData(SPI2, data % 256);
  // be sure that the character goes to the shift register
  while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_TXE) == RESET);
  // and then be sure it has been sent over the wire
  while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_BSY) == SET);
};

This is pretty stock stuff taken from the Peripheral Library Examples. Whenever you send data over SPI, you must first make sure that the transmit buffer is empty. Data is sent MSB first and, for a 16 bit transfer, the high byte goes first. After the transmit buffer is loaded, one of two things can happen. Either the shift register is empty, in which case the transmit buffer is immediately sent to the shift register and becomes available, or the shift register has not finished sending out the last byte so the peripheral has to wait before it can transfer the new contents out of the transmit buffer and make it available. If you don’t wait for the transmit buffer to become available, you will lose data.

After you get the last byte into the transmit register, you must wait until the shift register is empty before returning to the caller. Unless that is done, the caller will probably deselect the target device before all the data has been sent and, once again, you will lose data.

Now we have the chip set up and a way to get data to it. That data consists of a port number and an intensity level. The simplest way to manage this would be to have setLED() write the information directly to the chip. However, I am going to have more than one device on that SPI port and the other device will be using DMA so I cannot be entirely sure that the SPI peripheral will be available whenever I want to send stuff to the MAX6966. My solution is to have all SPI transfers initiated by the 1kHz systick event used by the micromouse.

On each tick, a call is made to MAX6966_update() which send out data for a single LED. That takes only about 8us with the speed I run the processor and SPI so it is not very costly. On each tick, a different LED gets updated so, after only 10ms, all of them have been done. I can update each LED 100 times per second for very little cost in processor time. The DMA transfer for the other device gets started after the MAX6966 is updated so there is no danger of the peripheral being in use for two different devices at the same time.

Here is the code that records the level for an LED:

static uint8_t LEDbrightness[10];
static uint8_t currentLED;

void setLED(uint8_t led, uint8_t value) {
  if (led > 9) return;
  if (value < 3) value = 3;
  if (value > 250) value = 250;
  LEDbrightness[led] = value;
}

The lower and upper limits on brightness exist because values of 0, 1, 2 and 255 have a special meaning to the device. Have a look at the datasheet for more information.

And this is the code that gets called at each systick:

void MAX6966_update(void) {
  currentLED++;
  if (currentLED > 9) {
    currentLED = 0;
  }
  MAX6966_putWord((uint16_t) currentLED * 256 + LEDbrightness[currentLED]);
}

All that doesn’t seem too complicated to me. There are 10 LEDs available (I only use 8 on the micromouse – not sure why now), they can be set to an arbitrary brightness level and they get updated 100 times per second. That’s not too shabby for a couple evenings work and only three traces going to the other end of the mouse – two of which were going there anyway to drive another display.

Here are the complete file listing with all the gory details in one handy zip file:

STM32F4-MAX6966-code