MPLAB X IDE Questions

[Kilroywashere]

Hey, I have a PIC16f627 and I want to program it I have a cheap K-150 programmer. I downloaded MPLAB X IDE  and im trying to understand where i would put code ....


Do i have to put my code in the "source files" tab as shown in the pic...


Or maybe im way off here... Any tips to put me on the right track ?

Or do i have to find out how to do assembly language to program it in Microbrn?

Pic is not as easy as  the atmega was...

Is this a good place to start? http://www.instructables.com/id/Programming-PIC-Microcontrollers/

And the code i have is for flashing an led im assuming that the code needs to be modified ...

Im just looking for reassurance that im on the right track, or a a push to a better way 

[MarkF]

Here is an example of how I do C source code.  A small project with one C file and one H file.  (I currently have 5 project loaded at one time. However, you must select a "main" project and it's the only one that gets compiled. If you want to compile a different one, you must first select it as the "main" project.)

Sorry, I only do assembly programs if it's required for execution speed or memory size or both. I haven't had those requirements for many years.

[Kilroywashere]

Thank you so much!

[TomS_]

If you want to write C you'll need to install the XC8 toolchain - mpasm cant compile C. You can download it free from the Microchip website, google it and you should find it easy enough.

You'll also want to create a "main.c" file instead of a text file - you will need a file called main.c with a routine called main() within it. That is essentially where the microcontroller will start executing, so you can call your reset routine from there to initialise peripherals etc.

The easiest way to do that is (after installing XC8 and restarting MPLAB X) is to right click Source Files, hover over New and then click main.c. That will create the file with all the requisite minimums.

I used to write assembly for 8 bit PICs back in my early days - I do enjoy it, its a fun challenge, but these days I have also moved to C pretty much exclusively. Its a lot easier to read (if written well) and way more productive.

My projects tend to follow this kind of structure:

Code: [Select]

Header Files
 - config_bits.h
 - main.h
 - file1.h
 - file2.h

Source Files
 - main.c
 - file1.c
 - file2.c

config_bits.h contains a copy/paste dump of the output of the config bits tool. It is included in to main.c

main.c/.h contain the main() routine which usually contains an infinite loop with a state machine if the project is complex enough, and maybe some other generic helper functions and (in the .h file) global variables. I try not to put too much in to main.c, instead breaking things out and grouping them in to other source/header files as appropriate.

file1/file2 .c/.h would be examples of where I would group related routines - for example, routines may be grouped by the type of peripheral they relate to, like the UART, I2C, etc. I'll typically use a much more descriptive name than just file1, file2 etc.

There are probably a whole bunch of schools of thought about how to organise your project - this works for me, use what ever works for you, or follow established guidelines (or establish them!) if working with a team. Look at other projects and see how they do it, like the Linux kernel.

Oh and pick 1 coding style and stick to it!

[eugenenine]

I was going to say similar as TomS, I put all the config stuff into a header file (use MCC or manually) so its out of the way of my code.

Then if you want to go one step further, this can help as your projects get bigger, make a main.c which calls other functions such as setup, main_loop, etc.  Then as you do simple code such as blink an LED you make a blink.c and call is from main.  Next maybe you make a read_blink.c which reads an input and blinks an LED and you call it from main.c and simply remake out blink.c within main.c.  Eventually you get more complex, maybe there is a uart.c and adc,c both called from main.c.

This helps to make code more portable, you can take the pic specific header to another project with the same pic, or if you need to take the whole project to a different pic you can use a different header file.

[Kilroywashere]

If you want to write C you'll need to install the XC8 toolchain - mpasm cant compile C. You can download it free from the Microchip website, google it and you should find it easy enough.

You'll also want to create a "main.c" file instead of a text file - you will need a file called main.c with a routine called main() within it. That is essentially where the microcontroller will start executing, so you can call your reset routine from there to initialise peripherals etc.

The easiest way to do that is (after installing XC8 and restarting MPLAB X) is to right click Source Files, hover over New and then click main.c. That will create the file with all the requisite minimums.

After installing XC8 and restarting MPLAB X I think I have what is required...


question:  In this example project I am using blinks an LED using PIC 16F877A.... and im using a pic16f627  Is a modification of the code required? Like do i have to change a pin name over or something? or will the code work for this chip im using ?

#include <xc.h>

// BEGIN CONFIG
#pragma config FOSC = HS // Oscillator Selection bits (HS oscillator)
#pragma config WDTE = ON // Watchdog Timer Enable bit (WDT enabled)
#pragma config PWRTE = OFF // Power-up Timer Enable bit (PWRT disabled)
#pragma config BOREN = ON // Brown-out Reset Enable bit (BOR enabled)
#pragma config LVP = OFF // Low-Voltage (Single-Supply) In-Circuit Serial Programming Enable bit (RB3 is digital I/O, HV on MCLR must be used for programming)
#pragma config CPD = OFF // Data EEPROM Memory Code Protection bit (Data EEPROM code protection off)
#pragma config WRT = OFF // Flash Program Memory Write Enable bits (Write protection off; all program memory may be written to by EECON control)
#pragma config CP = OFF // Flash Program Memory Code Protection bit (Code protection off)
//END CONFIG

int main()
{
  TRISB0 = 0; //RB0 as Output PIN
  while(1)
  {
    RB0 = 1;  // LED ON
    __delay_ms(1000); // 1 Second Delay
    RB0 = 0;  // LED OFF
    __delay_ms(1000); // 1 Second Delay
  }
  return 0;
}




Question 2: I Generate Source Code to Output then it tells me to  copy and paste this generated code to code editor.
Then enter the remaining code for the blinking of LED.


where do I paste this code to??

[MarkF]

Answer 1:
  It depends. In general you want to use PORT for reading and LAT for writing to/from the ports. However, some MCUs do not have LAT registers. In which case, you read and write using PORT.

Code: [Select]

// If the LAT registers exist
LATB = 0xff;      // To write to the entire port
// If no LAT registers
PORTB = 0xff;     // To write to the entire port

val = PORTB;      // To read from the entire port


// If the LAT registers exist
LATBbits.LB0 = 1;       // To write to bit 0 of port B
// If no LAT registers
PORTBbits.RB0 = 1;      // To write to bit 0 of port B

val = PORTBbits.RB0;    // To read bit 0 of port B


Answer 2:
  When you "Generate Source Code to Output", the configuration settings will be generated into the Output window. Then, copy the settings from the Output window into the top of your main.c file.

Note. Your main file does not need to be called main.c.  It's just the source file that contains the main() function. I usually call my main source and header files the same as the project name (i.e. projectName.c and projectName.h).

Code: [Select]

/*
 * File:   blink.c
 * Author: Mark
 *
 * Created on November 9, 2017, 6:56 PM
 */

// CONFIG
#pragma config FOSC = HS        // Oscillator Selection bits (HS oscillator: High-speed crystal/resonator on RA6/OSC2/CLKOUT and RA7/OSC1/CLKIN)
#pragma config WDTE = OFF       // Watchdog Timer Enable bit (WDT disabled)
#pragma config PWRTE = OFF      // Power-up Timer Enable bit (PWRT disabled)
#pragma config MCLRE = OFF      // RA5/MCLR pin function select (RA5/MCLR pin function is digital input, MCLR internally tied to VDD)
#pragma config BOREN = OFF      // Brown-out Reset Enable bit (BOD Reset disabled)
#pragma config LVP = OFF        // Low-Voltage Programming Enable bit (RB4/PGM pin has digital I/O function, HV on MCLR must be used for programming)
#pragma config CPD = OFF        // Data Code Protection bit (Data memory code protection off)
#pragma config CP = OFF         // Code Protection bits (Program memory code protection off)

#define _XTAL_FREQ 20000000L

#include <xc.h>
#include <stdio.h>
#include <stdlib.h>

/*
 *
 */
void main(void)
{
   TRISBbits.TRISB0 = 0;
   while (1) {
      PORTBbits.RB0 = 1;
      __delay_ms(1000);
      PORTBbits.RB0 = 0;
      __delay_ms(1000);
   }
}


[TomS_]

However, some MCUs do not have LAT registers. In which case, you read and write using PORT.

As I understand it, you should never write directly to a PORT register due to the read-modify-write problem, as this can have unintended side effects for output pins.

If you need to write to a PORT register on a device that doesnt have LAT registers, you would be best to implement your own LAT registers, write to those, and then copy them to the PORT register. The difference is that if you have pins that sink current for example, and you have those pins configured to be in a LOW state, that LOW state will be maintained when you write your LAT register to the PORT register regardless of what external voltage sources might be present on the pin.

If you look at how a typical I/O pin works internally, you can see that the state of the pins output latch loops back around via some tri-state buffers etc and is readable via the same PORT register. The state of the pin itself is also readable by the port register as in the case of an input pin. This means both internal and external voltage sources are visible via the PORT register. If an external voltage source is present on an output pin and you do a R-M-W operation on the PORT register to modify some other bit(s), you end up reading in those externally sourced HIGH states and writing them back, which may unintentionally alter pins which were previously configured LOW (sinking) to now be HIGH (sourcing).

So by example:

Code: [Select]

unsigned char myLATA = 0;  /* Create your own LAT register */
unsigned char val = 0;

myLATA |= 0x1;             /* Set bit 0 HIGH */
PORTA = myLATA;            /* Safe way to write to PORT register, external voltage sources
                            * are ignored therefore those output pins remain LOW */

if (PORTAbits.RA0) {
    myLATA &= 0xFE;         /* Set bit 0 LOW */
    PORTA = myLATA;        /* Safely write to PORT register */
}

I dont know whether the compiler will recognise R-M-W situations and perhaps implement something for you in the background, but personally I would not rely on something like this happening and I would implement my own mechanism explicitly.

Note. Your main file does not need to be called main.c.  It's just the source file that contains the main() function

Ah yes, you could be very right there, I might be confusing the fact that you need a main() function (unless perhaps you override that in the compiler) with also needing a main.c file.

[eugenenine]

Note. Your main file does not need to be called main.c.  It's just the source file that contains the main() function

Ah yes, you could be very right there, I might be confusing the fact that you need a main() function (unless perhaps you override that in the compiler) with also needing a main.c file.

While it is true you don't need main() to be in main.c after having to grep for main() in someone else's big project I started my own standard of having a main() inside of main.c and then main() just calls everything else I need from there so I always know where to look without searching