How to watipeq efficiently with multiple changing inputs
byrtolet
Posts: 22
in Propeller 1
The inputs I wait to wait for change simultaneously and sometimes waitpeq it gives false positives.
How to do what watipeq does, without false positives and with minimum latency on matching inputs?
How to do what watipeq does, without false positives and with minimum latency on matching inputs?
Comments
How fast are the input signals changing? It may be that your inputs are not quite simultaneous due to differences in impedances, capacitance, length of signal lines, etc. If that is the case a second waitpeq may be needed.
For Spin:
((PUB ┆ PRI))
WAITPEQ (State, Mask, Port)
State is the logic state(s) to compare the pin(s) against. It is a 32-bit value that
indicates the high or low states of up to 32 I/O pins. State is compared against either
( INA & Mask), or ( INB & Mask), depending on Port.
Mask is the desired pin(s) to monitor. Mask is a 32-bit value that contains high (1)
bits for every I/O pin that should be monitored; low (0) bits indicate pins that should
be ignored. Mask is bitwised-ANDed with the 32-bit port’s input states and the
resulting value is compared against the entire State value.
Port is a 1-bit value indicating the I/O port to monitor; 0 = Port A, 1 = Port B. Only
Port A exists on current (P8X32A) Propeller chips.
For Assembly:
Instruction: Pause a cog’s execution until I/O pin(s) match designated state(s).
WAITPEQ State, (#) Mask
State (d-field) is the register with the target state(s) to compare against IN x ANDed
with Mask.
Mask (s-field) is the register or a 9-bit literal whose value is bitwise ANDed with IN x
before the comparison with State.
The question is not asked precisely enough to be answered. "I wait to wait" means "I'm am waiting to wait." If you wait, you can not wait to wait and if you are not waiting, you can not wait to wait.
"Simultaneous" is not defined by definition, As two events happen at the same time at the same place establish one event and two events happening at the same time at different points happen at the same time only for an observer while for another observer the same events happen at different times.
If you look for something that does what waitpeg does but without false positives, you look for something that does thing different from waitpeq, as waitpeq creates "false positives" in contrast to what you are looking for.
So this is what is meant when there is the saying: a computer always does, what you say to him, never what you meant to say.
It is not clear precisely what you need to accomplish. An example would help, especially about pulse widths and timings.
Do you need pull-up, pull down?
Is the grounding efficient ?
Is there cross over?
what I need is to wait until particular address is output on the bus.
The problem is that while the bus changes its address, the propeller might sample it right during the transition, giving an input which is not an address actually put by the 6502.
For example on once 6502 cycle one might have 0xffff on the address bus, and on the next 0x0000.
During the transition between the two, propeller might read anything.
What I need is a stable input (at least two consecutive reads to read the same value)
What have at the moment (in c pseudocode)
while(true) { waitpeq(lookfor_addres, address_mask) if ( (INA & address_mask) != lookfor_address)) continue; // react to this particular address }While this works I'm seeking for a solution with lower latency (in my example I have an extra latency of an input read, binary AND, comparison and conditional jump.-Phil
the problem is that the addresses are valid long before phi2 is high, and some time after phi2 becomes low, so just including phi2 in the waitpeq will not do (remember, I need the valid address as soon as possible).
One could wait for phi2 to become high, then wait for it to become low, wait a little and read inputs, but then it still has to do the check if the address is the desired one.
And moreover, after the "react for particular address" part, all that waiting might miss another desired address.
-Phil
Unfortunately I can't afford to waste a cog and beside that, the communication would just add latency.
Phil, I disagree. If you have 1Mhz 6502 & 80 Mhz propeller you have 20 instructions per 6502 clock. If one accesses the hub you have even less. If the Phi2 duty cicle is 50% (which is not in my use case) you have 10 instructions.
I don't have access to the RDY pin.
If you are using a 1MHz 6502, from the Rockwell datasheet you a at most 225ns to wait for the address to be valid, which is less than two instructions of the Propeller at 80MHz. As long as you are only looking for a specific address or well-behaved range of addresses (e.g. $FFF0 to $FFFF), requiring only one or two comparisons, and save any hub access for after the address match you should easily be able perform your matching within 20 instructions.
Another salient point is whether you are simply triggering propeller actions on address matches, or whether you need to interact on the data bus as well.
If the required reaction time includes reading data from or putting data onto the data bus you have around 7 and 4 instructions respectively to do so.
Given that a 6502 can only meaningfully access the data bus for a data transfer every 2 or 3 cycles you have some time to do your hub access during the following 6502 instruction fetches.
If you are trying to have the propeller feed instructions to the 6502 then you really also need control of the 6502 clock to be exercised from the propeller.
I can actually feed 6502 instructions quite reliably (it takes a cog). The problem is that I have ran out of cogs, and in the last cog I must decode 6502 address on 6502's write cycle, and depending of the written bits set two longs in the hub. And beside that, on another address copy the written value. I even have a code that works sometimes, but only sometimes.
No.