PIC18F45K22 PWM

(instructions, reset, WDT, specifications...) PIC17Cxx, PIC18Fxxx

Re: PIC18F45K22 PWM

Postby Tom Maier » Thu Jul 03, 2014 2:51 am

It's a plugin that generates the configuration code for you. The 18f45k22 is one of the supported devices.

http://www.microchip.com/pagehandler/en ... /home.html
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F45K22 PWM

Postby SLTom992 » Fri Jul 04, 2014 1:43 am

This add-on is for the MPLAB IDE. The MPLAB X IDE has it built-in.
SLTom992
 
Posts: 58
Joined: Tue Jun 10, 2014 8:59 pm
PIC experience: Professional 1+ years with MCHP products

Re: PIC18F45K22 PWM

Postby Tom Maier » Fri Jul 04, 2014 1:42 pm

So can you show the setup code and any driver code that it generated? I'm curious about what is does.

I've had struggles with this same issue that you are dealing with, the set up on these new chips is pretty convoluted and this feature sounds like a good solution.

I can't do it right now because I'm running mplabx 1.85 and older versions of the compilers. I need to upgrade. Here is a list of the required versions and supported devices:
http://www.microchip.com/forums/m798289.aspx
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F45K22 PWM

Postby SLTom992 » Fri Jul 04, 2014 11:18 pm

I have been working on the program both from some help from the MicroChip site when it isn't screwing up and trying to make heads or tails from the manual. Here is my latest revision and it too is NOT generating a PWM output. As you can see the TRISC is reset at the end so it isn't the output. Also although the SOCSI input on that pin has priority as an analog input that has been disabled with ANSELC = 0;. Also PWM is an output which bypasses the analog input stuff.

There is a configuration bit but it doesn't seem to be incorrect.

// CONFIG3H
#pragma config CCP2MX = PORTC1 // CCP2 MUX bit (CCP2 input/output is multiplexed with RC1)

Does anyone have any ideas?

Code: Select all
    // Initialize PWM output
    TRISCbits.TRISC1 = INPUT;       // Disable CCP output

    // Set up CCP/PWM registers
    TMR4 = 0x4E;                    // Set Period for 800 Hz
    PR4 = 0x4E;                     // Set compare period.
    CCPR2L = (PR4 >> 1);            // Set pulse width
    CCPTMRS0bits.C2TSEL = 01;       // Select timer
    CCP2CONbits.CCP2M = 0b1100;     // set to PWM Mode
    CCP2CONbits.DC2B = 0;           // lsbs of pulse width compared with timer?

    // Timer Setup
    TMR4IE = FALSE;                 // No timer interrupt - freerunning
    // flag gets set regardless of interrupt enable or not
    T4CONbits.T4CKPS1 = 1;          // /16 prescaler
    T4CONbits.TMR4ON = YES;         // tmr on

    TRISCbits.TRISC1 = OUTPUT;      // Enable CCP output
SLTom992
 
Posts: 58
Joined: Tue Jun 10, 2014 8:59 pm
PIC experience: Professional 1+ years with MCHP products

Re: PIC18F45K22 PWM

Postby ric » Sat Jul 05, 2014 12:23 am

TMR4 = 0x4E; // Set Period for 800 Hz
As I've mentioned several times, this is pointless. The period is set by PR4.

Now, as I just asked over at MCHIP, is this on real hardware, or a simulator?
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 659
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F45K22 PWM

Postby SLTom992 » Tue Jul 08, 2014 10:49 pm

Ric, I understand your point. At initialization the timer would simply compare and pop to zero anyway so it didn't hurt anything. Worse case the program would wait at the flag until the timer rotated a complete cycle which would set the flag.

I decided that the clock might be a problem so I changed the PWM clock from 4 to 2 (My intention had been to use 2 for the CCP1/PWM output). After changing it over I careful single stepped through the initialization procedure using the ICD3.

What I eventually found was that:

CCP2CONbits.CCP2M = 0b1100; // set to PWM Mode

was setting CCP2M as 0x03. This is a compiler error. I have found a few of these sorts of things so you have to be very careful that initializations are actually being set the way you think they are. Replacing this command with:

CCP2CONbits.CCP2M = 0x0C; // set to PWM Mode

put the PWM into PWM mode.

I also discovered that when I first started developing the program I shut down all of the outputs specific to my hardware so that I could trace signals one at a time. On the PWM I had forgotten this and there the main problem was. So erasing that command turned the PWM on exactly at the correct period and pulse width.

So tested and operating code for initializing a freerunning PWM in a PIC18F45K22 is:

Code: Select all
   
    // Initialize PWM output==========================
    TRISCbits.TRISC1 = INPUT;       // Disable CCP output (verified as "1")

    // Suggestion from Forum
    // These two default to these values on reset anyway
    ECCP2AS = 0; // PWM Shutdown disabled
    PMD1 = 0; // (normal default setting)

    // Timer Setup
    TMR2 = 0;
    T2CONbits.T2CKPS1 = 1;      // /16 prescaler
    T2CONbits.TMR2ON = YES;     // tmr on

        // Set up CCP/PWM registers
    PR2 = 0x4E; // Set compare period.

    CCPR2L = (PR2 >> 1);        // Set pulse width
    CCP2CONbits.DC2B = 2;       // lsbs of pulse width

    CCPTMRS0bits.C2TSEL = 0; // Select timer 4
    CCP2CONbits.CCP2M = 0x0C; // set to PWM Mode

    // flag gets set at compare regardless of interrupt enable or not
    // this does not trigger an interrupt so should be immaterial

    // This is done only so that initial PWM is correct pulse width
    while (!TMR2IF);
    TMR2IF = FALSE;             // No timer interrupt - freerunning

    TRISCbits.TRISC1 = OUTPUT; // Enable CCP output (verified as "0")
    // ============================================================


