[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