Foutzoeken op experimenteerprintje

Beste CO,

Ik ben bezig met een lamp met 10 los bestuurbare RGB ledstripjes.
Dit doe ik met een PIc18F25K22 en 2 TLC5940 (pwm led driver, schuifregister).

Ik had het schema opgebouwd op een breadboard, daar werkte alles prima.

Nu heb ik dit op een experimenteer printje na gebouwd, maar je raad het al, die doet het niet. Als ik het printje aan zet dan gaat de ledjes in beetje in een random kleur branden (met bijna geen flikkeringen). Als ik met mijn hand in de buurt kom, dan gaat de boel flikkeren en als ik mijn hand dan weer weg haal dan blijft hij weer stabiel in een random kleur branden. Af en toe is het het geval dat alle leds ineens uit staan. PS er worden alleen 1 nen naar toe gestuurd, dus de leds zouden altijd wit moeten branden.

Ik heb al geprobeerd om met een functie generator een bepaalde pin vol te spammen, maar ook dit gaf geen resultaat.

Heeft iemand enig idee wat hier aan de hand kan zijn?

FOTO's
http://i47.tinypic.com/2qmj6ns.jpg
Schema
http://i47.tinypic.com/2q88t5g.png

PS: er zitten nu wel condensatoren over de 7805 (1&10uf)

C1 en C2 hebben alvast een te hoge waarde (deze moet iets van 20..27pf zijn).

Plaatst ontkoppel Condensators (100nf) dicht bij de PIC en de 7805 (in de voedings lijnen).

Ik zou het kristal ook dichter bij de PIC plaatsen als dat (nog) kan.

C1 en C2 zijn al de juiste waarde, deze staan alleen niet correct in de schema.

Dat word even zoeken naar een 100nf

[update]

Nog steeds het zelfde effect!

[Bericht gewijzigd door flamingo op (16%)]

Gebruik is om te testen de 16MHZ interne oscillator.

Suc6.

Weet je zeker dat alle sporen goed zijn doorgekrast?
Ik gebruik altijd een 4 mm boortje, welke op de hand ronddraai op een gaatje en zo het spoortje onderbreek.

Of het programma vervangen door een test programma welke een led op een vrije poort laat knipperen.

[Bericht gewijzigd door marcob op (24%)]

@Marcob
Ik heb elk verbroken spoortje doorgemeten en ik ben geen fouten tegen gekomen.

@stan1
Weet jij misschien hoe dat moet in Picbasic? De reden dat er een kristal op is, is dat ik er maar niet achter kon komen hoe je de interne oscillator aanzet.

Ja hoor,

Voor het gemak gebruik ik de fuseconfig plugin van JGB tools


CONFIG_START
   FOSC = INTIO67 ; Internal oscillator block, port function on RA6 and RA7
CONFIG_END

Zet dus: FOSC = INTIO67 in het config blok!

Verweider wel het kristal en de Ctjes voor de zekerheid.

Suc6.

AHA! Ik moet dan dus de "xtal = .." weghalen.
Ik dacht dat dat verplicht was voor de compiler zodat die bijv. delayms kan berekenen.
Ik had dit al meerdere malen geprobeerd zonder dat weg te halen.
weet ik dat voor de volgende keer!

even testen...

xtal kun je het beste gewoon laten staan, hiermee bepaal je de frequentie waarmee de compiler rekening houd. Hier bepaal je dus niet het oscillator type en snelheid mee. Dit configureer je in het config blok en de snelheid stel je in met de osccon instructie. Voor de gebruikte pic kun je de OSCCON configuratie vinden in de datasheet, bladzijde 32.

http://download.collem.nl/18F25k22_osccon.png

Lees dit eens rustig door.

Suc6.

hee, ik ken dit.

had ik laatst ook met een klok. check even of je interrupts uit staan, en of je MCLR hooggehouden wordt. hij kan de hele tijd aan het resetten zijn., en dan zijn er spookverschijnselen. als mijn hand in de buurt kwam, als ik de plastic trafo aanraakte, enz.

het kan ook iets anders zijn, hoor. maar ik post de ervaring, het was behoorlijk frustrerend, zo'n ghost-in-a-chip.

