Macroblock data sheets - awful or just me?

[Nogtail]

I've got a project that requires controlling a few thousand LEDs. Macroblock has a few drivers that seem like a perfect fit. The only downside: their documentation is an absolute mess.

The datasheet has pretty much no mention of how to actually use the bloody things - instead being filled with register descriptions where every bit is "reserved". Seriously, why bother mentioning a register if the whole thing is reserved? They have 4 whole pages taken up with that crap! Thankfully, I've got some application notes that completely disagree with the datasheet at just about every opportunity. Both the datasheet and application note mention things that are never referenced again, for example: "dummy time" is mentioned twice, with neither occurrence bothering to expand on what the hell it is or how long it should be.

Somehow the datasheet and application note also have a contradictory set of default register values - both of which are different to the values I get when actually reading the registers. They can't even decide if a register is reserved or used for "GCLK change". And no, I have no idea what "GCLK change" is or what it's useful for because the damn documentation never tells me. To top it off, there's a bunch of undocumented behaviour that appears to make the stupid thing not work unless you do things in a very specific sequence that I've only managed to find through sheer dumb luck.

Anyway, rant over. Am I an idiot or does Macroblock documentation just suck?

[exmadscientist]

Many Macroblock drivers have TI equivalents. (I have no idea who's cloning what.) The TI datasheets may help. Which part are you looking at?

[mikeselectricstuff]

Many Macroblock drivers have TI equivalents. (I have no idea who's cloning what.) The TI datasheets may help. Which part are you looking at?

But not the more interesting ones.

All the ones I've used did correspond to the datasheets, but sometimes after a bit of interpretation of what the datasheet meant.
It is worth asking your supplier for the latest info as this can be more up to date.

But in the end you pretty much need to build some hardware and poke at it with a scope to until you understand what's going on. The devices aren't typically very complicated.

They tend to be oriented to controlling with FPGAs - I've often spent more time figuring out how to bend MCU peripherals to drive them (e.g. using PWM to generate different latch pulse widths) than figuring out the protocol.

[tszaboo]

So I looked at a datasheet, on the block diagram they had 3 different symbols for an IO pin. Somehting called an Internal_osc which I assume an Internal oscillator has the same diagram as an IO pin. The package is called (TSSOP-28-EP) at one place, that assumes a heatsink pad in the middle, which is not on the drawing. The package outline is a screenshot from someone else's datasheet. Thermal information, pretty important for an LED driver, TBD, datasheet is from 2018.

I rate it as F for no effort.

[mikeselectricstuff]

From the responses I've had from them via my distributor, they seem accustomed to having to hand-hold people developing with them ( maybe if their datasheets were better..!) , and hence can be reluctant to deal with smaller buyers - they sell in gazillions to LED video panel manufacturers.

Whenever I've enquired about data or pricing on new parts, they want to know details of the application to check suitability - last time I told them what column drivers (TI and MB) I was looking at using with their high-side switches, they initially came back saying those drivers couldn't be used in my application. When I emailed back pics of working prototypes they shut up & just sent the data & pricing!

IME there can be subtle differences between apparently similar parts ( e.g. the LE to latch data being on the last word, or an additional dummy one afterwards), and in one case making a significant functional change between revs of the same part.
 
On the other hand they are typically much cheaper than TI, so worth a bit of effort to understand.

TI can also be almost as bad though - just look at the LP5890 datasheet, with poor English and many barely-documented registers.


 

[Nogtail]

As it happens I almost used the LP5890 instead, so maybe the grass wouldn't have been much greener in camp TI!

I've been looking at their multiplexing drivers with an embedded frame buffer to hopefully avoid using an FPGA. I've got a prototype built up with some MBI5253's hooked up to a RP2040 using one of the PIO blocks to drive them. I've managed to get it displaying some test patterns but I don't have a lot of faith in it being particularly robust given I barely understand how to drive the things.

Thankfully my local distributor didn't ask too many questions and sent me the datasheets/app notes. It's not something they'd be interested in considering it's a one-off project that only needs a handful of drivers, so I don't want to pester them too much.

I've already been bitten by their subtly different functionality between parts when trying to use datasheets from similar parts to find some of the missing information. I'm not sure what compels them to make so many minor changes to parts that would otherwise be fully compatible.

[Mahagam]

I have positive experience with TLC5951 and TLC5955. But I need to significantly increase the PWM frequency. So I am considering LP5890 (and its almost a copy - TLC6983). And yes, I can`t understand some of the register descriptions from datasheet.

[mikeselectricstuff]

I did ask TI about some of the LP5890 registers, got a vague response about some proprietory techniques for improving colour displays so didn;t bother persuing further.

I was doing a mono 80x80 display so not a big deal - got it working fairly easily on a PIC32MX174 using framed SPI mode, even the LED open/short detection stuff, which was, er,  interesting....

Starting from the register settings in their devboard example code for their dev board helps a lot. Once you've figured out the basic transport protocol it's actually fairly straightforward, though I still don't entirely understand how the cascading/shared-row thing works, it seems to "just work".

If using an MCU you absolutely need a SPI peripheral that can do the continuous clock ( or maybe use PWM to make the clock and an SPI slave to send the data). If it can do 17 bit frames that helps, otherwise there's a lot of bit-shuffling to do.

[mikeselectricstuff]

I've used the TLC5955 too, as well as teh 5971, 5973 and a few others  - one annoying thing about TI is it seems every chip uses a different protocol. Most of them are prettty sane, but a bit of a pain to keep having to implement new ones...