From: Martin Riddle on


"Phil Hobbs" <pcdhSpamMeSenseless(a)electrooptical.net> wrote in message
news:4B6BA5B4.2000806(a)electrooptical.net...
> Okay, so I'm trying to resurrect my long-deceased PIC skills. (I do a
> lot of C++ programming, off and on, but my last significant firmware
> was about 2000--the Footprints sensor, running on a PIC17C456.)
>
> From last time, I remember that MCU programming is all about getting
> the configuration bits right--once that's done, it's pretty simple.
> Sooo, I'm trying something fairly simple to start with, namely
> controlling an RC airplane servo.
>
> The servo needs 0.8-2.4 ms pulses, at a rep rate between 50 and 100
> Hz. I'm using a PIC 18F46k20 demo board with a nice little OLED
> display, running at a clock frequency of 64 MHz (16 MHz instruction
> clock). The PWM is done with Timer 2 and capture/PWM module ECCP 1.
>
> I started with demo program, which ran fine. Next I ported that to
> Hi-Tech C, which I remember very fondly from back when--it was pretty
> nearly bug-free, in stark contrast to Microchip's C17, which stank on
> ice. So far, so good.
>
> I got the PWM working OK, but with a 64 MHz clock, the slowest rate
> the PWM can go is 4 kHz (10-bit resolution and 16x prescaler), which
> is too quick for the servos. Sooo, I used the TMR2 interrupt handler
> to implement a divide-by-64 counter. For N+M/1024 cycles, it turns ON
> the RD5 output when the down-count reaches N, and then switches to the
> PWM for cycle 0 only. That way, I could have N complete cycles and
> M/1024 partial cycles, yielding 15 bits resolution at a 61 Hz rep
> rate. Plenty good for an RC servo.
>
> However....
>
> The 15 bits are made up of the number of full cycles (5 bits), bits 4
> and 5 of the CCP1CON register, plus an 8-bit value in CCP1L.
> According to the datasheet, any time I'm using x256 division in TMR2,
> I should be getting 10 bits worth of resolution, but it's acting
> exactly as though I
> were getting only 8--changing the programmed delay produces 4 times
> more PWM duty cycle change than it should, and the two CCP1CON bits
> don't seem to do anything, though I can read and write them correctly.
>
> The setup values are:
> T2CKPS0 = 0;
> T2CKPS1 = 1; //prescale by 16
> PR2 = 0xFF; // divide by 256
> DC1B1:DC1B0:CCPR1L = many values
>
> This is almost certainly pilot error, but the reason doesn't exactly
> leap out of the 450-page datasheet.
>
> C'mon, all you PIC guys--what gives?
>
> Thanks
>
> Phil Hobbs
>
> --
> Dr Philip C D Hobbs
> Principal
> ElectroOptical Innovations
> 55 Orchard Rd
> Briarcliff Manor NY 10510
> 845-480-2058
> hobbs at electrooptical dot net
> http://electrooptical.net

I haven t looked at the data sheet, but you might look at the related
function of the registers.
MicroChip likes to hide info for switches elsewhere in the data sheet.
Like the default state of some digital/analog pins, is actually analog
not a digital input. The bit for this is listed on the ADC section not
the digital Port bit section (16F877).


Cheers


From: Spehro Pefhany on
On Sat, 6 Feb 2010 09:56:47 -0500, the renowned "Martin Riddle"
<martin_rid(a)verizon.net> wrote:

