PASM-Counter Issue
Wurlitzer
Posts: 237
I have set Cntr A's register to:
(note I have played with the Pin# in case I have screwed up on pin assignment)
My intent is to have the counter reset to zero and stopped when P15 (starting from P0) goes below %50 Vcc.
I have an inductor discharging a capacitor on P15 and the waveform is perfect. It slopes from 3.0 volts to 0 volts with every event. (each event is ~~50 micro seconds) The 50% level looks like it is hit 25 micro seconds after the counter is reset.
The decay time from 3.0 volts to 50% lengthens as the inductance increases.
However, the value returned from the counter A is always the same regardless of slope or if P15 is just held high or held low. Right now it is always 4015.
It appears that it is just returning a value based upon when I look at it in code and not a function of P15.
If I change the interval at which I reset then copy the counter value, that value does change but always remains the same regardless of the slope on P15
My question is given the counter register configuration above should I be able to vary the counter value base on the time required to drop below 50% of Vcc?
I use the following to capture the value of the counter after what "SHOULD" be sufficient time for the counter to stop counting.
CntrA_Cfg long %0_01000_000_00000000_000000_000_01111
...
mov ctra, CntrA_Cfg
(note I have played with the Pin# in case I have screwed up on pin assignment)
My intent is to have the counter reset to zero and stopped when P15 (starting from P0) goes below %50 Vcc.
I have an inductor discharging a capacitor on P15 and the waveform is perfect. It slopes from 3.0 volts to 0 volts with every event. (each event is ~~50 micro seconds) The 50% level looks like it is hit 25 micro seconds after the counter is reset.
The decay time from 3.0 volts to 50% lengthens as the inductance increases.
However, the value returned from the counter A is always the same regardless of slope or if P15 is just held high or held low. Right now it is always 4015.
It appears that it is just returning a value based upon when I look at it in code and not a function of P15.
If I change the interval at which I reset then copy the counter value, that value does change but always remains the same regardless of the slope on P15
My question is given the counter register configuration above should I be able to vary the counter value base on the time required to drop below 50% of Vcc?
I use the following to capture the value of the counter after what "SHOULD" be sufficient time for the counter to stop counting.
mov InputCount, phsa
Comments
You just need to clear the phsa counter with a mov phsa, #0 instruction and then wait for it to accumulate.
Try studying the below code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
This is how the dira and ctra are set:
EDIT: The 4 "or" statements are the only settings for dira and it is not addressed elsewhere in the program so P15 should be an input
or dira,ClockPin 'p10 or dira,DataPin 'p11 or dira,OutputEnablePin 'p12 or dira,ChargeSenseCapPin 'p13 mov CirQueStartADDR, par mov CirQueWritePtr, par mov CirQueEnd, par add CirQueEnd, #128 'NOTE CHANGE TO ACTUAL mov CirQueStatusADDR,par add CirQueStatusADDR, ReadStatusOS mov ctra, CntrA_Cfg 'pos detection pin 15 for Counter A APIN mov frqa, #1Right as I start the discharge of the capacitor I do a mov phsa, #0
Post Edited (Wurlitzer) : 3/29/2010 5:55:45 PM GMT
I have also changed from CntrA to CntrB with the same results.
I appears the counter will never stop but can be reset.
or dira,ClockPin 'p10 or dira,DataPin 'p11 or dira,OutputEnablePin 'p12 or dira,ChargeSenseCapPin 'p13Are the contents of those addresses actual pin numbers? Or their corresponding masks, i.e.:
ClockPin long 1 << 10-Phil
I set the original value exactly like you have shown.
CntrA_Cfg long %0_01000_000_00000000_000000_000_01111It's easy to overlook but that's not POS detection mode (NCO in fact). What you want is this (note the extra 0 in the right most bit group):
binary long %0_01000_000_00000000_000000_000_001111 again long %0_01000_000 << 23 | 0 << 9 | 15▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 3/30/2010 2:46:35 PM GMT
The entire project works perfect now!
Kye and Phil thanks again also for taking the time to look at this.