![]() |
![]() |
![]() |
|
|
|||||||
| Micro Controllers Discuss all aspects of micro controllers - building them, coding them, etc. All controllers are welcome - PIC, BASIC, Z8 Encore!, etc. |
|
|
Thread Tools | Display Modes |
|
|
(permalink) |
|
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 |
|
|
|
|
|
|
(permalink) |
|
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. |
|
|
|
|
|
|
(permalink) | ||
|
Quote:
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. Quote:
|
|||
|
|
|
|
|
(permalink) |
|
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: |
|
|
|
|
|
|
(permalink) | |
|
Quote:
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?? |
||
|
|
|
|
|
(permalink) |
|
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!. |
|
|
|
|
|
|
(permalink) |
|
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
__________________
"I share, thus I am" Jay.slovak Read this! ICD2 Clone Best PIC/DsPIC Bootloader Read my Inchworm ICD2 review! |
|
|
|
|
|
|
(permalink) |
|
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 |
|
|
|
|