@stan
Bij die 16MHZ moet daar nog PLL over heen zodat ik 64mhz overhoud, dus 16 MIPS? of is die 16MHZ dan al 16MIPS. In het geval van FOSC = INTIO67
wat dan denk ik dit is: "111 = HFINTOSC - (16MHZ)"
@techno
Dat had ik met de eerste keer dat ik een PIC aansloot, toen was ik de MCLR vergeten. Toen kreeg ik vergelijkbare resultaten.

-

Nu moet mijn programmer wel even meewerken, die heeft er vandaag niet zoveel zin in volgens mij

Je kunt ook andere optie 's zoals MCLR, BOREN, Watchdog via het config blok in/uit schakelen.

Probeer het eens met onderstaand confog blok.


CONFIG_START
   FOSC = INTIO67 ; Internal oscillator block, port function on RA6 and RA7
   FCMEN = OFF ; Fail-Safe Clock Monitor disabled
   BOREN = OFF ; Brown-out Reset disabled in hardware and software
   WDTEN = OFF ; Watch dog timer is always disabled. SWDTEN has no effect.
   PBADEN = OFF ; PORTB<5:0> pins are configured as digital I/O on Reset
   MCLRE = INTMCLR ; RE3 input pin enabled; MCLR disabled
CONFIG_END

Suc6.

Op 24 juni 2012 15:56:16 schreef flamingo:
Dat word even zoeken naar een 100nf

Foei, toch! Als je met microcontrollers en/of andere digitale bouwstenen aan de slag gaat, zijn keramische C's van 100nF onmisbaar. Ik heb er doorgaans meer dan 100 in voorraad, in verschillende uitvoeringen.
Nou ja, 82nF en 120nF zijn net zo goed, en twee stuks 47nF parallel doen het waarschijnlijk beter dan één exemplaar van 100nF.

Kortom: als je er naar moet zoeken, ben je fout bezig. Ze moeten voor het grijpen liggen...

@stan
Ik zal het proberen!

@pros
Ik heb een bakje vol van 4x5x4 met de kleine ceramische condensatoren, alleen zitten we wel allemaal door eklaar!

Programmer heb ik nog steeds niet aan de praat, daar ga ik morgen even rustig naar kijken

[Bericht gewijzigd door flamingo op (24%)]

Als je weet dat zeg 22nF tot 1uF wel ongeveer goed is voor ontkoppeling is het VEEL sneller even in dat bakje te graaien dan te wachten totdat de bestelling van minstens 100 stuks binnen is....

Mijn pickit clone wil nog steeds niet programmeren, maar gelukkig kon ik met mijn easypic5 een beetje vals spelen en em toch programmeren.

We zijn een stap verder!
Als ik de lamp aan zet dan gaan alle ledjes tegelijkertijd tijd uit en aan. Maar ze knipperen wel in een stabiel ritme, dus zat er inderdaad een probleem bij het kristal.

Ik ga nu even met mijn scope en functiegen. even spelen, kijken of hij dan wil praten!

[update]

Ik heb mijn Programmer aan de praat gekregen, en nu doet de lamp het!
Zit alleen nog een probleempje bij de helderheid, het ene stripje is feller dan de andere. Dat licht denk ik aan de bekabeling. TLC

@ http://www.circuitsonline.net/forum/view/105926

Toch hier dus maar verder gaan:

@diy

Er zit inderdaad een PWM op het kanaal, van ongeveer 1/3. Dat licht waarschijnlijk dus aan mijn programmeer kunsten.

Dat is mij dus al gelukt.

Ja ik heb de datasheet gelezen en begrepen.

Op het crystal zitten 22pf en een 27pf, dat was een foutje in mijn schema. Verder maak ik nu gebruik van de interne oscillator, omdat het crystal te ver weg stond, en dus storing gaf.

Om het PWM probleem op te lossen, moet ik een wat meer constante puls geven. want wat ik nu geef is 4096 pulsen, daarna ga de 'volgende' data er in klokken.
Wat ik eigenlijk zou moeten doen is: de data er in klokken, en ondertussen met een timer interrupt er voor zorgen dat er in die tussen tijd 4096 pulsen door heen zijn geklokt.

Heb je enig idee hoe 'snel' die pulsen zijn? Met andere woorden, wat voor frequentie heeft de GSCLK lijn?

