Hi everyone.

I put this topic here because I think it may contain information more than PIC.

If the code is written in this way:

switch(period)
{
case 0:
PORTBbits.RB3=1;
PORTBbits.RB4=1;
PORTBbits.RB5=1;
break;
case 4:
PORTBbits.RB3=1;
PORTBbits.RB4=1;
PORTBbits.RB5=1;
break;
..........
...........
default:break;
}

The one of the output (RB4) will show strange behavior as in figure 1.





If the codes are written in this way:
switch(period)
{
case 0:
PORTBbits.RB3=1;
break;
case 4:
PORTBbits.RB3=1;
break;
..........
...........
default:break;
}


switch(period)
{
case 0:
PORTBbits.RB4=1;
break;
case 4:
PORTBbits.RB4=1;
break;
..........
...........
default:break;
}


switch(period)
{
case 0:
PORTBbits.RB5=1;
break;
case 4:
PORTBbits.RB5=1;
break;
..........
...........
default:break;
}
The outputs are just fine, which is shown in figure 2.


It seems that the pins have to be updated separately.

It is soooo strange, why?????

Because of the power supply is not clean???????


Thank you.

BTW, why the voltage may go to -2V in figure 2????

 

After reset a PIC will have pins with analog functions. Set as analog inputs. Not digital IO. And this may cause some strange behaviour. Which PIC are you using?

 

If its a 16Fxxxx or lower, it looks like the age-old read-modify-write I/O problem. When you to a bcf/bsf to a port pin, other pins on the port may be corrupted because the PIC does not store an internal value of what has been written to the port. Instead, it reads the current value of ALL of the pins on the port, modifies one bit then writes ALL of the pins back. If RB4 has not had time to rise to a logic '1' before you write to RB5, you will see exactly what you see in your first screen shot. In your second case, you have some time between port writes so it works.

The only real solution is to keep a local copy of the port outputs and write it as a byte to the port i.e.
PORTBimage |= '\0x10';
PORTB = PORTBimage;

The 18F and bigger PICs fix this by providing LATx.

The undershoot can be lots of things including how you have your scope probe grounded, chip bypassing etc. Given what looks like oscillator noise on the port signal, I suspect its not too good.

 

If its a 16Fxxxx or lower, it looks like the age-old read-modify-write I/O problem. When you to a bcf/bsf to a port pin, other pins on the port may be corrupted because the PIC does not store an internal value of what has been written to the port.
...
The 18F and bigger PICs fix this by providing LATx.

Even if it's not a PIC16, using the PORTB register will cause this behavior on PIC18 too. You must use LATB to avoid it.

 

Even if it's not a PIC16, using the PORTB register will cause this behavior on PIC18 too. You must use LATB to avoid it.

You are, of course, correct. Writing to PORTx writes through to LATx but r-m-w of PORTx on an 18F does indeed have the same problem.

Good catch!

 

BTW, why the voltage may go to -2V in figure 2????

That's your scope! every scope bounces the other way for a short burst... I don't know the whole theory behind that... My scope does that too, and it's more apparent the higher the frequency gets (I think).

 

That's your scope! every scope bounces the other way for a short burst... I don't know the whole theory behind that... My scope does that too, and it's more apparent the higher the frequency gets (I think).

It's almost certainly not the scope itself. It could be related to inductance of the ground lead, or more likely actual inductance in the circuit under test, and these negative voltages are actually occurring on the circuit.

 

... it's more apparent the higher the frequency gets (I think).

That is a correct observation if it is indeed due to inductance in the circuit under test: there is a current passing through the circuit, and then the current is abruptly switched off. Look at this equation regarding inductance: \(v = L \frac{di}{dt}\). The higher the current, the shorter the rise/fall time of the signal, and the greater the inductance, causes a more significant induced voltage.