Thoughts on BLMs

[latigid on]

Just continuing a discussion started in a pic from Sauraen. I asked if he noticed any problems driving that many LEDs, the answer was that everything worked out fine.

Psykhaze asked about 74HC541, but this is implemented in the Core to take the load off the MCU driving the SRIO lines. (For better results resistors should be added at the 541 outputs to control the impedance/attenuate reflections.) Also, some degree of PWM control is possible in LED matrices but of course limited by the 1/8 multiplexing. There are LED driver chips as mentioned, but they run over SPI. The beauty of shift register designs is (as mentioned) wide availability, but from a programming perspective the usage is also very simple -- once the matrix driver is written -- just send a series of bits and latch in a regular cycle; the low processor overhead is easily predictable. 

While the standard BLM uses 220R /13mA peak for red LEDs, the BLM 16x16+X is driving blue LEDs with 56R, so more like 35mA peak. Of course only one 595 output will be on at a time with 1/8 multiplexing. Still, turning multiple LEDs on drops the supply voltage, so much so that I needed a power up delay to allow the logic to stabilise, and a local buck-boost regulator helped. My feeling is the "high" current demands put on the anode drivers could do with some improvement. 

From the current sink side, this is already solved by using NPN bipolar transistors. The row scanning means 8 or even 16 LEDs could be on at a time, but that's no problem for the transistor. An N-channel MOSFET would likely do a better job, but these are a bit more expensive with lower availability, and are more prone to ESD. Another common method is to use a ULN2803 (8-channel Darlington) current sink. The issue is the extra PN junction has the effect of raising 0V/ground, which in turn can cause problems triggering the DIN side, especially if the supply starts to sag/droop.

It seems fine to use a plain old 595 output to drive LED anodes at low current. But what about higher current LEDs, or organ pipes? The simplest method might be to use a common emitter PNP with base and collector resistors. If a higher source voltage was needed, a cascaded NPN/PNP would work. (If a PNP had 12V supplied to the emitter and 5V switching on the base, it would never turn off.)

Getting fancier, there are chips numbered 2981 which act as source drivers. The UDN2981 is from Allegro (availability isn't great); the MIC2981 can be ordered at Mouser with good stock levels at the moment. So maybe that's the answer. TPS2080/2081/2082 (dual) and TPS2085/2086/2087 (quad) look okay as chip-based MOSFET high side drivers.

There are shift registers with better sinking capability (e.g.  TPIC6595), but there's only one I've seen for sourcing: MIC5891. On paper it looks good (have to check the programming), but the pinout is different -- actually nicer than 595 IMO -- and I'm a bit wary of using "specialist" chips for long-term availability. 

Now I've got all of those part numbers down I can close most of my browser tabs :-)

 

[Psykhaze]

Right, I forgot that some 74HC541 Line Drivers are on the core board already ^^

I am wondering what's the real problem with SPI?
i know that an I2C implementation would be somewhat easier moreover regarding available ports (J4A / J4B > I2C, only J19 offering SPI and should be reserved for analog) and that's almost like SRIO works.
To me Shift register are quite Ok for everything they are bound to , only the LED paradigm might need some recent thoughts because the current thing or RGB PWM.

About "pure" I/O expanders i also noticed MCP23017 / MCP23S17 from microchip (configurable 16 I/O) >MCP23017/MCP23S17 Datasheet<
Wide packaging options, Driver Source code widely available or easily portable (example https://github.com/dreamcat4/Mcp23s17)

SPI chips are for sure not as "long-term" as Shift registers but might offer recent features and practical sides (i especially think about Huge RGB config where using shift register might be harder than using an SPI thing because of big number of lines).Cross & Retro Compatibility are important for sure but for some config i guess that betting on some of these SPI things might make the design a lot easier by lowering BOMs , improving routing and component number,decreasing global price and offering Increased Control. (think about a 16x8 matrix in RGB for example) To me the only problem about SPI chips is availability in time but it might be a middle term alternative.

Nevertheless, Using PNP / MOSFETs / LED buck boost sound a good practice to me , but regarding the size of MIDIbox configurations (Excepted BLMs) it might be more a painful and somewhat not really useful thing. SR can handle their hybrid role managing Current and Control on small to medium Config , keeping the BOMs small. Look what sauraen did on the Genesis CS, using only Shift registers (+few row drivers)

But (Big/Non-Serial RGB) BLMs might require something better to handle it than a ton of shift registers. And in this case , using "power drivers" and SPI/I2C LED drivers might sound really more making sense.

Edit : some nice I2C LED drivers from NXP , known as offering better long time support than maxim : 
http://www.nxp.com/products/interfaces/ic-bus-portfolio/ic-led-display-control:MC_48878
Link to LED driver SPI chips from Maxim mentionned in the Picture Conversation: 
https://www.maximintegrated.com/en/products/power/display-power-control/MAX6960.html
https://www.maximintegrated.com/en/products/interface/controllers-expanders/MAX6966.html

Also notice that regarding respective bus speeds , an I2C emulation -might- be coded over a SPI I/O chip  like MCP23S17
Principle : http://www.microsemi.com/document-portal/doc_view/130041-ac324-spi-to-i2c-interface-app-note
 

Edited February 4, 2017 by Psykhaze

[latigid on]

Put it this way: you already need some sort of button scanning via a DIN (columns) and a DOUT (rows). With just one more 74HC595 register you get LEDs for "free." 

Note I2C LED driver stuff has already been done by Ander (Station). Just not in "regular" MIDIbox projects.

 

 

 

[Psykhaze]

That's a way it could be done , i was sure i have seen the piece of code for this somewhere on the svn but after minutes struggling i can't manage to find it again. If i remember well he used some 93XX from NXP.

The why about the MCP23017 / MCP23S17 is that it is having configurable GPIO ( 16 pins acting like or DIN or DOUT depending on the configuration,with possible mixed design) , twice the number of a serial register > for example 2 of these to scan a 16x16 BLM buttons> Lowered number of components. And the argument of mixed I/Os might allow customs I/Os mixed designs based upon only one kind of IC.Once again,it's just a thought. It has been used widely in the arduino world.

My other point is about RGB LEDs PWM and cost/number of IC used. Can be done with many I2C/SPI chips, like Ander did with the station (Do anybody remember the chip he used or where the code is?) , or serially with WS2812-alike like you used on your sparkfun pads @latigid on . Problem with ws2812 despite the great design is the price (and sometimes size, being most of the time 5mm-wide on sizes, even on SMT).

When i purpose about MAX6960 especially , it was because it attracted me with it first purpose , being a bicolor(R/G+Y) 8x8 matrix driver , that could be extended to RGB (BLM) designs and easily chainable. (remember old MBHP Bicolor BLMs? ^^)

Some DIP (even SMD) RGB or bicolor LEDs are really cheap to get x1000 units (and size decreased compared to WS2812) and the column-row driver design attracted me because of the all in one design that could manage 16x8=128 monocolor leds at once , with PWM or 8x8 Bicolor Matrix. Just another though,that is not an -absolute- solution purposal but just one way that could be used to decrease components number, with qualities and defaults too =)
 

Edited February 4, 2017 by Psykhaze