PIC12F509 & PIC18F26K20

[ocset]

Hello,
We need to program these two in XC8  C.
Can we do this?
Also, do you know what configuration bit commands we have to use, and/or where to find out.
Also, the libraries that we need to #include.

As you know, there is a certain amount of "setup" code needed...any info on where to find out  which "setup" code to use is needed.

Our software engineer has just left, telling us his code wouldnt work because our hardware is injecting noise into the pic......so we need to write our own code...just something simple, to see if the micro is indeed getting corrupted by circuit noise...we will just write simple code which eg takes one pin high when an input on another pin goes low, say....just to see if it works, and does/does not get corrupted by circuit noise.

On the pic18f26k20, it was the DALI code which wasnt working. The micro wasnt dimming leds according  to the dali commands sent to it.

[Andy Watson]

Unless you are prepared to publish hardware details, only you can determine the configuration bits. You will have to consult the datasheets but the first criterion is usually deciding what/where the clock source is. Keep the watchdog disabled until you have the basics working.

[voltsandjolts]

Sounds like you needs some extensive help.
Would you consider posting in the Jobs section and contracting someone for a few days. (Not me, but plenty of PIC experts around here)

[JPortici]

read the devices datasheet (answer is yes you can use a pickit 3, it's written there)
then read the XC8 manual

Short version: select "configuration memory" under device -> memory views. set the configuration words. hit generate code, copy that and paste it in a .c file. not in an header file. that's the only "startup" code you need for an 8bit and 16bit pic.

only include you really need is <xc.h> which then includes the selected MCU include file (register definitions)
i suggest you also include <stdint.h> so you can use fixed width types

standard c libraries, builtin functions like delays etc are documented in the compiler manual
if you absolutely need peripheral libraries you need to download and install MCC, but there is no need for them at all

[jpanhalt]

Our software engineer has just left, telling us his code wouldnt work because our hardware is injecting noise into the pic......so we need to write our own code...just something simple,

Did that engineer leave behind his source code?

If not, blinking LED's so to speak may not show you the noise source.

Those two chips are quite different.  What was the 12F509 tasked to do?  Did both chips show the same problem?   What was the problem, e.g., resetting?

John 

[ocset]

Hello,
Do you know why this code for PIC12F509 will not compile?
It is written in MPLAB X IDE and using XC8 C compiler.
All the code does is pick out a low to high transition on PORT GP4 and then wait 3 ms, then take PORT GP2 high.
I am festooned with build errors at the moment.

Code: [Select]

/*
 * File:   zapper.c
 * Author:
 *
 * Created on 03 June 2017, 23:55
 */

//This code turns the product ON at the mains peak voltage
//It does this by using the zero crossing detector input.

//This uses PIC12F509
//MPLAB X IDE
//XC8 C compiler (free)

#define  _XTAL_FREQ 4000000

#include <xc.h>
#include <stdint.h>

#pragma config OSC = ExtRC      // Oscillator Selection bits (external RC oscillator)
#pragma config WDT = OFF        // Watchdog Timer Enable bit (WDT disabled)
#pragma config CP = OFF         // Code Protection bit (Code protection off)
#pragma config MCLRE = ON       // GP3/MCLR Pin Function Select bit (GP3/MCLR pin function is MCLR)

//I have not set the MCLR pin as an input because it will be noise susceptible.
//Therefore i set MCLR up as reset, but i will never use it as reset..but will
//simply tie the pin top Vdd on the PCB.

//Define output
#define FETS     LATBbits.RB2;

//Define input
#define zero_x     PORTBbits.RB4;

//Define actions
#define ON    LATBbits.RB2 = 1  /*Turn ON FETs*/


//Declare functions which set up the microcontroller
void    disable_interrupts(void);   //How do this?
void    disable_pullups(void);      //How do this?
void    setup_ports(void);


void    setup_ports(void) {
    TRISB = 0b00011000;
    return;
}

//Declare variables
uint8_t    count;

void main(void) {
    setup_ports();
    //10 second delay
    for (count=1;count<=100;count++)   {
    __delayms(100);
    }

here:
    if {zero_x = 1} {goto here;}
here1:
    if {zero_x = 0} {goto here1;}

    //When it gets to this point, the zero crossing input has just gone high

    __delayms(3);   //delay to get to the mains peak
    ON;              //Turn ON FETs...at the mains peak

    while(1){;}

    return ();
}



[jpanhalt]

For starters, the 12F509 doesn't have a port B.  They are GP0..GP5. TRISx is just "TRIS." It doesn't have any LATx register.   It also doesn't have interrupts.  I don't do C, so I don't know how the "disable interrupts" will be handled.

John

[Andy Watson]

This may not do what you want, but it should at least get you through the compile stage:

Code: [Select]

/*
 * File:   zapper.c
 * Author:
 *
 * Created on 03 June 2017, 23:55
 */

//This code turns the product ON at the mains peak voltage
//It does this by using the zero crossing detector input.

//This uses PIC12F509
//MPLAB X IDE
//XC8 C compiler (free)

#define  _XTAL_FREQ 4000000

#include <xc.h>
#include <stdint.h>

#pragma config OSC = ExtRC      // Oscillator Selection bits (external RC oscillator)
#pragma config WDT = OFF        // Watchdog Timer Enable bit (WDT disabled)
#pragma config CP = OFF         // Code Protection bit (Code protection off)
#pragma config MCLRE = ON       // GP3/MCLR Pin Function Select bit (GP3/MCLR pin function is MCLR)

//I have not set the MCLR pin as an input because it will be noise susceptible.
//Therefore i set MCLR up as reset, but i will never use it as reset..but will
//simply tie the pin top Vdd on the PCB.

//Define output
#define FETS    GP2

//Define input
#define zero_x   GP4

//Define actions
#define ON    GP2 = 1  /*Turn ON FETs*/


//Declare functions which set up the microcontroller
void    disable_interrupts(void);   //How do this?
void    disable_pullups(void);      //How do this?
void    setup_ports(void);


void    setup_ports(void) {
    TRISGPIO = 0b00011000;
    return;
}

//Declare variables
uint8_t    count;

void main(void) {
    setup_ports();
    //10 second delay
    for (count=1;count<=100;count++)   {
    __delay_ms(100);
    }

    while (zero_x == 1) ;
    while (zero_x == 0) ;

    //When it gets to this point, the zero crossing input has just gone high

    __delay_ms(3);   //delay to get to the mains peak
    ON;              //Turn ON FETs...at the mains peak

    while(1){;}

}


[ocset]

Thankyou Andy Watson !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

You are a genius as far as i am concerned !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

BUILD NOW SUCESSFUL !!!!!!!!!!!!!!!

You may just have saved my job, and saved my company from going bust !
Thankyou!

[KL27x]

For starters, the 12F509 doesn't have a port B.  They are GP0..GP5. TRISx is just "TRIS." It doesn't have any LATx register.   It also doesn't have interrupts.  I don't do C, so I don't know how the "disable interrupts" will be handled.

John

Without even looking at the datasheet, I'm sure 12F509 has at least 2 timers which can generate an interrupt aside from the WDT and some GPIO digital input interrupt available on at least 2 of the pins. I've never seen a PIC without an interrupt. I can't imagine any microcontroller that does not have at least a timer interrupt.

 

[jpanhalt]

Without even looking at the datasheet, I'm sure 12F509 has at least 2 timers which can generate an interrupt aside from the WDT and some GPIO digital input interrupt available on at least 2 of the pins. I've never seen a PIC without an interrupt. I can't imagine any microcontroller that does not have at least a timer interrupt.

Maybe that's why there is a datasheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/41236E.pdf

John

[KL27x]

Thanks for the correction. I am quite used to being wrong, by now. I have the datasheet in hard copy that is practically wore out from use. But it has been many years and many upgrades later.




 

[Bruce Abbott]

I can't imagine any microcontroller that does not have at least a timer interrupt.

The 12F509 is a very old design, and it shows. The first PIC I used was its predecessor the 12C509, which has EPROM instead of Flash ROM. I used the OTP version. No in-system debugging - so the development cycle was write program, burn chip, test operation, throw in bin and get a new chip! Teaches you to be really careful about getting the code right first time...

[JPortici]

pic10 (baseline) do not have interrupts!

[jpanhalt]

@Bruce,

Last year was my first experience with an early 16Cxx chip.   The project was done to verify that the known problem with an interrupt occurring while clearing GIE could not be demonstrated with later chips (other then the three that Microchip recognized as being affected).

Here is a statement of the problem from Microchip's datasheet for the 16C84:

Note 2: If an interrupt occurs while the Global
Interrupt Enable (GIE) bit is being cleared,
the GIE bit may unintentionally be reenabled
by the user’s Interrupt Service
Routine (the RETFIE instruction). The
events that would cause this to occur are:
1. An instruction clears the GIE bit while
an interrupt is acknowledged
2. The program branches to the
Interrupt vector and executes the
Interrupt Service Routine.
3. The Interrupt Service Routine
completes with the execution of the
RETFIE instruction. This causes the
GIE bit to be set (enables interrupts),
and the program returns to the
instruction after the one which was
meant to disable interrupts.
The method to ensure that interrupts are
globally disabled is:
1. Ensure that the GIE bit is cleared by
the instruction, as shown in the
following code:
LOOP BCF INTCON,GIE ;Disable All
; Interrupts
BTFSC INTCON,GIE ;All Interrupts
; Disabled?
GOTO LOOP ;NO, try again
; Yes, continue
; with program
; flow

Anyway, those chips -- at least authentic ones -- are quite dear in today's market.  I only had 2 to test.    I can't imagine programming every day under those conditions.   Fortunately, MPLab worked for me.   I still have one virgin 16C84 left.

John

[jpanhalt]

pic10 (baseline) do not have interrupts!

That's true, but not all 10Fxxx chips are baseline.  The 10F32x do have interrupts and output latches, and they are cheaper than the 12F509.

John

[KL27x]

so the development cycle was write program, burn chip, test operation, throw in bin and get a new chip! Teaches you to be really careful about getting the code right first time...

This is why we have these archaic IC socket things, eh? I remember buying a bunch of them because I was supposed to need them and they looked cool. Then I had no use for them. I guess EEPROM and ICSP and self-writing devices enabling bootloaders weren't always the norm.

But wow, looking back, I remember trying to use up some of these old PICs. I had to use 12F629 over the 508, for even very simple stuff.  Even the way I write code would not work with baseline architecture, anymore. First, I'd run out of stack. Second, the whole not having a return command... i.e. you can't even preserve the W register upon returning from a subroutine. Third... no interrupts..? It is painful to even write assembly for these baseline devices.

I understand why C compilers are not efficient with these devices. It is because assembly isn't even efficient. You spend 3 or 4 times as much code to do the same thing, if you can even do it at all. Even for the minimal cost savings in a high volume project, the baseline PIC is more trouble than it is worth if you need accuracy of the internal oscillator. It is quite easy for the factory tuned calibration number to be lost or corrupted by a bad ICSP connection and create a big problem. Putting in a defaut middle of the road setting will result in error of up to 20%. And recalibrating it while in circuit takes a lot of time, if it is even possible. This is not quite the same problem as OTP, but even this is quite a pain.

[Bruce Abbott]

I guess EEPROM and ICSP and self-writing devices enabling bootloaders weren't always the norm.

Previously to PICs I was using 8031 and 68HC05 with external EPROM, and before that Z80. Most MCUs back then were mask programmed. You could get windowed EPROM versions for development, but they were very expensive and took 20 minutes to erase (and often failed after a few write/erase cycles). I also obtained an 8031 variant that had a 'piggyback' EPROM socket on top of the chip.
   

whole not having a return command... i.e. you can't even preserve the W register upon returning from a subroutine. Third... no interrupts..? It is painful to even write assembly for these baseline devices.

And yet they could still be useful. My first PIC project was an ESC for RC models. That little PIC was able to read a 1-2ms servo pulse with glitch filtering and failsafe, generate 2.7kHz PWM, apply the brake and check for low battery voltage, all in real time. It replaced an analog circuit that used several ICs and was less sophisticated.

assembly isn't even efficient. You spend 3 or 4 times as much code to do the same thing, if you can even do it at all.

Actually this isn't quite true. PIC has a 'RISC' instruction set that might appear to need more code, but every instruction is only 1 word and most execute in a single CPU cycle (4 clock cycles). You may need more lines of assembler source code to do the same job as a typical CISC MCU, but the machine code is often more compact and faster. For example the original 8031 took several bytes and 12 clock cycles or more to do simple things like testing a bit in a register.

The PIC just does things a bit differently. On baseline PICs you set W to a literal value when returning from a subroutine, so you have to put variable return values into a 'file register' (RAM) instead. But file registers in the PIC are like CPU registers in other architectures, so in reality all values are returned in registers! The stack only has 2 levels, but with no interrupts and no PUSH or POP you know exactly how much stack is required.  You can only call subroutines 2 levels deep, but most of the time this is plenty for the things you can do in 511 words of ROM or less (and when it isn't you just inline the code).

the baseline PIC is more trouble than it is worth if you need accuracy of the internal oscillator.

This was true of older chips such as the 12C509, but modern versions are a lot more accurate. Loosing the calibration value is only a problem if you use bad tools. At least PICs don't brick themselves if you choose the wrong oscillator option like AVRs do.   

Baseline PICs certainly are limited, but when introduced they were a big advancement over other MCUs when you needed a compact device to do a simple job. And with the 10F series they still are. Of course now with the 10F322 you have even more power (midrange instruction set, 16MHz clock, ADC, PWM, Configurable Logic Cell etc.) 
 

[KL27x]

The PIC just does things a bit differently. On baseline PICs you set W to a literal value when returning from a subroutine, so you have to put variable return values into a 'file register' (RAM) instead. But file registers in the PIC are like CPU registers in other architectures, so in reality all values are returned in registers

Yes, I appreciate that. I code in PIC assembly, extensively. But then you have to move this data back into the W register half the time, which is extra code space and execution time. Often it is the case you need to transfer data between subroutine and main code loop using registers in addition to W, but W is almost a given that you might not want to overwrite that with a literal. That's an extra code and execution on both ends, in the subroutine and the main code loop. At least. W transcends banks, too, so it could be even worse.

Actually this isn't quite true. PIC has a 'RISC' instruction set that might appear to need more code, but every instruction is only 1 word and most execute in a single CPU cycle (4 clock cycles). You may need more lines of assembler source code to do the same job as a typical CISC MCU, but the machine code is often more compact and faster. For example the original 8031 took several bytes and 12 clock cycles or more to do simple things like testing a bit in a register.

Indeed. I appreciate this fact quite a bit. This is one reason I do not use 18F unless I am using C. Many of the instructions are 2 or 3 lines of code and execution. And this takes away one of the elegant things about assembly in PIC midrange devices. This essentially wrecks the ability to branch by making relative changes to the PC. What I meant was that compared to midrange devices, for which this observation also holds true, assembly is quite a bit less efficient in the baseline PICs. This is true both in regards to code space and execution cycles.

I bet you could have done your ESC for RC models in significantly less code and end up with less latency (fewer instructions executed) on a midrange device, by utilizing just a few of the midrange instructions and special registers (like LAT), and having an ISR. Then, just with the larger stack, you could halve the remaining code space, perhaps more.

Regarding OSCCAL, the first thing you do with any dev board is read it and write it down, somewhere. This extra labor is what makes cost savings of baseline questionable in any large quantity project. And in small quantity, the cost savings are not existent. I know 509 was advanced when it came on the market. I don't know if it will ever die, but maybe it should.
 

[Bruce Abbott]

I code in PIC assembly, extensively.

Me too - and Z80, MC68000 etc. 90% of my code is assembler.
 

But then you have to move this data back into the W register half the time

W is the accumulator, equivalent to the A register in 68xx, Z80 etc. where it is a similar bottleneck. However the PIC has instructions such as  DECF and BTFSS which don't involve W. MCU applications often do more bit manipulation than math operations, so the single accumulator isn't that bad.

Often it is the case you need to transfer data between subroutine and main code loop using registers in addition to W, but W is almost a given that you might not want to overwrite that with a literal.

I use W to pass a literal value because MOVLW is only 1 cycle. Variables are passed in file registers.

Compared to CISC you need to write more lines of code, but macros can cut the typing down dramatically. To get a true comparison of code efficiency you need to count the number of words and cycles used in the entire operation, not just focus on individual instructions. Where PIC falls down compared to more powerful 8 bit MCUs is cycle time. AVRs are faster because they only need 1-2 clock cycles per instruction, whereas PIC needs 4. Newer PICs with 32MHz clocks are about as fast as a 16MHz AVR. 

What I meant was that compared to midrange devices, for which this observation also holds true, assembly is quite a bit less efficient in the baseline PICs. This is true both in regards to code space and execution cycles... I know 509 was advanced when it came on the market. I don't know if it will ever die, but maybe it should.

I mostly program midrange 12F/16F and do use the extra instructions, but most of time they don't make a lot of difference. The biggest improvement by far is peripherals like PWM which take the load off the CPU. But newer chips are becoming less code efficient (and a pain to code in assembler) due to all the bank switching required to access them. This doesn't really matter though because they have faster clock speeds and more memory.     

Baseline PICs will eventually die because they can be replaced by midrange chips at lower cost. When I run out of a particular PIC I upgrade to the more modern equivalent eg. 12C509 to 12F675, 10F200 to 10F322.   

I bet you could have done your ESC for RC models in significantly less code and end up with less latency (fewer instructions executed) on a midrange device, by utilizing just a few of the midrange instructions and special registers (like LAT), and having an ISR. Then, just with the larger stack, you could halve the remaining code space, perhaps more.

Contrary to popular belief, ISRs increase latency, and my ESC code would totally break if interrupts were used. I did get lower latency and higher resolution by using the PWM and 16 bit timer modules in a 12F617.   

Regarding OSCCAL, the first thing you do with any dev board is read it and write it down, somewhere. This extra labor is what makes cost savings of baseline questionable in any large quantity project. And in small quantity, the cost savings are not existent.

Better tools avoid overwriting the OSCAL value, so you shouldn't have to do this.

Slightly OT - I have a Cypress CYKIT-049 dev board which comes pre-programmed with a bootloader. But the bootloader is part of your application, so if you forget to include it then the board cannot be reprogrammed via the onboard interface and so is effectively bricked! 

 

[jpanhalt]

@Bruce Abbott

I agree in large part, but have moved to the "enhanced" mid-range and the 2nd generation of that species.   They are not  significantly more expensive (for a hobbyist) than the older mid-range and have greater capabilities.  Some of which are direct operation on WREG, instructions for addition and subtraction that incorporate the carry or borrow bit inherently, and enhanced math.

John

[KL27x]

I mostly program midrange 12F/16F and do use the extra instructions, but most of time they don't make a lot of difference. The biggest improvement by far is peripherals like PWM which take the load off the CPU. But newer chips are becoming less code efficient (and a pain to code in assembler) due to all the bank switching required to access them. This doesn't really matter though because they have faster clock speeds and more memory.     

I have difference of opinion, here. IMO, nearly everything that is good about the baseline is gooder in the midrange and the enhanced midrange. And if the improvement between the enhanced midrange and the regular midrange is moderate, the gap between the baseline and midrange is enormous. More banks are there due to more features... if you don't use those extra features, you aren't doing much more bank switching, IMO. Many of the most commonly accessed special registers are accessible in all banks. In addition, when you get to the enhanced, there are some nice additions which help in this regard. The enhanced can access all banks of its memory linearly, and they also have 16 bytes of what they call "nonlinear" user memory that is accessible from all banks.

I mostly program midrange 12F/16F and do use the extra instructions, but most of time they don't make a lot of difference.

I suppose it depends on what you're doing and how you write code. But stack size alone... if that doesn't make a difference even on the simplest of programs, I ...

Regarding ISR, I may have jumped the gun on your ESC project. I dunno what all it's doing. Entering and exiting the ISR eats some instruction cycles. But wherever you are going to use one is usually going to reduce latency and almost always increase efficiency in code volume and/or power consumption. I should not assume your code could possibly be improved in efficiency in any way regarding latency.. maybe you had to work very had to optimize this aspect.

but macros can cut the typing down dramatically.

I will personally not touch a macro, ever, under any circumstance. There is no occasion where it is worth the trouble for me. When you get errors, and the IDE points to your macro.... which is used 20 times....  the IDE can't show you which one is throwing an error. It can't even show you where you put all these macros.... So after you change the name of your macro and use the duplicate label error to locate them all, you still have to suss out the actual problem by studying the surrounding context of potentially each and every one... rather than knowing the exact one, single epicenter which you would otherwise be handed on a silver platter. 

Just from this statement alone, I can appreciated the effort and pain you go through to get the highest speed performance out of a baseline PIC to perform relatively simple tasks. I'll take the extra 4 cycles wherever possible to make my code more manageable by using subroutine over a macro. There are some things macros can do in one line which subroutines can't. I'll use two or 3, or however many it takes. If the latency is a real issue, I'll cut and paste the actual code over using a macro.

[ocset]

Hello,
Please could you help..the code is building now but not working.....please coudl you see why the following code does not turn a port on/off/on...

/*
 * File:   zapper.c
 * Author:
 *
 * Created on 03 June 2017, 23:55
 */



//This uses PIC12F509
//MPLAB X IDE
//XC8 C compiler (free)

#define  _XTAL_FREQ 4000000

#include <xc.h>
#include <stdint.h>


#pragma config OSC = IntRC      // Oscillator Selection bits (internal RC oscillator)
#pragma config WDT = OFF        // Watchdog Timer Enable bit (WDT disabled)
#pragma config CP = OFF         // Code Protection bit (Code protection off)
#pragma config MCLRE = ON       // GP3/MCLR Pin Function Select bit (GP3/MCLR pin function is MCLR)

//I have not set the MCLR pin as an input because it will be noise susceptible.
//Therefore i set MCLR up as reset, but i will never use it as reset..but will
//simply tie the pin top Vdd on the PCB.

//Define output
#define FETS     GP2

//Define input
#define zero_x     GP4

//Define actions



//Declare functions which set up the microcontroller
//void    disable_interrupts(void);   //How do this?
//void    disable_pullups(void);      //How do this?
void    setup_ports(void);


void    setup_ports(void) {
    TRISGPIO = 0b00011000;
//    TRIS = 0x18;
    return;
}

//Declare variables
//

void main(void) {
    setup_ports();


   while(1){
    GP2 = 1;
    __delay_ms(30);   //delay to get to the mains peak
    GP2 = 0;
    __delay_ms(30);
   }
 

    return;
}

[jpanhalt]

Are you testing the on/off with a scope or something like and LED?  An LED may not show a change (30 ms is quite short) -- use 200 ms.

If scope, what do you see?  Just flat line?

Sorry, if those are stupid comments as I do not do C.

I assume GP3 is tied high with a resistor.

John

[ocset]

Thanks, im testing with scope
Ive got this far now, but the delay isnt working....either that or the for loop isnt working?

/*
 * File:   zapper.c
 * Author:
 *
 * Created on 03 June 2017, 23:55
 */

//This uses PIC12F509
//MPLAB X IDE
//XC8 C compiler (free)

#include <xc.h>
#include <stdint.h>
#include <stdio.h>
#include <pic.h>
#include <pic12f509.h>


#pragma config OSC = IntRC      // Oscillator Selection bits (internal RC oscillator)
#pragma config WDT = OFF        // Watchdog Timer Enable bit (WDT disabled)
#pragma config CP = OFF         // Code Protection bit (Code protection off)
#pragma config MCLRE = OFF       // GP3/MCLR Pin Function Select bit (GP3/MCLR pin function is MCLR)

#define  _XTAL_FREQ 4000000




//I have not set the MCLR pin as an input because it will be noise susceptible.
//Therefore i set MCLR up as reset, but i will never use it as reset..but will
//simply tie the pin top Vdd on the PCB.

uint8_t     count;

void main(void) {
    OPTION = 0x00;
    TRISGPIO = 0x18;
   
    for(count=1;count<100;count++) {
    __delay_ms(100);
    }
   
    while(GPIObits.GP4 = 1);
    while(GPIObits.GP4 = 0);
   
    __delay_ms(4);
   
    GPIObits.GP4 = 1;
   
    while(1);
           
           

//   while(1){
 //   GPIObits.GP2 = 1;
//    __delay_ms(30);   //delay to get to the mains peak
 //   GPIObits.GP2 = 0;
 //   __delay_ms(30);
 //  }
 
    return;
}