MBI5045 cascade.

Ik heb een printje waar ik een 16bits schuifregister-led-driver op heb zitten. Dat is dan 16 bits, en met PWM op "output enable" kan ik dan de intensiteit regelen.

Toen kwam ik de MBI5045 tegen en dacht: Vrijwel dezelfde pinout, ik maak een proef-pring met die dingen er op en kijk eens of ik die aan de praat kan krijgen.

Nu zie ik op dit moment twee problemen: 1) Ik krijg hem helemaal niet aan de praat. Ik zie zinnige signalen met de logic analyser. Ik moet nog kijken of die op de juiste pins op de chip aankomen dus ik hoop dat ik dat ga oplossen.

Maar 2) Hoe kan je deze in vredesnaam in serie zetten, dat je met 1 setje pins (DCLK, LE, SDI) een zwik van deze dingen achter mekaar kan zetten?

Oh, wacht! Zou het werken als ik steeds 32 bits clock dan een "latch enable" pulsje geef, en op het eind een "global latch"?

Weet iemand, of heeft iemand een gevoel over de global latch? Kennelijk moet dat een "dummy" word zijn. In "full timing for data loading" lijkt het datasheet te impliceren dat dit dummyword maar 7 bits lang hoeft te zijn, terwijl een blz eerder bij "global latch" staat dat ie 16 moet zijn. Ik doe nu 16 trouwens. Ik moet die "7" nog proberen.

Ik heb voorbeeld code gevonden en die deed "global latch" tijdens het laatste 16bit word. En die deed de global latch met maar 2 LE clocks.

Ik heb geen ervaring met deze chip, maar de datasheet lijkt me duidelijk genoeg:

SDO van de eerste naar SDI van de volgende, enz
Alle DCLK aan elkaar
Alle LE aan elkaar

Daarmee zet je alle schuifregisters achter elkaar en krijg je dus een lang schuifregister, 16 bits per chip.

Met LE (neergaande flank) copiëert elke chip de data van zijn interne deel van de schuifregister naar de registers in de chip of andersom. De actie (lezen/schrijven/reset) hangt af van het aantal DCLK pulsen tussen opgaande en neergaande flank van LE.

Dus bij 3 chips in cascade moet je 48 bits schuiven, de LE hoog zetten tijdens de 48ste bit voor een "data latch", en tijdens bit 46 t/m 48 voor een "global latch" en voor een "write configuration" gedurende bit 38 t/m 48.

En voordat je begint eerst resetten (Enable Write configuration):
LE hoog, 15 clocks, LE laag.

Update: Ik heb data naar de chip gekregen. Ik had de pin definities fout. Ik had "wat-is-wat" op de logic analyser gedaan door naar de signaal vormen te kijken. Er is uit een ver verleden een signaal wat NIET naar deze generatie chips gaat, maar wel naar mijn debug-connector. De foute definitie zette het LE signaal op het niet-gebruikte signaal...

Dat niet-gebruikte signaal kan ik in een volgende hardware versie met een jumper aan SDO hangen. Dan kan ik vervolgens dus ook lezen uit deze chips. En ik kan de jumper er afhalen en een volgende module met 16 of 32 bits er aanhangen. :-)

@deKees: Hartelijk dank voor het bevestigen wat ik zelf tijdens het schrijven van de startpost had bedacht.

Mijn huidige code stuurt nu dus maar 16 bits terwijl er 2 van deze chips (32 bits dus) op deze print zitten. De tweede heeft nu dus een "slap aftreksel" van de eerste (1 positie verschoven dus).

Ik heb voor de test de data "random" gevuld, maar het komende halfuur kan ik nog even snel kijken of ik er zinnige data in kan zetten.

En die voorbeeld code, die doet compleet idioot met herhaalde code voor eerste 15 en laatste groep van 16 bits. Dat ga ik nu ook even opschonen.

(ik heb een halfuur voordat ik elders moet wezen).

Wel een complexe chip. Elke led heeft een 16-bit grayscale register en PWM doet die zelf.

Dus je moet 16 keer een 16-bit word in elke chip schuiven, telkens met een "load data" commando om de 16 buffers te laden, en vervolgens een "load global" commando geven om de buffers te copiëren naar de PWM comparators. De PWM doet de chip dan zelf, geklokt via GCLK.

En dat wordt nogal complex met meerdere chips in cascade.

Voordeel is wel dat je voor elke led de helderheid apart kunt regelen. Maar als dat niet nodig is kun je beter een andere chip nemen. Bijv STP16CPC26. Zelf heb ik ooit gewerkt met een TC62D748CFNAG, maar die gaat uit productie volgens mij.

Nadeel van de STP is dat ie 4x duurder is.

Ik heb nu de software voor de MBI werkend. Ik heb geen individuele grayscales nodig. Maar nu het er is zou ik een soeple overgang van de cijfers kunnen maken. Dus dat ik iedere seconde gedurende 0.2 sec een fade van oude-cijfer naar nieuw-cijfer doe. Dat is "leuk" maar niet nodig.

Voor nu stuur ik gewoon "0" als een segment uit moet zijn en "de ingestelde helderheidswaarde" als ie aan moet zijn.

Waar ik voor de tests nu dus een tabel van 32x 16 bits heb die ik naar de chip kan sturen, ga ik voor de echte applicatie straks gewoon de bits uit mijn 32-bit "aan/uit" variabele live uitlezen en naar de chips sturen. Minimale aanpassing aan de rest van de code.

Er zijn een paar ATMEL apparaten in het veld. "no longer supported". Er zijn een zwik STM32 apparaten in het veld. Omdat ik een groot deel van de code heb kunnen porten merken de gebruikers geen verschil. De port naar RP2040 was nog makkelijker. Alleen een paar "support" dingen aanpassen en het werkt voor de gebruiker PRECIES hetzelfde.

De oude prints gebruikten TLC59025IDBQR . Subtiel duurder dan de STP. De MBI zit gewoon op de footprint van de TLC. Ik ben alleen vergeten de weerstand aan te passen. De ingestelde stroom is nu niet 20mA maar 10mA o.i.d. Waar de TLC op 30% helder zat was, ziet het er nu naar uit dat ik op dit prototype met de MBIs op 100% moet zitten.... Voortaan in de assembly-variant met de MBI gewoon de juiste weerstanden monteren.

Ok, dus.. probleem opgelost. :)

Jep. Ik heb nu de code die ik van het internet had geplukt herschreven. Van 50 regels naar 3 waarbij ik nu een hulpfuncite van 13 regels gebruik. Ik heb nu ook "gecontroleerd" de tweede MBI chip aangestuurd ipv dat ie gewoon de "oude data van een ronde eerder" pakt. Nu de "send data" herschrijven en een config optie maken om de ene of de andere chip te gebruiken. :-)

(Ik doe nog niets met het config register. De fabrikant heeft gewoon gezorgd dat je direct aan de slag kan met redelijke instellingen. Oh! Ik kan in de config ook zetten dat ik globaal een andere helderheid wil hebben. Hoef ik niet "live" de intensiteit te sturen... )

Update: De klok doet het met de MBI chip. 1 segment werkt niet. Zoek ik later op welk pinnetje ik moet hersolderen.

Update2: verkeerde pennetje gesoldeerd. Hielp niet. Juiste pinnetje gesoldeerd. Hielp niet. Verbinding gecontroleerd: Is aanwezig. Segment met de hand aan de voeding gehangen: Werkt niet. :-( Segment is gewoon kapot. :-(

[Bericht gewijzigd door rew op (13%)]