PIC18F4320 clock frequency and code delays?

(instructions, reset, WDT, specifications...) PIC17Cxx, PIC18Fxxx

PIC18F4320 clock frequency and code delays?

Postby BobAGI » Thu May 29, 2014 10:30 am

I am trying out the new forum for a change with a real query....

I am debugging a modified PIC18F design where the CPU was changed from a 28 pin device to PIC18F4320, which is a 44 pin device.
The new board works seemingly OK, but I have found a problem in time delays between activation and deactivation of the relay drive pins, which cause switch-off transients to be generated. So now I am hunting for these delays (72 us to be exact) and for this I need to know the clock frequency of the PIC...
I have not worked with a PIC18 design before, just used PIC24 devices, so I am not up to speed in this regard.
The MPLAB C18 compiler is being used.
In this case there is no crystal so it uses the built-in PIC oscillator.
What I have found is the following settings which use the Internal Oscillator Block:
Code: Select all
#pragma config OSC = INTIO2     //Internal RC oscillator, port function on RA6 and RA7

//In the inithw() function:
OSCCON = 0x4C; // Internal Oscillator Block @ 1Mhz. & set PRI_IDLE

It seems like this implies a 1 MHz oscillator is in use, but does this give 1 us or 2 us instruction cycle time?
I am seeing a delay of 72 us between the tristating of one end of the relay coil and the tristating of the other end.
But the code sequence is pretty simple and should execute faster, I believe:
Code: Select all
void ControlRelay_PortC(unsigned char bitmask, unsigned char drive_dir)
/*Arguments:  bitmask:   relay bits in port
              drive_dir: drive direction SET or CLEAR
*/
{
    LATC = 0;
    if (drive_dir == HIGH) LATC = bitmask;
    TRISC = ~bitmask;                       // activate relay drive output
    PulseRelayCommon(drive_dir);            // pulse relay drive common output
    TRISC = 0xFF;                           // de-activate relay drive output
    LATC = 0;
}

void PulseRelayCommon(unsigned char relay_dir)
{
    ActivateRelayCommon(relay_dir, TRUE);   // activate relay common drive
    Delay_ms(RELAY_HOLD_TIME);              // delay for roughly 5ms
    ActivateRelayCommon(relay_dir, FALSE);  // de-activate relay common drive
}

void ActivateRelayCommon(unsigned char level, unsigned char state)
{
    TRISE = 0xFF;   //Make sure the port is in the OFF state
    if (state == FALSE) return;
    if (level == HIGH)
        LATE = RECMN_SET;
    else
        LATE = RECMN_CLR;

    TRISE = RECMN_IO_DIR;
}

The function ControlRelay_PortC() is called from main() to pulse a relay coil in one or the other direction.
It just sets the level for the relay drive pins, then calls the PulseRelayCommon() function to generate the drive pulse on the common line.
When this exits back the drive pins are tri-stated immediately (in the code) and still I see a 72 us delay between the two tri-state operations.

Why is this so?
Is the PIC18 so slow that it explains the delays or is the C18 compiler inserting wait states where there should be just a simple sequence of operations??
--
Bo B
Sweden & Texas
User avatar
BobAGI
Verified identity
 
Posts: 49
Joined: Sun May 25, 2014 2:28 pm
Location: Sweden and Texas
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F4320 clock frequency and code delays?

Postby Tom Maier » Thu May 29, 2014 12:53 pm

Hi Bob,

The pic18 instruction cycle is osc/4, so 72 usec is 18 instruction cycles at 1 MHz. The pic24 is osc/2, except I think they also make some that are osc/1? Like the "EP" series"? What were you using before?

Can you just crank up the osc to shorten up the time?
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F4320 clock frequency and code delays?

Postby ric » Thu May 29, 2014 1:40 pm

Have you looked at the assembly instructions output by the compiler for that function?
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 659
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F4320 clock frequency and code delays?

Postby BobAGI » Thu May 29, 2014 2:00 pm

Hi,
well, I added a block of Nop(); commands right after switching off (tri-stating) the common drive and then I measured the delay before and after and found that the instruction cycle seems to be 4 us. Then I understand some of the delays because even a for(j=0;j<4;j++) evaluation will consume a significant amount of time.

