jovak
meten is weten, weten is meten, maar hoe kan je weten wat je allemaal moet meten en weten.
Op 6 september 2007 06:56:09 schreef fotoopa:
[...]Oja, ik heb 2 rijen pinheaders op het boardje gesoldeerd (bovenkant) om de buitenste 40 pinnen op een flatkabel aan te sluiten. Die 40 pins zijn dan compatiebel met al de andere boards van terasic en dit vereenvoudigd bepaalde testen door ze steeds op dezelfde pinnen aan te sluiten. In de loop van de dag probeer ik in het voorbeelden topic een 2x16 lcd display met 8x8 matrix keyboard als voorbeeld klaar te hebben. Daar zal dan ook de pinout voor die externe aansluiting bijkomen.
Die pin headers was ik ook van plan. Als ik een ontwerp heb waar de FPGA correct werkt ga ik wel een ander bordje bouwen waar ik de uiteindelijke hardware op bouw. En tot die tijd heb ik een leuk speelgoedje. 
Terug een update van het lopende moodlight project.
Na het volgen van andere RGB led sturingen met PIC's ben ik terug mijn project gaan bekijken en vereenvoudigen waar mogelijk. Ook was er een vraag naar 128 RGB leds sturen.
Mijn voorgaande konstruktie, een combinatie van 100 RGB leds en 400 witte leds gaan niet door. Na een analyse van de mechanische konstruktie is gebleken dat er geen goede oplossing was voor de gecombineerde lichtverdeling.
Dan maar terug naar de RGB versie. Het huidig ontwerp is nu gebaseerd op 128 RGB leds. Dit zijn 384 stuurpunten of pwm's met een resolutie van 8 bit. Die opstelling is niet gewijzigd, ik vertrek van 2 groepen zodat de matrix nu 2 x3 rgb x 64 leds is. Omdat alles in de FPGA komt hoef ik enkel de 64 leds vertikaal te sturen elk met een kleine FET direct van de I/O's van de FPGA. Er is hiervoor bijgevolg vrij weinig extra hardware nodig, omdat de gate direct mag aangesloten zijn komt dit neer op 64 draden verbinden. Hieronder het schema:
iedere fet bevat 6 leds, samen iedere maal 2 volle RGB leds per knooppunt. De stroom hiervoor wordt via een multiplexer horizontaal toegevoegd via 6 powerfets. de spanning kan hierbij aangepast worden omdat een rode led minder ledspanning heeft dan de andere 2 en gezien we slechts 1 gemeenschappelijke stroombegrenzings weerstand hebben moeten we daarmee rekening houden. Maar dit is zeker niet moeilijk.
De pwm heeft 8 bit resolutie, of 256 scans. Een volledige pwm scan is 64 x 2 x 3 x 256 pwm clk's = 98304 bits informatie. Bij een refresh van 50 Hz wordt het totaal aan databits: 95232 x 50 = 4915200 bits. Dit komt overeen met een clock van 5 Mhz en een rekentijd per bit van 200 nsec.
Even een nieuw blokschema, behalve de SRAM en de FLASH blok zit alles volledig in de FPGA:
Die 64 bits zitten telkens in een 64bit dreg en een extra 64bit shift register zet de volgende informatie klaar (in de FPGA). Dit maakt in totaal 128 LE's die we hiervoor nodig hebben, enorm weing dus!
Tussen iedere pwm cloktijd moeten nu de volgende 64 fetleveldrivers berekend worden. Hiervoor gebruik ik slechts een 8 bit comparator omdat ik de 8 bit pwm_progwaarde per ledsturing uit het geheugen haal en heel snel alle 64 volgende compairs bereken. Die pwm progwaarde ga ik ook nog eerst herberekenen met de dimmer encoder stand zodat ik voor iedere led een totaal nieuwe berekende pwm_progwaarde bekom inclusief dimmer functie.
Die berekening doe ik zo:
Geheugen 8 bit waarde x 8bit encoder waarde (0..255) resultaat is een 16 bit produkt en de hoogste 8 bits zijn de nieuwe uitgangswaarde volgens de dimerstand. Die berekeningen gaan razend snel in hardware en resultaten worden na het vergelijken met de pwm_cnt_stand via de 64 bit shift register klaar gezet. Bij de volgende pwm_clock worden die 64 bits van de shiftregister overgeladen in de 64 bits dreg.
Alle informatie om de 128 RGB leds in een opgelegd patroon aan te sturen kunnen vanuit 3 plaatsen komen.
We hebben 49.152 bits interne ram gereserveerd van de FPGA zelf. Daar kunnen 16 x 3072 bits in of 16 verschillende patroontje. Maar realtime kan er vanuit een externe toevoer gelijktijdig nieuwe data in die ram bijgevuld worden zodat we een kontinu scan proces kunnen uitvoeren.
Maar op vb een DE1 board zit er ook externe SRAM en FLASH geheugen. Omdat dit geheugen enorm groot is kunnen daar heel veel sequentie's met totaal verschillende patronen in. Voldoende om daar uren data mee te sturen. Die FLASH is eerder een vaste opslag maar die SRAM kunnen we opnieuw opvullen met totaal andere patronnen zonder direct gebonden te zijn aan strakke timingen. Een adrs generator/sequencer moet dat verkeer regelen.
Mede door deze nieuwe aanpak heb ik maar heel weinig LE's meer nodig. Als je nu gebruik zou maken van extra shiftregisters zoals de 74HC595 zou je deze RGB sturing drastisch kunnen opdrijven met dezelfde FPGA waarbij je de I/O pinnen over die extra 74HC595 registers kunt expanderen. 1024 RGB leds aansturen blijft dan nog eenvoudig, tenminste als je in dat geval het werk van die externe 74HC595 ic's niet meerekend. Maar tot 128 RGB leds heb ik er geen enkel nodig.
Ik werk nu verder aan een gecompileerde versie die ik dan op een kleiner schaal zal testen maar wel voorzien van de 128 RGB versie aansturing maar vb 8 leds aangesloten. Ik zal dan voorbeelden met de logic analyser geven van bepaalde belangrijke signalen.
Als het nodig is om een aantal I/O lijnen te sparen kan ik ook die 74HC595 gebruiken om van 1 naar 8 outputs te gaan.
De shift clock wordt 5MHz voor 50 Hz led refresh en in totaal 128 RGB leds. Ik heb dan 200 nsec de tijd om die databit te berekenen (inclusief die multiplay) wat voldoende moet zijn ( pipeline systeem maken). Ook is het mogelijk de berekening te ontdubbelen waardoor de rekentijd op 400 nsec komt. Hé dit wordt toch al een mooie schakeling. Mijn logicPort 34 kanaals analyser zal hierbij goed van pas komen ( Is trouwens een uitstekende analyser, reeds heel veel testmetingen gedaan op complexe trigger voorwaarden!)
De basis opstelling voor het aansturen van de leds ligt nu definitief vast. Hier het basis schema:
Deze opstelling bied een aantal voordelen vooral naar uitbereiding voor het aantal leds dat je wil sturen. De tekening toont 8 powerlijnen horizontaal boven wat overeenkomt met een multiplex verhouding van 1:8. Maar de opstelling kan vrij eenvoudig gewijzigd worden naar elke andere multiplex verhouding vertrekkende zelfs van 1:1. Ook de RGBled montage wordt hierbij vrij modulair naar bestukking en/of uitbereiding. Immers iedere led heeft 3 stuurpunten en als je multiplexed moet je enkel vertikaal bijkomende leds monteren en gewoon de draden vertikaal per R, G en B lijn doorverbinden.
Horizontaal staan de RGBleds per 16 stuks (48 stuurlijnen of I/O's) vertikaal zijn er 8 rows wat in totaal 128 RGBleds heeft. Hoe je die nu mechanisch opsteld speelt weinig rol. Kan vb 8x16 zijn maar ook 10x12 ( slechts 120 RGBleds), of 9x14 (126 RGBleds) enz.
Ondertussen heb ik de FPGA volledig uitgewerkt en getest. 128 RGBleds geven 384 pwm stuurkanalen. Deze zitten intussen allemaal in mijn FPGA en de outputs zijn op enkele testleds aangesloten maar ook op de logic analyser om de korrecte werking hiervan te kontroleren.
In totaal verbuik ik 1350 LE's en de stuurdata komt van een externe 4 Mbyte flash die op mijn board staat. Ik heb in die flash random data ingestoken om de 384 pwm's gemakkelijk te kunnen voeden.
De pwm_clk draait op 2 Mhz, de resolutie is 8 bit ( 256 levels) en de frame rate, dit is de totale tijd nodig om alle leds 1 maal aan te sturen is 1024 usec of ongeveer 1 msec. ik ga dus 1000 maal (geen 50) per seconde alle data updaten waardoor ik voldoe aan de max pulsduur bij het multiplexen van ongeveer 128 usec bij 1:8 duty cycle.
Het is gewoon ongeloofelijk hoe goed al deze pwm's draaien. Ik gebruik ook een rotary encoder die realtime de helderheid regeld van alle leds. Daarvoor wordt iedere kleur inputwaarde vermenigvuldigd met de rotary encoder waarde. Ook hier is de dimmerfunctie 8 bit resolutie waardoor je 256 stappen hebt om die regeling te maken. maar niets weerhoud je om 1 rotary encoder te gebruiken per kleur waardoor je een soort kleurwiel aansturing kunt realtime maken.
Hierbij nu een voorbeeld hoe je een aantal pwm's ziet tijdens hun werking. Ik heb de LA aan een aantal pwm's gelegd, en als trigger heb ik het uitleesadres $0000 van de flash gebruikt. Hierdoor weet ik precies waar iedere data byte van de flash als pwm outputsignaal te zien is.
Even verduidelijken:
led0_R is de eerste byte uit de flash en heeft de waarde 7B. De overeenkomende pwm staat boven links op het scherm en de cursors B en C duiden de pwm pulsbreedte aan, staat op 61 us in de status lijn. Iedere pwm clock is 500 nsec, 61 usec zijn dus 122 pwm clocks. Omdat ik vermenigvuldig met de helderheid van de encoder die op 255 staat wordt de waarde net 1 lager ( ander zou ik met 256 moeten vermenigvuldigen wat 1 bit extra is) $7B = 123 -1 is 122.
De volgende pwm rechts in beeld staat aangeduid met de cursors D en E en bezit een pulsbreedte van $AC of 172 clocks -1 wordt 171 of 85.5 usec. Omdat ik de flash routine heb gemaakt tot 64 leds horizontaal zit de volgende pwm $40 bytes verder vandaar dat adres $40 waar je de data moet aflezen.
Ik stuur nu wel degelijk alle 384 pwm's en de data komt uit de flash maar kan evengoed uit een SRAM of gewoon serieel binnengebracht worden.
Nu ondervind ik nogmaals de waarde van zo een logic analyser, je ziet heel snel waar er iets mis loopt omdat je alle data kunt volgen. Gewoon onmisbaar en ik heb erbij wel gegelijk al mijn 34 kanalen van de LA gebruikt.
Tot mijn grote verrassing kunnen deze 384 pwm's ook met het heel kleine MAX II nano gestuurd worden.
Beste heren,
Ik ben zeer benieuwd naar jullie project. Ik heb zelf een soortgelijk plan om met 128 rgb leds iets te maken.
Ik hoop dat jullie me d'r een beetje me kunnen helpen.
Het idee is op mijn achterlichten van de auto van RGB leds te maken, zodat ik dan zelf kan programmeren waar het knipperlicht zit en welke vorm en kleur hij heeft.
kortom een soortgelijk project maar dan met 6 Digitale ingangen ( knipperlicht links, rechts, remlicht, achterlicht, mistlicht en achteruitrijlicht )
Dit verdeeld over 2 lampen met elk 64 RGB leds.
lijkt me cool toch
Ik hou jullie post in ieder geval in de gaten
mvg,
Passion
Ik vraag me af hoe je daarmee door de autokeurig gaat gaan?
Je hebt mogelijks wel 128 rgb leds maar functioneel liggen de meesten toch samen.
Als ik het goed begrijp is je toepassing te herleiden tot enkele basis functie's, veel veel minder dan wat ik hier voorstelde.
Geachte Fotoopa
nou voor de keuring gaat helemaal goed komen als ik maar niet het programma met bijv blauwe pijlen als knipperlicht kies dan komt het zeker goed... hihi
( Das alleen iets voor op een meeting )
de enige restrictie is dat je een reflector moet monteren en dat achterlichten rood zijn en achteruitrijlicht wit.
Kortom zoals ik al zei ik hou het in de gaten en hoop dat als jullie Moodlight klaar is ik er een gedeelte van kan gebruiken voor mijn project
ook wil ik nog ven kwijt dat ik respect heb voor wat je zoal op het forum doet !!!
mvg Passion
Beste Fotoopa,
Ik vroeg me af of u op de hoogte bent van het bestaan van LED-driver IC's zoals de TLC5941. Dit is een 16 kanaals constant current LED-driver met ingebouwde 12-bits PWM en 6-bits DOT-correctie, speciaal gemaakt voor applicaties als de uwe. Doordat ze serieel zijn door te lussen kun je met slechts 7 I/O-pinnetjes met gemak b.v. 512 LED's aansturen. Dit maakt het ontwerp zeer eenvoudig en modulair, een simpele microcontroller of cpld is al genoeg voor de aansturing. En de LEDs zullen een langer en gelukkiger leven leiden als ze met een constant-current source worden aangestuurd.
Het is eigenlijk jammer dat zulke dingen bestaan, soms is het leuker om het wiel zelf uit te vinden.
Op 11 oktober 2007 11:46:52 schreef Mr. Brown:
Beste Fotoopa,Ik vroeg me af of u op de hoogte bent van het bestaan van LED-driver IC's zoals de TLC5941.
Ik had idd die al gezien maar niet veel aandacht aan besteed. Maar met de datasheet nog even te doorlezen is het wel een prachtig ic. Ik zou er 24 nodig hebben voor al mijn 384 RGB punten. Ze kosten ongeveer 3$ per stuk maar afzonderlijke fets zouden nog meer kosten. Datarate om 50 x per sec te refreshen lijkt ook geen probleem, trouwens er kunnen ook een aantal chips parallel aan dezelfde clk hangen, dan moet je maar de data lijnen ontdubbelen. Ik zie dat ze werken tot 30Mhz, er is slechts 200Khz nodig voor 384 punten. De dot korrectie kan waarschijndeljk geladen blijven blijven.
Het valt te bezien, maar mijn DE1 board wordt dan overkill, maar het MAX II boardje zou dan weer perfect passen. Ik ga er nog wat verder over nadenken. Immers het uitsturen zou een goede oplossing zijn, maar de inteligente data opwekken zou toch een DE1 taak kunnen zijn vooral als je met flash geheugen wilt werken of SDcard en die zitten op de DE1, ook de USB connectie is daar aanwezig als je het geheel wilt koppelen met vreemde data.
Ik bekijk het nog een grondig.
Ik heb er zelf pas geleden een aantal samples van aangevraagd, wil eerst even goed testen of het combineren van meerdere outputs goed werkt, maximale stroom per output is nl 120 mA, ik wil er 3 combineren om 350 mA te kunnen aansturen (1 Watt PowerLEDs).
Ga er in totaal 512 RGB power-LEDs mee aansturen, waarschijnlijk ga ik het opdelen in 4 aparte serieele strings om de klok niet onnodig hoog te laten worden.
Aansturing doe ik voorlopig met een EP2C5, later misschien met een ARM7-microcontroller om eenvoudiger een grafisch lcd te kunnen aansturen voor een uitgebreide gebruikersinterface met menu's e.d.
Ik ben nog op zoek naar Verilog-code voor het DMX512-protocol, als iemand nog wat heeft liggen houdt ik me aanbevolen (als ik het wiel niet zelf hoef uit te vinden, doe ik dat liever niet).