I should note errors found both mine, manual and compiler:

The manual will get very weak in places:

DCxB<1:0>: PWM Duty Cycle Least Significant bits - since the PRx register is 8 bits what do these LSB's on a ten bit register do? This is after all a comparison.

The point can't be stressed too strongly that although this is a DIGITAL PROCESSOR it contains many analog inputs to the 10 bit internal ADC. What is completely beyond my kin is that the chip defaults to Analog inputs. I would expect that you'd have to specifically set it to Analog Inputs. Because of this you can still output digital signals out of an analog port but you cannot input digital signals without specifically disabling the analog inputs using the ANSELx commands.

The compiler makes errors on REGbits.bitgroup commands and/or numbering system. Sometimes it will make errors on binary, sometimes on decimal and sometimes on hex. So you must have an in-circuit debugger in order to look at each load and/or transfer.

Sometimes it will also make errors on the specific group name such as INT1IE (this may not be one of the errors) and you have to play with the numbers.

The ICD3 and the XC-8 are not entirely compatible. Even the free version will change the code around a bit so that you can single step through your code and it will take an entirely unexpected jump. Usually you can fix this by doing nothing more than rearranging your code.
SLTom992
 
Posts: 58
Joined: Tue Jun 10, 2014 8:59 pm
PIC experience: Professional 1+ years with MCHP products

Re: PIC18F45K22 PWM

Postby ric » Tue Jul 08, 2014 11:21 pm

SLTom992 wrote:DCxB<1:0>: PWM Duty Cycle Least Significant bits - since the PRx register is 8 bits what do these LSB's on a ten bit register do? This is after all a comparison.

From figure 14-4 on page 186 of the datasheet.
The 8-bit timer TMRx register is concatenated
with the 2-bit internal system clock (FOSC), or
2 bits of the prescaler, to create the 10-bit time
base.

so this does give you another two bits of resolution.

What is completely beyond my kin is that the chip defaults to Analog inputs. I would expect that you'd have to specifically set it to Analog Inputs. Because of this you can still output digital signals out of an analog port but you cannot input digital signals without specifically disabling the analog inputs using the ANSELx commands.

This is entirely necessary due to the behaviour of digital inputs. They will consume a lot of current if the input voltage is in the "transition region", i.e. higher than the highest valid "low", but lower the the lowest valid "high".
Any pin which can act as an analog input might have this sort of voltage on it on power up. The safest option, which is what Microchip chose, is to leave the digital input buffers disabled on all those pins, so the designer can only switch on the buffers to pins which are known to be driven by digital signals.
It helps to remember that you are not "disabling the analog input", you are "enabling the digital input". In fact, you can still do analog measurements on pins which have the digital input buffer enabled.

The compiler makes errors on REGbits.bitgroup commands and/or numbering system. Sometimes it will make errors on binary, sometimes on decimal and sometimes on hex. So you must have an in-circuit debugger in order to look at each load and/or transfer.

I've never struck this, but then I never initialise parts of registers, I always write the entire register in one go during initialisation.
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 659
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: PIC18F45K22 PWM

Postby SLTom992 » Wed Jul 09, 2014 1:47 am

That's a somewhat incomplete explanation of how to get 10 bits with 8 bit registers by pulling two bits for one register off of the CCPxCON (5:4) and using two bits out of the clock divider. They could have been more effective with that explanation.

As for defaulting the inputs to analog. While I can understand your explanation I would think that the inputs are either floating or in use and in either case will be initialized within clock cycles so it is hardly a battery drain.

It turns out that the majority of my problems have been those bit setting errors. If you remember, in a previous subject you suggested that I use that bit setting routine so that you wouldn't have to look up each register to see what bits I was setting since you weren't familiar with every PIC on the market. And I agree that's probably a superior style save for those compiler errors.
SLTom992
 
Posts: 58
Joined: Tue Jun 10, 2014 8:59 pm
PIC experience: Professional 1+ years with MCHP products

Re: PIC18F45K22 PWM

Postby vloki » Wed Jul 09, 2014 10:01 am

ric wrote:
SLTom992 wrote:The compiler makes errors on REGbits.bitgroup commands and/or numbering system. Sometimes it will make errors on binary, sometimes on decimal and sometimes on hex. So you must have an in-circuit debugger in order to look at each load and/or transfer.

I've never struck this, but then I never initialise parts of registers, I always write the entire register in one go during initialisation.

I don't remember of any problems that I had with bitfields at the moment.
(often use them /manly with C18 compiler / sometimes with XC8 in student labs)
vloki
Verified identity
 
Posts: 186
Joined: Wed May 28, 2014 8:42 am
Location: Germany
PIC experience: Professional 5+ years with MCHP products

Previous

Return to 16-Bit Core

Who is online

Users browsing this forum: No registered users and 10 guests

cron