>
>
>"Phil Hobbs" <pcdhSpamMeSenseless(a)electrooptical.net> wrote in message
>news:4B6BA5B4.2000806(a)electrooptical.net...
>> Okay, so I'm trying to resurrect my long-deceased PIC skills. (I do a
>> lot of C++ programming, off and on, but my last significant firmware
>> was about 2000--the Footprints sensor, running on a PIC17C456.)
>>
>> From last time, I remember that MCU programming is all about getting
>> the configuration bits right--once that's done, it's pretty simple.
>> Sooo, I'm trying something fairly simple to start with, namely
>> controlling an RC airplane servo.
>>
>> The servo needs 0.8-2.4 ms pulses, at a rep rate between 50 and 100
>> Hz. I'm using a PIC 18F46k20 demo board with a nice little OLED
>> display, running at a clock frequency of 64 MHz (16 MHz instruction
>> clock). The PWM is done with Timer 2 and capture/PWM module ECCP 1.
>>
>> I started with demo program, which ran fine. Next I ported that to
>> Hi-Tech C, which I remember very fondly from back when--it was pretty
>> nearly bug-free, in stark contrast to Microchip's C17, which stank on
>> ice. So far, so good.
>>
>> I got the PWM working OK, but with a 64 MHz clock, the slowest rate
>> the PWM can go is 4 kHz (10-bit resolution and 16x prescaler), which
>> is too quick for the servos. Sooo, I used the TMR2 interrupt handler
>> to implement a divide-by-64 counter. For N+M/1024 cycles, it turns ON
>> the RD5 output when the down-count reaches N, and then switches to the
>> PWM for cycle 0 only. That way, I could have N complete cycles and
>> M/1024 partial cycles, yielding 15 bits resolution at a 61 Hz rep
>> rate. Plenty good for an RC servo.
>>
>> However....
>>
>> The 15 bits are made up of the number of full cycles (5 bits), bits 4
>> and 5 of the CCP1CON register, plus an 8-bit value in CCP1L.
>> According to the datasheet, any time I'm using x256 division in TMR2,
>> I should be getting 10 bits worth of resolution, but it's acting
>> exactly as though I
>> were getting only 8--changing the programmed delay produces 4 times
>> more PWM duty cycle change than it should, and the two CCP1CON bits
>> don't seem to do anything, though I can read and write them correctly.
>>
>> The setup values are:
>> T2CKPS0 = 0;
>> T2CKPS1 = 1; //prescale by 16
>> PR2 = 0xFF; // divide by 256
>> DC1B1:DC1B0:CCPR1L = many values
>>
>> This is almost certainly pilot error, but the reason doesn't exactly
>> leap out of the 450-page datasheet.
>>
>> C'mon, all you PIC guys--what gives?
>>
>> Thanks
>>
>> Phil Hobbs
>>
>> --
>> Dr Philip C D Hobbs
>> Principal
>> ElectroOptical Innovations
>> 55 Orchard Rd
>> Briarcliff Manor NY 10510
>> 845-480-2058
>> hobbs at electrooptical dot net
>> http://electrooptical.net
>
>I haven t looked at the data sheet, but you might look at the related
>function of the registers.
>MicroChip likes to hide info for switches elsewhere in the data sheet.
>Like the default state of some digital/analog pins, is actually analog
>not a digital input. The bit for this is listed on the ADC section not
>the digital Port bit section (16F877).
>
>
>Cheers

