WAITPEQ timing & RESET behaviour questions...
Bill Henning
Posts: 6,445
Hi,
A) WAITPEQ question
The manual shows WAITPEQ to take 5+ cycles.
I interpret the documentation as follows:
1. If the bit you are looking for is already set, WAITPEQ will take 5 clock cycles to execute
2.·If the bit is not set, the instruction following the WAITPEQ will start executing one clock cycle after a bit you are waiting for goes high
(assuming 80MHz clock) This implies that say if I was watching p0, and it went high 5 ns after WAITPEQ was executed, the instruction following would get executed six cycles after the WAITPEQ started executing... And if it went high 37.5ns after WAITPEQ started, it would be 8 or 9 cycles... See, I am trying to figure out what "jitter" I need to allow for.
RESET behaviour question
If RESET is held low, what state are the port pins in?
1) Are they left floating (essentially tri-stated)?
2) Do they default to "input" mode? (while in RESET)
3) Do they default to "output" mode? (while in RESET)
THANKS!
Bill
p.s.
Why am I being so picky? I need to know...·the questions are·related to a large model project [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
A) WAITPEQ question
The manual shows WAITPEQ to take 5+ cycles.
I interpret the documentation as follows:
1. If the bit you are looking for is already set, WAITPEQ will take 5 clock cycles to execute
2.·If the bit is not set, the instruction following the WAITPEQ will start executing one clock cycle after a bit you are waiting for goes high
(assuming 80MHz clock) This implies that say if I was watching p0, and it went high 5 ns after WAITPEQ was executed, the instruction following would get executed six cycles after the WAITPEQ started executing... And if it went high 37.5ns after WAITPEQ started, it would be 8 or 9 cycles... See, I am trying to figure out what "jitter" I need to allow for.
RESET behaviour questionIf RESET is held low, what state are the port pins in?
1) Are they left floating (essentially tri-stated)?
2) Do they default to "input" mode? (while in RESET)
3) Do they default to "output" mode? (while in RESET)
THANKS!
Bill
p.s.
Why am I being so picky? I need to know...·the questions are·related to a large model project [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
From the pin descriptions: RESn I/O Reset (active low). When low, resets the Propeller chip: all cogs disabled and I/O pins floating. Propeller restarts 50 ms after RESn transitions from low to high.
A)
There is a comment from Chip on this question in this thread:
http://forums.parallax.com/showthread.php?p=585182
0) read source N
1) read destination N
2) read instruction N+1
x) any wait cycles go here (0...infinity clocks) ' <----my question: should this be 1...infinity?
3) write destination N (N=N+1, goto 0)
The instruction table does say 5 wait states in the WAITxxx command. That would seem to make at least one wait cycle mandatory?
You suggest, "if it went high 37.5ns after WAITPEQ started, it would be 8 or 9 cycles". I don't think so. 37.5 ns would mean the pin is high at the beginning of the first (mandatory) wait state, so the next (0) read source state would start 25 ns later. That is at exactly the same time it would happen if the input pulse had occured earlier in the execution of the WAITPxx command. It seems to me, there is not much jitter to account for in the execution stream, so long as the input happens before or coincident with the start of the (x) state.
Peter (pvj) has noted empirically that the input pulse must indeed be on the order of 12.5 ns long (= master clock period), or else there is a possibility it will be missed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Thank you!
I forgot about the pin description... that does tell me what I need - if I hold the prop in reset, it sounds like it will be safe for me to reprogram the eeprom w/o using the prop to do it [noparse]:)[/noparse]
And I missed chips posting, however despite your kind post, I am still not 100% certain of the timing... I am attaching a simple diagram to clarify my reading of the description of WAITPEQ
The diagram shows the 5 cycles minimum execution time of WAITPEQ, with a monitored signal going high shortly after the five complete cycles... if my understanding is correct, the wait will "expire" the next complete clock after the signal goes high, and therefore MOV will start to be executed (in this case) 6 cycles after WAITPNE starts executing.
12.5ns minimum detectable pulse width makes perfect sense with the 80MHz master clock [noparse]:)[/noparse]
I wish I had more time to work on the propeller... but I won't until end of March [noparse]:([/noparse]
Best,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
One other thing that's unknown until the datasheet comes out is the setup time for the pin input relative to the clock. That will determine where in your diagram the transistion can take place before its recognition gets bumped to the next clock cycle.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.