Shouldn't this be valid in Hitec C?

Discussion in 'Programmer's Corner' started by coldpenguin, Jun 13, 2010.

  1. coldpenguin

    Thread Starter Active Member

    Apr 18, 2010
    165
    9
    Chasing more bugs in hitec c!
    Please, someone confirm whether this is 'correct' or not, it is sending me mad!

    I was hoping to use RD6, as a pin for sending an ultrasound signal down.
    However, it appears that changing RD7 is changing RD6....
    I have two chips set up with the same circuit, and the same is happening on both.
    When One_Wire_RS() is called, both RD6 and RD7 are changed. I couldn't work out going through the code why RD6 was changing, so I am changing RD5 manually, and watching RD5, RD6 and RD7,
    I am watching what is happening with a logic analyser.
    When One_Wire_RS() is called, RD6 is set low, as well as RD7 (and also RD5, I was using this to trace exactly which call it was which did it).
    (doing a find in files for D6 shows only the ultrasound calls, TRIS is set only for the whole port at the beginning of the program. The LCD routines were portD, but I have moved them for debugging purposes to the end of the while loop, and are wrapped in USTX=1)
    WHY is RD6 changing?


    Code ( (Unknown Language)):
    1.  
    2.  #define TPIN TRISD7
    3.  #define DPIN RD7
    4.  bit prescence = 0;
    5.  
    6.  void One_Wire_High(){
    7.  DPIN=1;
    8.  TPIN=1;
    9.  }
    10.  
    11.  void One_Wire_Low(){
    12.  TPIN=0;
    13.  DPIN=0;
    14.  }
    15.  bit Get_One_Wire_Bit(){
    16.  TPIN=0;
    17.  char a=DPIN;
    18.  TPIN=1;
    19.  return a;
    20.  }
    21.  
    22.  
    23.  bit One_Wire_RS(void){  
    24.  One_Wire_High();
    25.  __delay_us(TG);            
    26.    prescence = 0;                    
    27.  One_Wire_Low();
    28.    __delay_us(TH);              
    29.  One_Wire_High();
    30.  __delay_us(TI);          
    31.  if (Get_One_Wire_Bit() == 0 ){
    32.  prescence=1;
    33.  };
    34.  
    35. #define USTX RD6
    36. #define USTXTRIS TRISD6
    37.  
    38. void main(void){
    39. //initialise everything
    40. USTXTRIS=0;
    41. USTX=1;
    42. TPIN=0; //output for 1wire
    43. DPIN=1; // 1wire should be constantly high unless data is being sent
    44. while(1){
    45. sleep();  //Is woken up by SQWE output on pin RB0
    46. //other routines run, RD6 is still high
    47.  
    48. TRISD5=0;  
    49. RD5=1;  //watching LA, RD6 is still high, RD5 goes high
    50.  if(1 == One_Wire_RS()){   //I know something is there in this case anyway
    51. TOK=1;
    52. RD5=0;
    53. USTXTRIS=0;
    54. USTX=1;
    55.  
    56. }
    57. }
    58. }
    59.  
     
  2. t06afre

    AAC Fanatic!

    May 11, 2009
    5,939
    1,222
    Which PIC do you use? Is it any analog functions on port D. It sounds to me like read modify write problem
     
  3. coldpenguin

    Thread Starter Active Member

    Apr 18, 2010
    165
    9
    It is the 16f877a, portD is listed as RD<N> / PSP<N>
    Missing from the code that I posted, is that I am setting TRISE and TRISD to 0x00000000;
    TRISE<4> is specified as being the enable bit for the Parallel port on port D, this is 0 on all resets, and obviously being set to 0 with the TRISE above as well.

    All analog pins are on port A and E (and I am not implementing any at the moment, I will want to use one later)
    I am setting ADCON1 to be 0x00000000
    The only 'special' item that I am using as far as I am concerned, is INTCON
    I am setting
    INTCON = 0b00010000;
    sleep();
    INTCON = 0b00000000;

    during part of the code. This sets up RB0 to be able to wake the PIC from sleep (SQWE input from a DS1307, wakes the PIC once per second). After the wake, the PIC performs an I2C read from the DS1307, which is OK, then, it runs the code I posted, which produces the fault. (timewise I can see that the LA shows the I2C completing, then I set RD5 high as my marker, then perform the 1-wire read on RD7, which initiates the erroneous low on RD6)
     
    Last edited: Jun 15, 2010
Loading...