CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

madness setting in!

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
davt



Joined: 07 Oct 2003
Posts: 66
Location: England

View user's profile Send private message

madness setting in!
PostPosted: Fri Nov 05, 2004 8:46 am     Reply with quote

Hi all

Compiler version 3.210.
Pic 16F767.
Programmer Warp-13


If I program my 16F767 with the code below which continually sets the test pins high - all pins should remain high!!

But what I am seeing are pulses 0.2us wide and 2us spacing on pins portb.1 to portb.4

void main(void)

{

trisa=0b00000111;
trisb=0b00000000;
trisc=0b10000000; // set rc7 rx as an input


test0=0; //
test1=0; // oscilloscope
test2=0; // test
test3=0; // pins
test4=0;
test5=0;
test6=0;
test7=0;

gie=0; // disable all interrupts


while(1)

{

test2=1;
test3=1;
test4=1;
test5=1;
test6=1;
test7=1;

}

}

If I alter the code to:

void main(void)

{

trisa=0b00000111;
trisb=0b00000000;
trisc=0b10000000; // set rc7 rx as an input


test0=0; //
test1=0; // oscilloscope
test2=0; // test
test3=0; // pins
test4=0;
test5=0;
test6=0;
test7=0;

gie=0; // disable all interrupts


while(1)

{

portb=0xff; // sets all pins high

}

}

All the pins remain high - as they should!

This only happens on a 16F767

Am I missing something???????

Dave
SherpaDoug



Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA

View user's profile Send private message

PostPosted: Fri Nov 05, 2004 9:22 am     Reply with quote

It sounds like a read-modify-write problem. Try adding a 1ms delay between setting each pin high:

test2=1;
delay_ms(1);
test3=1;
delay_ms(1);
test4=1;
delay_ms(1);
test5=1;
delay_ms(1);
test6=1;
delay_ms(1);
test7=1;
delay_ms(1);

and see if the problem goes away. The root of the problem is the structure of the PIC output pin and its connection to the CPU, there is nothing the compiler can do about it. If two commands to modify a port are in the instruction pipeline together, the first one may be lost. A short delay (1us is probably enough depending on your clock speed) lets the first command complete before the second starts, so everything works.
I am sure there many references to this "gotchya" on this BBS and any other PIC related source.
_________________
The search for better is endless. Instead simply find very good and get the job done.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Nov 05, 2004 10:54 am     Reply with quote

Quote:
The root of the problem is the structure of the PIC output pin and its connection to the CPU, there is nothing the compiler can do about it. If two commands to modify a port are in the instruction pipeline together, the first one may be lost. A short delay (1us is probably enough depending on your clock speed) lets the first command complete before the second starts, so everything works.
I am sure there many references to this "gotchya" on this BBS and any other PIC related source.


Note quite true. The command doesn't get lost. What happens is that the first command is executed and the pin is set to go high. Now this takes some time. The next instruction to set a bit high occurs. Now what really happens is that the port is read, bit changed, and written back out. The problem is that the read occured before the previous bit set had enough time to allow the output to reach a logic level of 1. A small delay will fix this. Some PICs (18's) have a LAT register (LATA, LATB,...). If you use this register you won't have the problem because the data is written to a latch.
asmallri



Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Fri Nov 05, 2004 11:20 am     Reply with quote

What about adding
Code:
#use fast_io(b)
[/code]
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
SherpaDoug



Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA

View user's profile Send private message

PostPosted: Fri Nov 05, 2004 11:37 am     Reply with quote

asmallri wrote:
What about adding
Code:
#use fast_io(b)
[/code]

I don't think that will help. This has nothing to do with the TRIS register. It has more to do with the capacitance on the I/O lines and the ability of the drivers to drive the line to the opposite state before the next instruction starts.
_________________
The search for better is endless. Instead simply find very good and get the job done.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Nov 05, 2004 12:38 pm     Reply with quote

It could actually make it worse. With standard IO the tris register are set/cleared with takes additional instruction cylcles with actually adds a small amount of delay.
Guest








Re: madness setting in!
PostPosted: Sat Nov 06, 2004 6:03 pm     Reply with quote

How did you declare

test0 to test7 ?
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group