The PIC is driving miniature bidirectional relay coils and it uses two pins in parallel for each coil drive.
All 11 coils are connected in one end to a single drive output (actually 3 pins in parallel) and the other end is each connected to two parallel pins.
Previous code activated the relay specific pins in the proper direction for setting/clearing the relay and then the common drive was pulsed ON for 3 ms (actually 3.4 ms).
When this was done the common drive was tri-stated in a subroutine and then the function call returned (taking some instruction cycles more) and then the main function tri-stated the relay drive output.
What happens is that as soon as the common drive is tri-stated there is a kick-back from the coil, which makes the PIC pin voltage go to -0.75V (outside of specs).
Then a bit later when the relay individual drive is also tri-stated and now the coil energy sends the voltage to Vdd+0.75 V, again outside specs.
It seems not damage the PIC but is not good so I want to remove it.

What I have done is that directly after the 3 ms delay I have added code to invert the common drive signal so it becomes the same as the individual drive on the other side of the coil. Then I have an inline delay loop running for about 300 us which allows time for the coil to discharge into the effective short circuit before I tri-state the common drive.
It completely removed the big kick-back pulses, now I only see voltages within the PIC specs.
--
Bo B
Sweden & Texas
User avatar
BobAGI
Verified identity
 
Posts: 49
Joined: Sun May 25, 2014 2:28 pm
Location: Sweden and Texas
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F4320 clock frequency and code delays?

Postby Tom Maier » Thu May 29, 2014 2:13 pm

considerations for mass production...

If this design is going to see temperature extremes then make sure your timing windows can tolerate a +/-5% or more variation in oscillator speed.

Also, what about timing variations caused by the possible +/-20% variation in the coil inductance?

And does this rely on caps? they have a large variation, too.

Look for ways that the timing could get shoved back into the destructive mode.

I've never heard of such a relay. Push-pull. Strange.
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F4320 clock frequency and code delays?

Postby ric » Thu May 29, 2014 3:00 pm

Tom Maier wrote:...
I've never heard of such a relay. Push-pull. Strange.

Very common in latching relays.
They come in two configurations
[1] Wired like one side of a centre tapped transformer, so you pull the common pin high, and drive one side or the other low to latch it one way or the other, or
[2] Like Bob's, where there is a single coil, and you energise one way to latch it into the first state, and the opposite way to latch it into the second state. That means you can't use standard diodes across the coil to catch the spike.
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 659
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F4320 clock frequency and code delays?

Postby Tom Maier » Thu May 29, 2014 3:39 pm

It sounds like if the software ran amuck, it could vioate the activation timing window and blow a pin. Is that true?

In situation like that I like to have pure hardware create the windows. It's always a hazardous situation when software has the ability to destroy something. It also makes it harder to develop the code because you keep blowing parts until the code is right.

Some common techniques for dealing with that:
- RC delays can be used for activation delay windows.
- Some logic gates can be used to decode an illegal i/o operation and generate a reset, or just block the illegal output condition.
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F4320 clock frequency and code delays?

Postby Ian.M » Thu May 29, 2014 3:56 pm

Bob inherited this design and it is *EXTREMELY* space constrained, to the point that there was no possibility to add the external coil drivers and clamps that it should have had. There was barely enough room to swap in a 44 pin PIC to allow pin paralleling to get enough coil drive.

For development, I'd patch in Schottky clamps + current monitoring on the clamping rails so you can see if you are hitting the clamps. If you disconnect the clamp rails from the supply rails it effectively disconnects the clamps (apart from their junction capacitance) so you can confirm working code will keep the pin voltages in spec on the final hardware.
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: PIC18F4320 clock frequency and code delays?

Postby Tom Maier » Thu May 29, 2014 4:29 pm

I've been in many situations where the mechanical engineer makes the box, and then says "make it fit in there...".

Usually the box is a bit too small, but I remember one occassion the guy hung a 18x18'' box on the machine. When he came back he found I was only using about 4 square inches of it. That was back in the days when discrete digital logic used to fill large cabinets, and I put an 8051 in it. He was very puzzled. :D
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F4320 clock frequency and code delays?

Postby Ian.M » Thu May 29, 2014 4:47 pm

I should note that I pointed out the need to drive both ends of the coil to the same level and let the current decay in Bob's original topic (@MCHP) over two months ago! http://www.microchip.com/forums/FindPost/788836
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Next

Return to 16-Bit Core

Who is online

Users browsing this forum: No registered users and 8 guests

cron