Jump to content
TomF

Strange Results Writing To Portb

Recommended Posts

Hi,

 

Im using 16F1827 at 18.432MHz HS xtal. The device is setup correctly and all periferals are turned off.

 

set_bit(portb, 6);

set_bit(portb, 7);

 

clear_bit(portb, 6);

clear_bit(portb, 7);

 

If i do this, the port lines act strangely, its hard to exactly describe what happens, but RB6 appears to drive correctly until RB7 is set, then it follows RB7 for a small period of time, then returns to where it should be.

Adding a NOP instruction between the set_bit calls fixes the issue.

 

 

However, if i do the following, it works as expected. Does anyone care to explain why, i dont understand it!?

 

set_bit(latb, 6);

set_bit(latb, 7);

 

clear_bit(latb, 6);

clear_bit(latb, 7);

 

If i write this, it also works as expected:

 

portb = 0b01000000;

portb = 0b11000000;

 

portb = 0b10000000;

portb = 0b00000000;

 

 

? totally confused with this.

Share this post


Link to post
Share on other sites

Hi Tom,

 

This is the standard "Read-Before-Write" Gotcha!

 

You cannot change a single bit on an 8 bit port. What happens is, all 8 bits are read, the bit you want is altered, then all 8 bits are written back to the port. The problem is that you may read a zero from a port that has a one written to by some other means. When the port is written back, the zero you read now resets the one that was there bafore.

 

If the PIC has a latch register then use it instead of the port. When you read the latch you do not get any strange inputs as the latch is output only.

 

If the PIC does not have a latch register, you should have a port image in RAM that is modified then written to the port.

 

Cheers

 

Reynard

 

Clear as mud or what ?

Share this post


Link to post
Share on other sites

TomF

What happens is, all 8 bits are read

The logic levels present on the pins are actually read, so an excessive load on a pin can drag it down to zero even though the data last written set the output on.

 

I hope that helps make it a little clearer.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Thank you both for the answers. Im not using the port as an input, the outputs on b7 and b6 are driving a clock and data line for a SPI device, so its not a big load.

Its running at full speed, e.g. im changing the port data as fast as the pic can do it, so wondering if the next instruction is being read before the line fully changes state (low to high).

Share this post


Link to post
Share on other sites

Hi Tom,

 

There will be some propagation delay through the output driver logic. The load capacitance will also affect the rise and fall times of the output signals.

 

Even though the port bits are set to outputs, if you perform bit operations using the port, the PIC will read what it sees on the port pins and not necessarily what you think you have put there previously due the delays above.

 

If your PIC supports the reading of the LAT register then use it, as this will illiminate the reading of the acutual port pins and is unaffected by strange effects that take place beyond the chip pins.

 

The PIC pipelining may read the next instruction but won't execute it until the current instruction has completed.

 

Your PIC16F1827 supports SPI. It make life easier to use it if possible.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites
Hi Tom,

 

There will be some propagation delay through the output driver logic. The load capacitance will also affect the rise and fall times of the output signals.

 

Even though the port bits are set to outputs, if you perform bit operations using the port, the PIC will read what it sees on the port pins and not necessarily what you think you have put there previously due the delays above.

 

If your PIC supports the reading of the LAT register then use it, as this will illiminate the reading of the acutual port pins and is unaffected by strange effects that take place beyond the chip pins.

 

The PIC pipelining may read the next instruction but won't execute it until the current instruction has completed.

 

Your PIC16F1827 supports SPI. It make life easier to use it if possible.

 

Cheers

 

Reynard

 

If your data rates are high enough you may need to look at your circuit traces as transmission lines. That is, you will want to make sure that all clock and data lines are properly terminated to avoid unnecessary line reflections. This may or may not be an issue for you. Just a thought to keep in the back of your head.

Share this post


Link to post
Share on other sites

Thanks for the replys. Im clocking SPI as fast as possible with the 18MHz xtal im using; this may cause transmission line issues? not sure, the traces are as short as possible.

 

I cant use the internal SPI because i also needed a uart and a xtal, which is on the same pins :P

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...