View previous topic :: View next topic |
Author |
Message |
Ttelmah
Joined: 11 Mar 2010 Posts: 19535
|
|
Posted: Thu Mar 21, 2019 1:38 pm |
|
|
I don't think #zero ram will affect this. It'll be the value actually in the
SFR that causes this, and zero ram doesn't affect the SFR's.
If you look at the SFR definitions in the data sheet for the duty cycle
it shows R/W-x for each bit, which says this is readable/writable, and
wakes up in an 'unknown' state. |
|
|
avatarengineer
Joined: 13 May 2013 Posts: 51 Location: Arizona
|
|
Posted: Thu Mar 21, 2019 2:06 pm |
|
|
The odd thing is that a command to change the duty doesn't work properly if the duty wasn't initially specified in the #use statement.
I have found in the past a number of bugs with MicroChips that the DEFAULT conditions are not reliable.
i.e. ALWAYS specify ADC=n bits in the main header as the default will not always occur. I escalated that to MicroChip corporate and discussed this for months with their technical experts who were clueless. Some chips work, others do not.
This duty cycle issue smells the same and CCS may not be aware of the "personality" these peripherals have.
|
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9241 Location: Greensville,Ontario
|
|
Posted: Thu Mar 21, 2019 4:07 pm |
|
|
One should never, ever trust 'default' conditions or setups. It boils down to a personal preference as to what a condition 'should be'.
For me I'd prefer all I/O pins to default to regular I/O, set as inputs, however a lot of PICS with ADC or Comparators default to Analog functions.
I know have a 'fuse' header file that I #include. Each fuse is on ONE line, with a comment as to what it does (and why...). This not only saves me a lot of typing (and retyping as I can't type, bum finger) but it also 'cleans up' the main program. It also reduces problems if I relied on another programmer's idea of 'defaults'.
As was pointed out, 'duty' is actually part of an SFR, so it should be initialized, to a 'safe' value. That you'll have to decide !!
Yeesh, WHO dreamed up the COG ?!! 39 PAGES and 2 dozen registers JUST for the COG !!! Someone could spend a lifetime trying to figure out how to operate this peripheral and write a book about it !! It actually looks far more complicated than the 16C84. I'd be curious to know if anyone has used it in a 'real World' application.
Jay |
|
|
avatarengineer
Joined: 13 May 2013 Posts: 51 Location: Arizona
|
|
Posted: Fri Mar 22, 2019 10:47 am |
|
|
I agree, never trust defaults.
My list of #Defines get so nested sometimes, I
think I'm programming in Forth.
I agree, the COG is somewhat complicated to apply,
but MicroChip doesn't have power conversion experts
explaining how the hardware should be designed.
With 8/10/16bit PWMs each with different functionality,
Power PWMs for motor control, PSMC as another flavor,
Enhanced PWM, then COGs, ... it's obvious there isn't
a fixed intelligence directing the peripherals design.
MicroChip is relying on their "Harmony" interface to
fix its utility, but that platform is a disaster and everyone at
MicroChip knows it.
I'll stick with CCS and if need be use inline assembly. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19535
|
|
Posted: Fri Mar 22, 2019 2:52 pm |
|
|
I don't think your issue is with the CCS setups. You've managed to get
the COG working with these, just not doing what you want.
Now I have used the COG, but it was on a different chip.
Key things are:
Using the COG just to give an invert, will generate one master oscillator
clock cycle of delay on the inverted edges. Unavoidable. This is why
I suggested using the PUSH_PULL mode.
As I understand it you have got this mode working, the only issue is
that you are having to get two extra output signals from the PWM
itself?.
The reason for this, is that you are using #USE PWM. Don't.
#USE PWM, _assumes_ you want to generate a PWM output and
won't setup the PWM without output pins. The whole point is that
to use the COG, you want the PWM setup _without an output pin_.
This is done how I showed in my PWM setup. Use the manual setup
and you have proper control of the PWM, and don't need to select
output pins.... |
|
|
avatarengineer
Joined: 13 May 2013 Posts: 51 Location: Arizona
|
|
Posted: Sat Mar 23, 2019 11:00 am |
|
|
Thanks Ttelmah, but I haven't got that method to work.... yet.
It seems the 16F1769 has a personality and may require
something else in setups, some bit in the register to see the
PWM as input.
So far, if I don't set an output for the PWMs, the COG doesn't work.
Also, the push-pull setup doesn't allow me to get overlap, but
the inverted half-bridge does. That's just a distinction between modes
that MicroChip thinks is an industry norm. Although I'm a gold partner,
they don't take my advice of 40 years experience.
|
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9241 Location: Greensville,Ontario
|
|
Posted: Sat Mar 23, 2019 3:23 pm |
|
|
re:
Quote: | they don't take my advice of 40 years experience. |
That's cause you're too OLD !!!
Then youngins probably have never ever seen a real hardcopy databook or programmed a PIC to talk to a Teletype to punch paper tape !!
After all they 'know-it-all'....
I did have one engineer there modify MPLAB so that I could change the default from 'debug' to 'release', though he couldn't understand why, even after I told him I 'debug' in the Real World as NO simulator can simulate the Real World.
Jay |
|
|
avatarengineer
Joined: 13 May 2013 Posts: 51 Location: Arizona
|
|
Posted: Sat Mar 23, 2019 4:11 pm |
|
|
Old is relative.
40's years an EE, but have been programmer since 1970.
I prefer "Seasoned"... in many areas.
|
|
|
newguy
Joined: 24 Jun 2004 Posts: 1908
|
|
Posted: Sat Mar 23, 2019 5:47 pm |
|
|
avatarengineer wrote: | I prefer "Seasoned"... in many areas. |
...salty.
|
|
|
|