[resolved] counter issue
kuroneko
Posts: 3,623
I ran into a minor yet annoying problem when using counters triggered by logical equations (%1xxxx).
I start counter A as 6.25% DUTY (1/16th of CLK) which delivers its output to a pin P. Counter B is programmed as LOGIC A (sampling pin P), so is supposed to increment PHSB every 16th clock cycle (FRQB is 1).
Now, I start counter B and immediately after that set FRQB to 0 which means there is only a very small window to catch an impulse from pin P. Furthermore, I synchronised timings so that the high pulse on pin P should fall on the first cycle of the mov FRQB, #0, which means that in the 2nd cycle (one cycle delay for LOGIC) PHSB should be incremented.
Anyway, what I see is that most of the time I do get the increment in PHSB but sometimes I don't (about 1 out of 20). It could well be that my observations above are slightly off but even then I'd expect consistent behaviour. I see this with download to RAM and running from EEPROM, at all frequencies.
What am I missing here?
TIA
Edit: Seems that the delay was off by one, I still see the same problem (I updated the attachment and the comment above).
These postings are now two years old. Time flies. Anyway, in the meantime I had a chance to test this on different platforms with the same results. I file this under setup race-condition and deal with it accordingly.
Update 20110902: Another - more likely reason - is that because the two counter flip-flops are not reset during hard-reset or cogstop we may catch a stray event with frqx != 0 initialisation. The chips I checked tend to favour an initial high state.
I start counter A as 6.25% DUTY (1/16th of CLK) which delivers its output to a pin P. Counter B is programmed as LOGIC A (sampling pin P), so is supposed to increment PHSB every 16th clock cycle (FRQB is 1).
Now, I start counter B and immediately after that set FRQB to 0 which means there is only a very small window to catch an impulse from pin P. Furthermore, I synchronised timings so that the high pulse on pin P should fall on the first cycle of the mov FRQB, #0, which means that in the 2nd cycle (one cycle delay for LOGIC) PHSB should be incremented.
Anyway, what I see is that most of the time I do get the increment in PHSB but sometimes I don't (about 1 out of 20). It could well be that my observations above are slightly off but even then I'd expect consistent behaviour. I see this with download to RAM and running from EEPROM, at all frequencies.
What am I missing here?
TIA
Edit: Seems that the delay was off by one, I still see the same problem (I updated the attachment and the comment above).
These postings are now two years old. Time flies. Anyway, in the meantime I had a chance to test this on different platforms with the same results. I file this under setup race-condition and deal with it accordingly.
Update 20110902: Another - more likely reason - is that because the two counter flip-flops are not reset during hard-reset or cogstop we may catch a stray event with frqx != 0 initialisation. The chips I checked tend to favour an initial high state.
Comments
Counter A runs with a 6.25% (1/16th CLK) DUTY cycle mode (link pin in the diagram in the source). Somewhere in between two pulses I start counter B and immediately after that I set FRQB to 0 (it's set to 1 initially). Which means I have a 4 cycle window to catch a pulse from the link pin. As the link pin should be 0 during this window, I expect PHSB to be unchanged. However, what I'm experiencing is that in 30 runs I have at least one ghost pulse which causes counter B to be triggered.
I checked the counter application note from the Parallax website and they initialise FRQx only after CTRx but I don't see why it shouldn't work the other way around. The docs don't mandate a fixed order. Even so, my argument/point is that the update enable condition for counter B is false, so there shouldn't be an update at all (unless initialising the counter triggers some race condition in its logic). Also, what if I don't know FRQx's content and don't want it to be used for a different counter setup or it's simply in an unknown state.
The thing is that when I keep FRQB equal to 0 until after CTRB is setup (and then set it to 1), e.g.
it all works nicely. The following sequence works as well:
which was what made me wondering about race conditions in the first place.
The program uses pin 0 for the link pin between counter A and B and the two joystick LED's on the Hydra (5, 6). Counting 0..2 is mapped to 1..2 respectively (bit 0 being the left joypad LED, bit 1 the right).
So my question is why is this happening? Maybe it's my h/w (Hydra, which I assume is OK apart from an inverted debug LED), maybe not ... I checked this at all frequencies from RCSLOW to 80MHz on all 8 cogs and with different link pins. I get always the same unpredictable behaviour.
Post Edited (kuroneko) : 5/25/2008 5:59:42 AM GMT