Dat is nu:
2x 1 clockcycle, met een klok van 16MHZ(PLL x4 = 16MIPS) zou dat dus 8MHZ moeten zijn.

Met de Interupt timer zal dit iets lager liggen omdat de pulsen dan wat meer verdeelt worden.

[Bericht gewijzigd door flamingo op (33%)]

Je hebt IREF van de TLC5940 op de 5V aangesloten. Is dat wel goed? Normaal is: vanaf IREF een weerstand naar massa.

The maximum output current per channel is programmed by a single resistor, R(IREF), which is placed between
IREF pin and GND pin.

Klopt, de Iref zit ondertussen al met een weerstand aan de massa. Ik zal om verwarring te voorkomen, mijn schema even updaten.

http://i48.tinypic.com/20624gn.png

[Bericht gewijzigd door flamingo op (13%)]

Ok, dat is in ieder geval snel genoeg.
Alleen, hoe je het beschrijft klinkt het alsof die clock dus 'handmatig' wordt aangemaakt, in een interrupt. Je zou voor de grap toch eens moeten meten aan die GSCLK pin. Met een scoop of analyzer.
Zodra je onder de 400kHz komt, zullen je leds gaan flikkeren.

Ik raad je aan om die clock automatisch te geneneren vanuit je Fosc.
Of te wel je, gebruik de internal clock en trek deze naar buiten op RA.6 (even je fusebits nakijken hoe je dat doet). Op deze manier heb je geen omkijken meer naar GSCLK in je code.

En de BLANK pin..hoe wordt die bestuurd?

Dat was inderdaad de bedoeling, maar ik kan dat dus beter doen MBV de fosc. Ik ga even zoeken of ik nog een voorbeeld kan vinden.
Mijn config staat is als volgt ingesteld:

Config_Start
   FOSC = INTIO67 ; Internal oscillator block, port function on RA6 and RA7
   FCMEN = Off ; Fail-Safe Clock Monitor disabled
   BOREN = Off ; Brown-out Reset disabled in hardware and software
   WDTEN = Off ; Watch dog timer is always disabled. SWDTEN has no effect.
   PBADEN = Off ; PORTB<5:0> pins are configured as digital I/O on Reset
   MCLRE = INTMCLR ; RE3 input pin enabled; MCLR disabled
Config_End

Er staat hier dus een 16MHZ klok op poort RA6 en ra7

Op de blank pin word samen met de xlatch pin een eenmalige puls op gezet, nadat de GLSCK klaar is met pulsen.

Om even een beeld te geven hoe mijn programma in elkaar zit zal ik het in stappen neerzetten:

- Data voor de TLC laden en weg klokken
- GSCLK 4096x pulsen
- Puls op Xlatch en Blank

Wat het dus zou moeten worden is de GSCLK tijdens het laden van de data 4096x te pulsen.

De GSCLK moet continu doorlopen. Geen onderbreking. Dit is namelijk je PWM clock. Als je die zomaar stopt, dan doet die TLC niks meer.
Daarom het idee om je Fosc daarvoor te gebruiken.
Als je nu de capture compare functie van de PIC gebruikt, kun je op de achtergrond in interrupt de BLANK pin zetten na 4096 pulsen. Hier heb je dan verder ook geen omkijken meer naar.
In je mainloop stuur je vervolgens periodiek je SPI commando's.

Zoals je configbits nu staan, heb je GEEN clockout, dus ook geen GSCLK. Het staat zelfs expliciet in je code: "port function on RA6 en RA7". RA.6 en RA.7 zijn dus gewoon I/O poorten en losgekoppeld van je Fosc.
Je moet even opzoeken hoe je de configbits goed zet, zodat je de interne clock gebruikt, en deze ook op OSCOUT (RA.6) zet.

Als ik meer dan 4096 pulsen klok, bijv. 8192, en ik wil dat alle leds volledig branden, dan zullen ze toch maar op 50% van hun dutycycle branden, omdat de laatste 4096 pulsen de pwm uit staat.
Als ik dus halverwege een blank puls zou sturen, dan brand hij wel volledig?

Ik ontdek net mbv een klein stukje code dat de pic op 2mhz draait ipv 16, even kijken hoe ik dat recht kan zetten.