XC8 and Hi-Tech help! Can't get started.

Discussion in 'Embedded Systems and Microcontrollers' started by diogenes500, Jan 24, 2013.

  1. diogenes500

    Thread Starter New Member

    Jan 24, 2013
    2
    0
    Hello,

    I'm rather new to PIC microcontrollers but have had decent success with the PIC18F series and the C18 compiler (with MPLAB 8.8x). Recently I've wanted to move to the MPLAB X and the XC8 compiler, but am having great trouble successfully operating anything other than the 18F series. I can't even get an LED to blink! My simple programs compile just fine but then nothing happens. I've searched the forums, read datasheets, nothing seems to work. I've tried it on multiple MCUs (of the same type) and nada.

    As an example, I'm trying to program the PIC16f819 with a PICKit3 and either MPLAX 8.8x or MPLAB X with hi-tech or XC8 (nothing has worked). Below is one instance, tyring to compile with hi-tech on MPLAB 8.8x for starters, of the dozen of programs I've tried to code with. It compiles fine but the LED (ON RB4) doesn't blink. Same with xc8 and MPLAB X. I've commented out the config bits because the compiler doesn't like FOSC_INTIO1 (which is in the datasheet?) and set them via the Configure >Configuration Bits MPLAB interface. They are

    FOSC_INTRC, WDTE off, PWRTE off, MCLRE off, BOREN off, LVP off, cpd off, wrt off, ccpmx RB2, CP off.

    Any suggestions would be greatly appreciated! This is driving me crazy!

    Code ( (Unknown Language)):
    1.  
    2. -------------------------------------
    3.  
    4.  
    5. #include <htc.h>
    6.  
    7. //__CONFIG(FOSC_INTIO1 & WDTE_OFF & PWRTE_OFF & MCLRE_OFF);
    8.  
    9. //needed for time delay
    10. #define _XTAL_FREQ 4000000
    11.  
    12. void main()
    13. {
    14.     //run at 4 MHz
    15.     OSCCONbits.IRCF2=1;
    16.     OSCCONbits.IRCF1=1;
    17.     OSCCONbits.IRCF0=0;
    18.  
    19.     TRISB = 0;
    20.     PORTB =1;
    21.  
    22.     while(1)
    23.     {
    24.         __delay_ms(100);
    25.             PORTB =!PORTB;
    26.     }
    27.  
    28. }
    29.  
    30. ------------------------------------------
    31.  
     
    Last edited by a moderator: Jan 24, 2013
  2. nerdegutta

    Moderator

    Dec 15, 2009
    2,517
    785
    Hi, and welcome.

    Please use code-tags.

    Code ( (Unknown Language)):
    1.  
    2. while(1)
    3.     {
    4.         __delay_ms(100);
    5.         PORTB =!PORTB;
    6.     }
    I think there is a problem here...
     
    diogenes500 likes this.
  3. t06afre

    AAC Fanatic!

    May 11, 2009
    5,939
    1,222
  4. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,394
    1,607
    The ! in "PORTB =!PORTB;" denoted a LOGICAL inversion, so TRUE becomes FALSE and FALSE becomes TRUE... now false is denoted by 0 and true by 1.

    So PORTB can have 2 discrete values: 0 or 1. So unless your LED is at RB0 it will never come on.

    Perhaps what you intended was to use a bitwise inversion, which is the tilda ~ character: "PORTB =~PORTB;"

    That will invert all 8 bits.

    This is definitely a case where a debugger can show you the trouble. Even the simulator will catch it.

    Try it, you'll like it!
     
    diogenes500 likes this.
  5. t06afre

    AAC Fanatic!

    May 11, 2009
    5,939
    1,222
    Sorry I did not see your real problem before now. But anyway take a look here http://en.wikipedia.org/wiki/Bitwise_operations_in_C As pointed out Ernie. Using the boolean not operator on any integer. Will only flip the least significant bit. And zero the rest of the bits. Also one more thing of advice. If you are unsure on which names that are used in the configword(s), and you are using a 16F chip. You will all the options in the PIC header file. In version 9.83 of the Hi-Tech C compiler it will be on the top of the header file. In more early version it will be in the end. Try to document the configword(s) in the code. The solution in MPLABX regarding this is quite elegant
     
    diogenes500 likes this.
  6. diogenes500

    Thread Starter New Member

    Jan 24, 2013
    2
    0
    Thanks to everyone who responded. That did the trick, and my LED is now blinking away. I've been used to toggling individual pins, not ports, and got tripped up. It worked both in my old MPLAB and the new X.

    Interestingly, the particular configuration bit settings are also crucial. If I set FOSC to internal oscillation and turn off MCLRE, MPLAB 8.xx complains but runs compiles anyway and everything works. If I then turn on MCLRE, it complies just fine but the MCU doesn’t work (doesn’t blink). With other configuration bit setups it works for some small time than goes dark. Very strange.

    By they way, I haven’t got a clear answer as to the syntax of MPLAB X. Is it just hi-tech, mostly hi-tech, or something completely different. I know there is the users’ guide, and I’ve looked through it, and although it might be exhaustive it’s not exactly forthcoming.
     
  7. t06afre

    AAC Fanatic!

    May 11, 2009
    5,939
    1,222
    You should know that many programmers take control of the MCLR pin. If you use a PICKIT2 or 3 programmer. You can control the MLCR pin from MPLAB. I recommend not having MCLR enabled. Then you one thing less to think about
     
  8. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,394
    1,607
    The "MPLAB® XC8 C Compiler User’s Guide" is definitely exhausting but well worth your time, at least for the first few chapters. I agree, reading a section on "Divergence from the ANSI C Standard" is kinda meaningless unless you have a solid appreciation for the minutia of the standard itself. One can just do what one can do...


    I don't like putting configuration information set inside the IDE. MPLAB non-X could do that, but it leads to code without the config information listed anywhere (it's in the project files), so you can't do a copy and paste to a forum to let someone check it for you.

    Again, while a simulator is excellent, there are things an in-circuit debugger will tell you that can't be learned other ways. To use one the MCLR pin needs to be enabled. For hardware, all you need is a pull up resistor on MCLR and it is forever happy for the day you remove the programmer/debugger and MCLR runs on it's own. The PICkit2 or 3 do in circuit debugging for most PICs.
     
Loading...