Problem; Random pic performance

[timothyjackson]

Hello all.

Am lost. totally.

Not going to swamp you all with code, just the problem itself (and its not me )

Got code to fade leds in sequence. Using 3 pics (to fade a long line of leds, each pic fading 1 led at a time. wired up so it looks like 3 leds constantly fading down a line of 24 leds)

I burnt the "same" code on to 3 pics, so that, they all illuminate there respective led at the same time (i.e. bank of 3 leds fade on together, then off, next bank etc etc.)

problem. When opening up a new pic package, and buring the "same" code to a pic, it, fades/performs totally differently (fades at a different rate). ITs like it works on a different timing, even though the code is identical.

- using mplab ide
- using pic start plus
- pic is a 16f628

got it working with 3 pics identically, but, still, i'm foxed about this weird problem, a new burnt pic performs differently.

Do I have to prepare the pic when opening it up????

Any and any help would be so great.

Thanks. Timbo

 

[Oznog]

So it sounds like you used an array of PICs to drive an LED array because you needed more pins? Do I understand correctly?

More commonly you'd multiplex them. Now for 24 leds, you'd just use a 40 pin PIC too.

But better solutions nonwithstanding, you might have a memory initialization problem, but unless they're all driven off the same oscillator, they will drift over time no matter what you do. You want a reserve a logic pin to synchronize the operation, one PIC will source the signal and the others follow it.

 

[timothyjackson]

So it sounds like you used an array of PICs to drive an LED array because you needed more pins? Do I understand correctly?

Kinda. I didn't know how to fade to leds at the same time on one pic. Too complicated for me. i wanted a long line, so, problem was solved by alternating the led fade to three pics.

I spoke to an american chap just now. He said that the internal oscillator (which i'm using) has a poor tolerance, say 20%, which could be a big cause for the irregularity.

I don't know if the osccal function is built into the 16f628?

I love your idea.

You want a reserve a logic pin to synchronize the operation, one PIC will source the signal and the others follow it.

Its great. i'm hoping the 25ma source/sink is per pin, not per chip?

 

[csaba911]

Hi

Are you using the internal RC "@4MHZ" ?
If yes did you save the osc calibration value ?
The value in the OSCCAL register is used to tune the frequency of the internal RC oscillator.
+- 1.5 %
For the 4000000 expected clock it may be 4060000 or 3940000 !

Let say your first pic had ocall trim to max and the second pic had on min.
120000 / 4 =30000 instruction different !!!!!!!

than may be I'm wrong :arrow:

 

[timothyjackson]

Are you using the internal RC "@4MHZ" ?
If yes did you save the osc calibration value ?

yes am using the internal RC "@4MHZ

you've lost me with saving the osc calibration value..../


movfw 07FFh
bsf STATUS, RP0
movwf OSCCAL
bcf STATUS, RP0
retlw 0x00

just after the org 0x00 the program calls the subroutne above.

? does the osccal worK with the 16f628 ?????? cant see osccal on the datasheet??????

?? MPLAb doesn't recognise OSCCAL?????

? the code above; will that do the job??

 

[Nigel Goodwin]

There is no OSCCAL register in the 16F628, the internal 4MHz oscillator can't be trimmed. unlike some of the other PIC's with internal oscillators.

However, they should be within fairly close tolerances of each other, certainly not far enough apart to be able to see the difference!.

 

[Jay.slovak]

There are two solutions for your problem:
1. Use a syn signal from first PIC to another two
2. Make an external oscilator and feed all PIC from it

And yes, you can't trim 628's internal oscilator

 

[timothyjackson]

hmm mmm

indeedy. Thank you for the fantastic suggestions.

PIC 1 is now driving the other two pics. works a treat.

i'm finding this pic m'larky quite entertaining, just need to find somewhere which does hair implants.

best of luck to you all

timbob