Help with the pic18f458 and the PORT command

Discussion in 'Embedded Systems and Microcontrollers' started by johnnyinwa, Apr 30, 2015.

  1. johnnyinwa

    Thread Starter Member

    Jun 24, 2013
    41
    1
    Heh Guys,
    I am programming in the c computer language using the xc8 c compiler (free version) and the MPLABX IDE both from Microchip. The microcontroller I am using is a pic18f458. I have completed my first coding project and have this one annoying bug in my code that won't go away. I configured bit 0 of port B with the following command (which worked fine) TRISBbits.TRISB0=1;. Here is the line of code that keeps giving an error:
    if (PORTBbits.PORTB0==0) numgen (float numb1,numb2,numb3,rannumseed);

    The error keeps showing up at "PORTB0" in the above line of code. I am trying to read a logic zero on pin 0 of port b of the pic18f458. This is my first project programming a microcontroller in c. Everything else in my code seems to work fine. Anyway any help you guys could give me on this issue would be much appreciated. By the way the program is four pages long. ;)
     
  2. JohnInTX

    Moderator

    Jun 26, 2012
    2,347
    1,029
    I use something like this to define the input:
    #define MY_INPUT_TRUE (PORTB & 0x01) // RB0 == 1 evaluates as TRUE

    Which generates:
    Code (Text):
    1.  
    2. // this..
    3.   if (MY_INPUT_TRUE) BEACONstate = 1;
    4. // ..generates this code:
    5. 94:  if (MY_INPUT_TRUE) BEACONstate = 1;
    6. 0FB8  A081  BTFSS PORTB, 0, ACCESS
    7. 0FBA  D002  BRA 0xFC0
    8. 0FBC  0E01  MOVLW 0x1
    9. 0FBE  6E1F  MOVWF BEACONstate, ACCESS
    10.  
    BEACONstate is just a filler from some code I used to demonstrate the use. The key is that the defined construct for the input generates a simple bit test and skip - just what you want.

    XC8 seems to be happy with the old HiTech constructs so:
    LATB |= 0x01 sets RB0
    LATB &= ~0x01 clears RB0
    LATB ^= 0x01 toggles RB0
    all with native assembler bsf/bcf and so on.. similar for inputs, too as shown in the code above. An active low input can be done with:

    #define MY_INPUT_FALSE (~PORTB & 0x01) // True when RB0 == 0

    Have fun
     
    Last edited: May 1, 2015
  3. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,392
    1,606
    With all the constructs used in C code it is usually a very good thing to add the include file for the PIC you are using. Then you can easily search it when these things come up.

    I suspect you are seeing two errors when you compile:

    Code (Text):
    1. Error   [255] C:\YourPath\YourFile.C; 66.21 not a member of the struct/union ""
    2. Error   [207] C:\YourPath\YourFile.C; 66.24 simple type required for "=="
    The number shows you the line number (which you get to by clicking the error in the build window). Then "not a member of the struct/union" simply means you made a typo either in the structure (here PORTB) or the member (here PORTB0). If you search out the include file (pic18f458.h**) you will find PORTB to be a valid union but there is no PORTB0 member: the port pins are called RB0 thru RB7.

    So change PORTB0 to RB0 and you will get a clean compile.

    ** Finding these files can be troublesome. Typically they are named the same as the pic. Formerly they were named with just a "p" before the rest (or just p18f458.h) but this has changed. Those files are still there but now they just point back to htc.h, which is what including xc.h gets you.
     
  4. JohnInTX

    Moderator

    Jun 26, 2012
    2,347
    1,029
    It does compile but at least the latest version of XC8 (1.34) warns that using the RBx construct is deprecated. At least it is for the 18F. I just completed an enhanced midrange XC8 project that used inputs declared as RBx with no complaints. Go figure.
     
  5. johnnyinwa

    Thread Starter Member

    Jun 24, 2013
    41
    1
    Well changing PORTBO to RBO did the job. Thanks for your help!! ;)
     
    ErnieM likes this.
  6. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,392
    1,606
    Since it is the header files and not the compiler that hold the definition of the PORTx structures they are rather easy to redefine, but I would be surprised if MC changes from the current definitions; their stated intent it to match the hardware data sheet nomenclature with the software identifiers.

    Also, my version of XC8 v 1.34 does not toss any warnings for this structure.

    So my mileage varied with this test.
     
Loading...