Hier zijn veel topics aan gewijd maar mij is iets opgevallen. Als je een array van LED's aan de PIC hangt heb je een hoopt transistoren nodig (1 per uitgang).
Nou weet ik dat er van die leuke ULN drivers zijn. Maar ik zie bij schakelingen waar mensen deze hebben gebruikt, dat ze ook nog eens transistoren hebben gebruikt.
Die ULN zijn toch leuk om te pakken om de transistoren volledig te vervangen?
2de vraag:
Ik wil een array van 8 RGB LED's aansturen waarbij ik naar keuze alle 8 een indivuele kleur/aansturing wil geven. Hoe kan ik dat het beste aanpakken? Ik neem aan dat ik per LED de 3 kleuren tegelijk moet sturen om de goede kleur te krijgen.
Zou ik dan dus gewoon 3 uitgangen nodig hebben, 1 per kleur en dan met een schuifregister per uitgang door alle LED's heen schuiven? Komt dat met de timing uit omdat je een PWM signaal naar die registers loopt te sturen?
Zoiets ?
4x 74hc595 schuifregister, en aan de onderkant 4x uln 2803 buffer. 32 kanalen 8 bit PWM 
Ben al tijdje mee aan het knutselen, en werkt nu redelijk snel.
Met de nieuwe PIC-starters bestel ik een aantal RGB strips mee. En ga ik alles aansluiten
Interesse ? Wss wordt het wel weer een SK 
Ziet er weer leuk uit Gamba.
Met de eerste 2 heb ik meegedaan dus aan een 3de zal ik ook wel weer meedoen 
. En als het geen SK wordt heb ik nog steeds interesse .
Zeg bestel je al je printen bij Niels of maak je het zelf? Spaar je dan alles op ofzo want voor elk printje een nieuwe bestelling is nogal duur. Daarnaast vraag ik mij af hoe je losse projecten kunt samenvoegen tot 1 gerber file.
Maar even terug on-topic:
Vanuit de ULN's ga je rechtstreeks naar de LED's toe dus? Dus geen FET's/Transistoren meer nodig? Want dan ga ik dat hier ondertussen al vast doen.
Ziet er goed uit. Ik ben ook op zoek naar iets met veel PWM kanalen. Van waar haal jij die 32 kanalen dan?
Nou ik heb nog geen antwoord op mijn vraag maar als mijn idee kan snap ik hoe hij het heeft gedaan.
De gebruikte PIC heeft een PWM circuit voor maar 1 uitgang. Logischerwijs zal hij daar dus helemaal geen gebruik van hebben gemaakt. Echter doet hij de PWM waarschijnlijk puur in de software. Daarin maakt hij PWM voor 8 uitgangen (lekkere timing ).
Door nog 4 uitgangen extra te nemen, 1 voor elke schuifregister. Kan hij dmv die laatste uitgangen de schuifregisters 1 voor 1 enable-en (elke keer maar 1 actief) en de 8 uitgangen daar heensturen. Door snel genoeg te schakelen tussen de schuifregisters kun je dan het PWM signaal goed rondsturen naar alle 32 uitgangen (= 8-bits schuifregister x 4).
Ik weet niet of ik het juist hebt want ik weet niet eens of het kan. Dat is nou juist mijn vraag waarmee ik dit topic heb geopend. En het lijkt wel alsof hij die schuifregisters gewoon parallel gebruikt: 8 bits in, 8 bits uit.
Je zou nml ook met minder uitgangen kunnen werken, bv 4. En op die 4 uitgangen serieel de data sturen naar de schuifregisters. Deze kunnen vervolgens de seriele data omzetten naar parallele data en die op de eigen 8 uitgangen aanbieden. Maar misschien is timing in de software dan nog moeilijker. Zoals ik al zei, ik heb er nog helemaal geen kaas van gegeten .
Dus verbeter mij maar..........
(Ik hoop dat hij alle vragen in mijn beide reacties kan beantwoorden. Dus Gamba.... komt u maar )
Op dit moment werkt het geheel wel, en heb ik een mooi PWM signaal op alle kanalen ( op 2 na.,. soldering die niet helemaal lekker zit geloof ik ). Alleen ik moet de code nog wat sneller zien te maken, want deze is nogal lomp.
Op dit moment werkt het als volgt. 2 Schuifregisters hangen in serie aan elkaar, dus de data die bij schuifregister 1 naar binnen gaat komt 9 klokpulsen later bij de 2e naar binnen. Hiervan heb ik 2 sets parrallel staan. Die 2 strengen worden tegelijk van data voorzien. En de data wordt ook tegelijk naar binnen geklokt. Hierdoor worden de registers sneller vol gestopt.
Aan de uitgang van de 74hc595 hangt een uln2803, welke puur en alleen als buffer dient. Voordeel van de uln2803 is dat deze mooi te combineren is met de RGB-ledbars van LEDSEE omdat hij zijn uitgangen sinkt, en dat is precies hoe je die RGB-ledbars aanstuurt.
In princiepe heb ik dus 10 RGB kanalen en nog 2 andere kanalen tot mijn beschikking.
Over die printjes, deze heb ik tegelijk met de vorige SK besteld bij LEDSEE. En ik had er idd een aantal opgespaart, en er kwamen nog 2 printjes bij van 2 andere deelnemers.
@Gamba: Ik heb er nu een tijdje over na zitten denken maar ik snap nog steeds niet hoe je het bedoeld. Als ik ga rekenen kom ik ook nog eens aan een andere optelsom. Kun je er een tekeningetje van maken? Of misschien een afbeelding van het schema?
Hier heb ik een tekening van hoe ik het zelf wil gaan doen:
Schematische weergave
Ik schuif de data serieel de schuifregisters in en die data gaat vervolgens parallel naar de 8 LED's toe. Ik kan natuurlijk pas sturen als ik de data aan elke uitgang heb staan. De 3 verschillende kleuren LED's stuur ik natuurlijk tegelijk aan.
Is het op deze manier te doen of zit ik dan met timingsproblemen? Of is er een betere/makkelijkere manier?
Ik heb het zo gedaan :
Dan heb ik 32 uitgangen op een rij. Die kan ik opdelen in blokken van 3 of 4 of 5 of wat je maar wil
Voordeel is dat alle schuifregisters op hetzelfde moment de data op de uitgangen gooien, hierdoor lopen alle PWM kanalen synchroon. Niet dat dit heel veel uitmaakt voor verlichting. Maar het kan wel eens van pas komen.
Nope,.. je kan ook 3 naast elkaar liggende uitgangen van het schuifregister gebruiken
Jochem
If you want to succeed, double your failure rate.
Ik snap je PWM niet, zo kun je toch niet per led PWM'en?
Jawel, alleen het vullen van het schuifregister moet dus 256*50 keer per seconde gebeuren voor een refresh rate van 50Hz.
Juist ja, dan kan mijn methode ook. Het ging mij inderdaad om de timing en als ik snel genoeg de registers kan vullen kan ik het PWM er doorheen sturen.
@Gamba: als je groen er niet bij doet kun je dus 10 RGB led's aansturen en dan hou je nog 2 lijnen over.
Ik neem aan dat je pin 9, Q7' (serial data out) gebruikt om data door te sturen naar het 2de register? Want anders zou je 7+8=15 uitgangen hebben per 2 registers.
Op 17 september 2007 17:05:51 schreef Mr GAmba:
Jawel, alleen het vullen van het schuifregister moet dus 256*50 keer per seconde gebeuren voor een refresh rate van 50Hz.
Even een vraag, hoe snel vul je momenteel de schuifregister vol met zo een pic. Normaal zou je 256*50*16bit = 204800 bit/sec moeten realiseren. Haal je deze snelheid nu?
Voor gewone 20 mA leds zou je die ULN's kunnen weglaten omdat die juist wat duurder zijn. Voor higbright leds met hogere stroom zijn ze dan wel nodig.
Op 17 september 2007 21:40:16 schreef fotoopa:
[...]Voor gewone 20 mA leds zou je die ULN's kunnen weglaten omdat die juist wat duurder zijn. Voor higbright leds met hogere stroom zijn ze dan wel nodig.
Hmm ik zit nu ook even aan het stroomverbruik te denken. Totaal zou het max 32x20mA = 640mA zijn. Dit wordt verdeeld over alle schuifregisters dus per schuifregister: 8x20mA = 160 mA. Gezien ik geen max rating kan vinden voor de totale uitgangsstroom die het register kan leveren weet ik niet of het kan. Ik zie wel dat de max dissipatie 500 mW is. Maar hoeveel hij dissipeert weet ik niet. Ik neem aan dat ik niet 5V x 160mA mag doen (wat teveel zou zijn).
Ik zie wel het volgende in de datasheet staan: Icc, Ignd (Vcc or GND current) -> max 70mA!!! Dus als er max maar 70mA in mag hoe kan het dan 160mA leveren? Ik vraag me dus af of de ULN's wel weggelaten kunnen worden.
De PIC levert op PORTA en PORTB tesamen max 200mA maar die is het probleem niet omdat de schuifregisters er tussen staan.
Even een vraag, hoe snel vul je momenteel de schuifregister vol met zo een pic. Normaal zou je 256*50*16bit = 204800 bit/sec moeten realiseren. Haal je deze snelheid nu?
Vanuit gaande dat je de PIC op 20MHz laat draaien en voor het gemakt nemen we daar 1/4 van dan heb je nog steeds 5 MIPS ter beschikking. Dan zou je 200kbps toch wel kunnen halen lijkt mij? Zelfs met een refrashrate van 100Hz -> 409600 bps zou toch nog wel lukken?
[Bericht gewijzigd door Eagle666 op (12%)]
Op 17 september 2007 21:40:16 schreef fotoopa:
[...]Even een vraag, hoe snel vul je momenteel de schuifregister vol met zo een pic. Normaal zou je 256*50*16bit = 204800 bit/sec moeten realiseren. Haal je deze snelheid nu?
Voor gewone 20 mA leds zou je die ULN's kunnen weglaten omdat die juist wat duurder zijn. Voor higbright leds met hogere stroom zijn ze dan wel nodig.
De pic draait op 20Mhz en is op dit moment met niet veel anders bezig dan data naar buiten toe pompen. Dit is statische data... Ik ben nog bezig met uitzoeken hoe ik data naar het printje kan sturen ( snel genoeg ) Ik ben al wel tevreden als ik gewoon de dataarray kan vullen, maar mooiste zou zijn als dit ook op 50Hz kan. De interne UART van de pic kan tot 115200 bps. Dit zou dus genoeg moeten zijn aangezien ik dan maar 32*8*50 = 12800 bit/s moet doorsturen. Kheb de UART alleen nog nooit zelf geimplementeerd. Moet wel lukken alleen ik heb ook nog een studie erbij
De refresh rate ga ik morgen avond wel halen. Ik kwam namelijk toennet iets tegen dat RLF heet als instructie. Komt erop neer dat als je de PWM waarde die de led moet hebben optelt bij de waarde van een counter die tot 256 telt. Je aan de carry zien of de PWM waarde is bereikt. Als ik dus die carry afvang en daarop laat kiezen of de led aan of uit moet, heb ik ongeveer 10-12 instructies per 2 leds nodig. Ik zal die code morgen wel posten als die klaar is en werkt.
Over de ULN2803's ik heb deze om meerdere redenen gekozen. 1 daarvan is dat deze makkelijk te gebruiken zijn met de RGB ledbars van LEDSEE. Aangezien deze common-anode zijn, en de uln2803 sinkt . En omdat 1 ledje per kanaal een beetje weinig is ( vind ik zelf dan ). De precieze spec's van de hc595's weet ik niet. Maar het kan zijn dat die idd gelimiteerd zijn tot iets van 100mA per chip oid. Maar aangezien ik zowiezo die RGB strips wil kunnen aansturen, heb ik de ULN's er gewoon tussen gezet.
Op 17 september 2007 11:20:13 schreef Mr GAmba:
Ik heb het zo gedaan: Schema
Ik zie nu pas dat ik dus maar 1 uitgang nodig heb voor de enable. De klok had ik voor het gemak weggelaten maar die hoort dus er ook nog bij. Ik heb er dus 1 uitgang minder voor nodig (1xR, 1xG, 1xB, 1xEN, 1xCLK).
Dus mijn design wordt nu:
Schematische weergave
In jouw geval is het 10 RGB LED's aansturen + 2 uitgangen over. In mijn geval is het puur voor RGB LED's aansturing bedoeld en ik stuur er 8 aan.
Bij mijn opzet heb ik maar de helft van jouw snelheid nodig of dezelfde snelheid met een 100Hz refreshrate:
8x256x50 = 100kbps of
8x256x100 = 200kbps
Nu maar hopen dat ik snel tijd kan vinden om er mee aan de slag te gaan. De ULN's heb ik ook nog rondslingeren dus dat zit wel goed.
Jochem
If you want to succeed, double your failure rate.
Op 17 september 2007 17:05:51 schreef Mr GAmba:
Jawel, alleen het vullen van het schuifregister moet dus 256*50 keer per seconde gebeuren voor een refresh rate van 50Hz.
Ok, ik had niet gedacht dat je dat fatsoenlijk zou kunnen halen, ligt natuurlijk ook aan de rest van de taken die je met de PIC uitvoert.
Op 18 september 2007 08:10:39 schreef Jochem_S:
[...]Ok, ik had niet gedacht dat je dat fatsoenlijk zou kunnen halen, ligt natuurlijk ook aan de rest van de taken die je met de PIC uitvoert.
Dat is vrij weinig verder . Waarschijnlijk ga ik een controller print maken met wat drukknopjes enzo. Die zal dan data naar de PWM print sturen.
Ik was ook bezig met een voorbereidend project met RGB leds. Zie deze link Maar 8 leds zijn een beetje weinig, hoewel het afhangt wat je doelstelling is. Ik had meer een animatie voor doel met een 10x10 RGB leds array type: OSRAM SYLVANIA LRTBG6TG-TU7-1+W7-36+ST7-68
Deze leds had ik geselecteerd uit een groter duits project waar ze een 2.4m wand wilden maken maar met 256 RGB leds.
Maar probleem is dat die leds vrij duur zijn, ongeveer 2 euro per stuk inclusief BTW maar ze zijn dan wel prima geschikt om per led een behoorlijk vlak uit te lichten en hebben een heel goed kleurspectrum. Die gasten deden zelfs gamma correctie voor het aansturen van de leds en iedere kleur/led was pwm gestuurd.
Er zijn natuurlijk goedkopere RGB leds maar als je dan eens de specs vergelijkt is het precies dag en nacht verschil.
Blijf ik bij een matrix van 10x10 RGB leds dan zijn dat nog steeds 300 pwm's. Vandaar dat ik dit enkel kon sturen met mijn DE1 FPGA board. Maar die kon ook wel zorgen voor voor de nieuwe data en zelfs realtime berekeningen maken voor een globale dimmer functie binnen de aangestuurde data helderheid.
Ik weet niet welke leds jullie hiervoor gaan gebruiken en welke functie je juist gaat sturen naar die 8 RGB leds.
Met een 10x10 matrix kun je natuurlijk heel veel fantasie bedenken omdat je zowel character sturing als design, artiestiek of dynamische figuren kunt maken.
Maar ik ben een beetje terughoudend omdat die leds alleen reeds 200 euro zouden kosten.
Maar het idee iets hierrond te maken laat mij niet los.
Die 300 pwm's waren al opgelost in mijn FPGA, dat lukt aardig goed. Ik had zelfs een versie met 700 pwm's en dan was mijn FPGA 57% bezet (10700 LE's van de 18752)
Gamma correctie ( de rode kleur is wat minder aanwezig in de LED-bars ) wilde ik gewoon doen in de software, die de data naar het picje toe stuurt. Aangezien daar echt geen tijd meer voor is... 
Ik heb je 10x10 array idd al gezien. Het idee is super alleen de uitvoering gaat wat voeten in de aarde hebben. Laat staan de kosten idd. Wat wel een voordeel is, dat je met de FPGA makkelijker een SD kaart ofzo kan uitlezen, en daar al je data opzetten zodat je een stand-alone systeem krijgt.
Op 18 september 2007 13:19:31 schreef Mr GAmba:
Gamma correctie ( de rode kleur is wat minder aanwezig in de LED-bars ) wilde ik gewoon doen in de software, die de data naar het picje toe stuurt. Aangezien daar echt geen tijd meer voor is...Wat wel een voordeel is, dat je met de FPGA makkelijker een SD kaart ofzo kan uitlezen, en daar al je data opzetten zodat je een stand-alone systeem krijgt.
Die gamma correctie wordt voor de 3 RGB waarden berekend. Ikzelf heb daar nu nog geen ervaring mee maar kan me best wel indenken dat voor een tegelmuur dit vrij belangrijk is. Realtime berekeningen zelfs voor een FPGA vormen al een mooie taak of uitdaging.
Of een SD kaart uitlezen gemakkelijker is op een FPGA betwijfel ik sterk. Voor software kun je veel sneller terugvallen op bestaande routines die door andere al geschreven zijn.
Wel heeft die DE1 board dan weer het voordeel van enorm veel extra geheugen onboard zowel RAM, DRAM als Flash en van die SD kaart. Maar de audio chip onboard laat ook heel veel experimenten toe, immers muziek uit je SD kaart, via de audio chip naar buiten en je RGB leds aansturen met de FPGA.
Ik ga die dure leds toch moeten bestellen, liefst 100 ineens voor een goede prijs. Slechts dan kan ik starten voor de bouw.
mijn origineel idee om daarin nog eens witte leds te plaatsen zal niet doorgaan. Ik heb de mechanische bouw uitgetekend maar zie geen goede oplossing om de licht projectie binnen een vlak inorde te brengen. Ik zou blijven op 300 pwm's in dit geval.
Oh ja voor die ULN's, ze zijn idd best aanwezig dan ben je minder beperkt door de stromen en zelfs de spanningen als je er meer in serie plaatst. Ik ging echter kleine fets gebruiken omdat die direct kunnen gestuurd worden en een heel kleine RSDon hebben. Maar ik ga ook eens een type moeten zoeken die klein is maar vooral goedkoop want ik heb er ook veel nodig en ze moeten aanstuurbaar zijn van de 3V3 levels, direct op hun gate.
Mijn projectje met 'maar' 8 RGB LED's is maar een introductie voor mij. Gewoon iets om mee te beginnen. Ik heb vroeger wel geprogrammeerd maar dat is eeuwen geleden. PIC moet ik zelfs nog leren. Dus ik begin met iets eenvoudigs maar toch met een uitdaging door een array van LED's te nemen. Ik wilde mijn PIC wel de PWM laten doen en dat ik de PIC kan aansturen met iets van LED nummer en gewilde kleur. Misschien een geheugen element erbij met een lookup table voor de kleuren... Ik ben er nog niet helemaal uit. Ik kijk eerst naar de beginselen en daarna bouw ik verder.
@fotoopa: Leuk project, inderdaad duur, maar dan heb je ook wat. Ik zal daar niet aan beginnen omdat ik andere ideen heb maar ik heb mijn FPGA dev. board van Xantus nog niet eens binnen (en FPGA moet ik zeker nog helemaal leren). Dus voor mij is het nog te hoog gegrepen .
Dat ik met ULN's werk is gewoon gemakzucht gezien ik simpelweg geen zin heb om 3x8 aan transistoren of FET's te solderen. En ik heb 'gewone' RGB LED's, dus geen Flux dingen of andere gewilde zaken. Het is puur een simpel schakelingetje om mee te beginnen. Verder zijn de ULN's voor mij dus voldoende dus waarom moeilijk gaan doen met transistoren als alles al lekker geintegreerd is .
[Bericht gewijzigd door Eagle666 op (19%)]
Ik wilde binnenkort ook iets gaan proberen met rgb-leds en heb daarvoor een ic van texas instruments gesampled : TLC5945. Moet je maar eens op zoeken. 16 pwm kanalen, schakelbaar. zet een paar van die chipjes achter elkaar en dan kan je al heel wat rgb ledjes aansturen.
Binnenkort maar eens even wat mee proberen. :d
Op 18 september 2007 19:02:48 schreef Eagle666:
@fotoopa: Leuk project, inderdaad duur, maar dan heb je ook wat. Ik zal daar niet aan beginnen omdat ik andere ideen heb maar ik heb mijn FPGA dev. board van Xantus nog niet eens binnen (en FPGA moet ik zeker nog helemaal leren). Dus voor mij is het nog te hoog gegrepen
Nog een beetje geduld, de printjes van xantus zijn net binnen. Met die FPGA kun je heel wat, ik vermoed zelfs een 8x8 RGB volledig pwm dus 8x8x3= 192 pwm's. Er zijn LE's genoeg, hij heeft een externe flash voor data opslag en met een beetje multiplexen moet het gaan. Ik kijk nog wel voor die details want ik heb 3 boardjes intotaal besteld ( 2 bestukte, 1 als reserve print)
Dat ik met ULN's werk is gewoon gemakzucht gezien ik simpelweg geen zin heb om 3x8 aan transistoren of FET's te solderen. En ik heb 'gewone' RGB LED's, dus geen Flux dingen of andere gewilde zaken. Het is puur een simpel schakelingetje om mee te beginnen. Verder zijn de ULN's voor mij dus voldoende dus waarom moeilijk gaan doen met transistoren als alles al lekker geintegreerd is
Als je die RGB channels multiplexd moet je maar 8 fets solderen..... Maar die ULN's gaan ook, dat is geen probleem. Maar de huidige fets zijn heel klein (smd versie's) en die soldeer je heel dicht bij de leds, je ziet ze nauwelijks en ze moeten zelfs geen weerstandje hebben in de gate.
@Arroz,
Ja die TLC5945 is een mooie chip, goed bestuurbaar. Die Duitsers gebruiken hem ook, ik weet de prijs nog niet maar als je erveel nodig hebt wordt het waarschijndelijk ook duur, terwijl dat eigenlijk gewoon indezelfde FPGA kan. Hoe groter je project hoe relatief goedkoper het wordt om hem in de FPGA te steken.