[CCC DEV] Duhhhh! - problem with my servo fix.
Steve Pretty
steve.g.pretty at btinternet.com
Mon Jan 31 22:57:08 GMT 2011
Isn't it always the way - you put the PC to bed for the night - and
suddenly realize a flaw in your thinking.
The problem is that Timer 1 has two output compare registers and drives
2 PWM16 or servo ports.
What happens if I want to use both pins associated with Timer 1?
Looking at control port TCCRnB, the same values will be written to this
register when each of the two pins is started (as pwm16 or servo) - so
my fix is good. For TCCRnA, the same value is written for the lower
nibble - but there is an issue for the top nibble. Bits 6 and 7 deal
specifically with the operating mode of OCRnA and bits 5 and 4 deal with
OCRnB. So for those bits, my fix is bad.
What is needed is code that will set the lower nibble, set the two bits
of for the OCRnx that we are configuring correctly (not but ORing, as
the required value is 1 0) while preserving the state of the other two
OCR1 bits.
I am still thinking about the best way to handle this. Right now, I
think, that the pwm8.lookup and pwm.16.lookup routines will have to
return an extra result - call it TCCRnA.mask. This will either contain
#C0 or #30, as a mask to preserve the OCR configuration bits we are not
configuring - so the code that would have in pwmx.setup is:
ports[TCCRnA] := (ports[TCCRnA] /\ TCCRnA.mask) \/ TCCRnA.bits
The trouble is that the pwmx.setup routines do not "know" if they are
configuring the A or B channel.
I do have some misgivings about relying on an I/O configuration port as
a safe repository for state information! Probably just as many
misgivings about holding such state information in a global variable!
What do you think?
Steve
More information about the developers
mailing list