Prop-2 %10000 "Time A-Input States" How does IN get reset?
JonTitus
Posts: 193
in Propeller 2
I drew the attached diagram to show what I think happens in the %10000 Time A-Input States mode. If software doesn't read the newest data with an RDPIN or RQPIN instruction, what resets the raised IN flag? And when would it get reset? It would seem to remain raised if software doesn't capture the data. Cheers. --Jon
Comments
From the docs.
Yes, but the captured totals are latched, so you have a full measurement cycle to respond.
It's the same as any capture peripheral - if you are too slow in reading it, you may miss a N captures, but eventually read N+1 capture will be of a whole measurement cycle.
If that possible missing was a problem, you could configure another pin cell to count measurement cycles, and read that too. If that was ever >1, it shows you missed reading one.
IN could be tied to an interrupt if you want.
Then save the actual time-tick, and subtract the older one, before replacing the older with the new one, to be ready for subtraction, at the next capture of IN.
This way, you can have a reasonable guess about if your routine did lost any measurements, or not.
Both CT and the states counter evolve at the same rate (Sysclk), thus it'll be easy to spot any abnormal evolution at the value of Z. Also remember; the value of Z is limited to 80000000 counts, by design.
What happens if an input is constantly held as a logic-1 or a logic-0? Does the Z register indicate an overflow? --Jon
The counter saturates, at $80000000, but has no overflow flag as such.
The capture/transfer of that counter to the visible Z, occurs on the capture condition - here it is a state change. So no-state-change means no transfer.
If reading of captures is too slow, the latest capture overwrites the un-read one, but has no error flag showing over-run.
For teaching ports, it may be useful to have a simple dumper that stimulates pins at ~ 1 second rates (maybe pins 56,57.. on the LEDs on EVAL ?), and reports Smart Pin flags and pin states at maybe 100ms rates.
That would let users see how each mode totals/captures/overflows etc
If the software doesn't read the measurement from Z in a timely manner then it will be lost when overwritten by the subsequent measurement. IN also stays high for these cases, ie: IN lowers when the measurement is read with RDPIN.