In fairness to them, it gets pretty complicated, and they do generally
list all the registers that can affect a given port pin in the
relevant port pin section. It's just explained elsewhere. So make sure
you understand the potential effect of every single non-grayed-out bit
of every one of those registers, even if there seems to be an awful
lot of them.


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff(a)interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
From: Phil Hobbs on
On 2/6/2010 9:56 AM, Martin Riddle wrote:
> "Phil Hobbs"<pcdhSpamMeSenseless(a)electrooptical.net> wrote in message
> news:4B6BA5B4.2000806(a)electrooptical.net...
>> Okay, so I'm trying to resurrect my long-deceased PIC skills. (I do a
>> lot of C++ programming, off and on, but my last significant firmware
>> was about 2000--the Footprints sensor, running on a PIC17C456.)
>>
>> From last time, I remember that MCU programming is all about getting
>> the configuration bits right--once that's done, it's pretty simple.
>> Sooo, I'm trying something fairly simple to start with, namely
>> controlling an RC airplane servo.
>>
>> The servo needs 0.8-2.4 ms pulses, at a rep rate between 50 and 100
>> Hz. I'm using a PIC 18F46k20 demo board with a nice little OLED
>> display, running at a clock frequency of 64 MHz (16 MHz instruction
>> clock). The PWM is done with Timer 2 and capture/PWM module ECCP 1.
>>
>> I started with demo program, which ran fine. Next I ported that to
>> Hi-Tech C, which I remember very fondly from back when--it was pretty
>> nearly bug-free, in stark contrast to Microchip's C17, which stank on
>> ice. So far, so good.
>>
>> I got the PWM working OK, but with a 64 MHz clock, the slowest rate
>> the PWM can go is 4 kHz (10-bit resolution and 16x prescaler), which
>> is too quick for the servos. Sooo, I used the TMR2 interrupt handler
>> to implement a divide-by-64 counter. For N+M/1024 cycles, it turns ON
>> the RD5 output when the down-count reaches N, and then switches to the
>> PWM for cycle 0 only. That way, I could have N complete cycles and
>> M/1024 partial cycles, yielding 15 bits resolution at a 61 Hz rep
>> rate. Plenty good for an RC servo.
>>
>> However....
>>
>> The 15 bits are made up of the number of full cycles (5 bits), bits 4
>> and 5 of the CCP1CON register, plus an 8-bit value in CCP1L.
>> According to the datasheet, any time I'm using x256 division in TMR2,
>> I should be getting 10 bits worth of resolution, but it's acting
>> exactly as though I
>> were getting only 8--changing the programmed delay produces 4 times
>> more PWM duty cycle change than it should, and the two CCP1CON bits
>> don't seem to do anything, though I can read and write them correctly.
>>
>> The setup values are:
>> T2CKPS0 = 0;
>> T2CKPS1 = 1; //prescale by 16
>> PR2 = 0xFF; // divide by 256
>> DC1B1:DC1B0:CCPR1L = many values
>>
>> This is almost certainly pilot error, but the reason doesn't exactly
>> leap out of the 450-page datasheet.
>>
>> C'mon, all you PIC guys--what gives?
>>
>> Thanks
>>
>> Phil Hobbs
>>
>> --
>> Dr Philip C D Hobbs
>> Principal
>> ElectroOptical Innovations
>> 55 Orchard Rd
>> Briarcliff Manor NY 10510
>> 845-480-2058
>> hobbs at electrooptical dot net
>> http://electrooptical.net
>
> I haven t looked at the data sheet, but you might look at the related
> function of the registers.
> MicroChip likes to hide info for switches elsewhere in the data sheet.
> Like the default state of some digital/analog pins, is actually analog
> not a digital input. The bit for this is listed on the ADC section not
> the digital Port bit section (16F877).
>
>
> Cheers
>


Nah, I just found it--pilot error, as I thought, and about as stupid in
retrospect as most cases of pilot error. I was using the CCP1CON bits
as MSBs instead of LSBs, and the poor choice of increment (0xFF) didn't
show it up easily. Amazing how you can stare at something for a long
time and not see it--hopefully this will get rarer as I get less rusty.

Thanks for the heads-up though.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net
From: Nobody on
On Sat, 06 Feb 2010 09:56:47 -0500, Martin Riddle wrote:

> Like the default state of some digital/analog pins, is actually analog
> not a digital input.

Any pin which can be used as an ADC input is configured as analogue at
startup, and has to be explicitly set as digital. Apparently, digital
inputs don't like being held at an intermediate voltage, so analogue is
the "safe" option for pins which can be used as either.

From: Spehro Pefhany on
On Sun, 07 Feb 2010 06:03:59 +0000, the renowned Nobody
<nobody(a)nowhere.com> wrote:

>On Sat, 06 Feb 2010 09:56:47 -0500, Martin Riddle wrote:
>
>> Like the default state of some digital/analog pins, is actually analog
>> not a digital input.
>
>Any pin which can be used as an ADC input is configured as analogue at
>startup, and has to be explicitly set as digital. Apparently, digital
>inputs don't like being held at an intermediate voltage, so analogue is
>the "safe" option for pins which can be used as either.

Not just ADC inputs but also other analog functions such as comparator
inputs etc.


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff(a)interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com