Sure Electronics Led-matrix driver for Netduino.

Posted by Mario Vernari Saturday, February 09, 2013 7:06:00 PM
Rate this Content 0 Votes

Led driving is one of the most requested things to do with Netduino. I think it's because leds are nice, colored, and have thousands of applications.

Here I'm going to present how to interface a Sure Electronics HT1632-based led-matrix module to a any Netduino, although I strongly recommend to consider the Netduino Plus) 2, due the major resources availability.

Each led-matrix module is composed by 32x16 bi-color leds, which can light green and/or red. By mixing both the colors, the dot appears as bright orange. Unfortunately, there's no ability to dim every single led. Physically, the board ships with four HT1632 controllers, each one drives two 8x8 bi-color led-matrix module.

The module itself is very well designed and also relatively simple to interface to any microcontroller, because its SPI-like protocol require no particular complexity to implement. However, the HT1632 led controller requires a 12-bit data format, which is not natively available as "pure-SPI" on many MCUs. The STM32 is one of them!

Finally, it's worthwhile noting that the module embeds a little logic for addressing the HT1632 chips. The Sure engineers found a very smart way for addressing a cascade of controllers, so that many modules can be pipelined without any pain. However, at the moment of writing this, the driver is tailored for just one module (i.e. no pipeline supported).

As a personal consideration, several Sure modules can be accustomed horizontally, for a perfect long striped matrix. However, the tall PCB yields hard time for a vertical extension of the matrix.

 

The HT1632 SPI-like protocol.

Given the specs, sooner I realized that there's no apparent way to use the native SPI of the Netduino Plus 2 as communication. Its STM32 supports only 8- or 16-bits per symbol, but the HT1632 couldn't accept a similar length.

The most straightforward alternative was bitbanging the whole protocol, bit by bit. I know, the new Netduino is much faster than the old one, but a such a overhead won't give me any satisfaction in terms of speed.

Instead, I found an hack, which I'm proud of, because it leverages the weakness (I'd say an hole) of the Micro Framework.

As you know, the TristatePort is not useful just for its ability to change direction, but also (especially) because can be shared with other ports. This implies that you can declare an OutputPort on a certain pin, then creating a TristatePort on the same pin without bumping against any collision. Let's say the "actual value collision" is a concept that you have to deal by yourself.

So, just to be clear:

 

public class Program1
{
    public static void Main()
    {
        var p = new OutputPort(Pins.GPIO_PIN_D0, false);
        var q = new OutputPort(Pins.GPIO_PIN_D0, false);    //leads an exception at runtime
 
        // ...
 
        Thread.Sleep(Timeout.Infinite);
    }
 
}
 

But the follow one works fine instead:

 

public class Program2
{
    public static void Main()
    {
        var p = new OutputPort(Pins.GPIO_PIN_D0, false);
        var q = new TristatePort(Pins.GPIO_PIN_D0, false, false, Port.ResistorMode.PullUp);
        q.Active = true;
 
        // ...
 
        Thread.Sleep(Timeout.Infinite);
    }
 
}
 

Well, that's *not* the weakness I meant: that's an useful feature, instead. The actual weakness, IMHO, is that the sharing ability is allowed even on other "special" ports, such as the SPI!

The most amazing fact is that you can open and fully use your SPI, declare some TristatePort-s on the same SPI pins, then interfere arbitrarily with just playing with the TristatePort-s value.

From a reliable framework perspective, I'd be scared by seeing that: a stupid mistake could lead to unpredictable behaviors. But from an hacker viewpoint that's simply awesome because it leaves a door open for a trade-off between the native SPI and the bitbanging technique.

Thus, my hacking was to "add the missing pulses" via bitbang, then leave the rest of the message in the SPI hands. This way yielded me a relatively high speed most of the time, whereas the slowness of the bitbanging is just a minimal section of the protocol.

I wouldn't go deeper in the implementation details, but the real driver implementation is very simple. I'd rather say that the most difficult task is dealing among the HT1632 specs, the actual Sure module logic specs, and the optimization of the C# software in the Netduino.

That's all!

 

How to wire the boards together.

Another interesting point of this project is the simplicity of the hardware implementation.

The Sure module comes with two kinds of connectors: a two screwed-pins header for the power supply, and a 8x2 flat header for the logic. These connectors are doubled for a convenient pipelining of more modules.

I strongly suggest to consider the proper connector for the supply: the board can reach over 500mA when totally lit. Moreover, I would discourage to plug the same supply for the Netduino and the led module, unless it is very well filtered as noise rejection. I experienced several troubles in the data exchange due to the heavy ripple in the power supply. That's because I recommend a dedicate, linear-regulated (i.e. non-switching), +5V PSU just for the led board: I used a very common LM7805 for that.

WP_000286

I also added a 1000uF/25V electrolytic capacitor on the +5V rail.

WP_000287

The Netduino can be powered via USB (my case since it's an experiment), or any dedicated PSU can fit the purpose.

About the logic header, the wiring is very simple: the Netduino output ports can be tied directly to the header. The led module works entirely at +5V, but its inputs accept also a lower voltage logic, thus even a +3.3V logic-high is fully recognized.

The only requisite is a pull-up resistor for any of the signals involved. That's because the STM32 MCU places all the I/O in a three-state during power-up, but a valid state should be ensured anytime. I can't believe a bunch of inexpensive resistors could be an issue.

Netduino-SureHT1632_bb

The driver code, as well as several demo, will be posted in my Cet Toolbox repository.

Have fun!

 

Comments are closed on this post.