[invalid][puzzle] Nine Cycles of Hell
kuroneko
Posts: 3,623
Disclaimer: This is more of an anti challenge as it may be impossible to solve, i.e. the result may differ from the set target.
The datasheet notes a 7..22 cycle timing for hub ops. A hub window being 16 cycles results in a nine cycle window before the next hub op can be issued (or rather is processed, 16 - 7 = 9). So let's not waste those nine cycles and fill them with a 4 cycle insn and a 5+ cycle insn of your choice, the latter set to minimum execution time.
With all the measurement going on it seems that everyone is happy with capturing cnt before and after, take the difference and adjust for overhead, e.g.
should clock in with 16 consumed cycles. It's part of the challenge to make sure that the cogid is sync'd to the hub window (and reading mark is aligned accordingly, i.e. hub window - 4).
The datasheet notes a 7..22 cycle timing for hub ops. A hub window being 16 cycles results in a nine cycle window before the next hub op can be issued (or rather is processed, 16 - 7 = 9). So let's not waste those nine cycles and fill them with a 4 cycle insn and a 5+ cycle insn of your choice, the latter set to minimum execution time.
With all the measurement going on it seems that everyone is happy with capturing cnt before and after, take the difference and adjust for overhead, e.g.
neg mark, cnt ... ' instruction(s) to be measured add mark, cnt sub mark, #4What I want is proof that there are nine cycles to spare. Basically, the sequence
neg mark, cnt [COLOR="Red"]cogid cnt ' 7[/COLOR] ... ' 9 cycle consumer add mark, cnt sub mark, #4
should clock in with 16 consumed cycles. It's part of the challenge to make sure that the cogid is sync'd to the hub window (and reading mark is aligned accordingly, i.e. hub window - 4).
Comments
entry mov DIRA, #1 neg tmp, CNT waitpne DIRA, DIRA add tmp, cnt sub tmp, #4 wrlong tmp, PAR cogid tmp cogstop tmp tmp res 1AFAIK the only way to do this is to delay 2 hub cycles and use the waitcnt to do the timing. I am busy with other thinks otherwise I would try.
The timing will be updated in the next revision of the documention along with the actual values for waitpxx/waitcnt and waitvid (6+/4+).
Blimey, no wonder Zog is so slow:)
If you run this code and look at a scope...
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Pasm cognew(@Entry,0) DAT Entry mov dira, #1 Loop mov outa, #1 nop mov outa, #0 jmp #Loop... the HIGH time will be 100ns. However if you run this code ...
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Pasm cognew(@Entry,0) DAT Entry mov dira, #1 Loop mov outa, #1 waitpeq dira,dira mov outa, #0 jmp #Loop... the HIGH time will be 125ns and I think (<-THAT) is where the confusion came from and how it was miscalculated and made it's way into the documentation. Intuitively if you think 100ns for a command that you know to take 4 clocks, and then look at a command that indicates 125ns, then you just assume there is a 5th clock.
What your not considering is the processing overhead time required for making the pin HIGH, and then LOW again. Look at this code ...
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 PUB Pasm cognew(@Entry,0) DAT Entry mov dira, #1 Loop mov outa, #1 mov outa, #0 jmp #Loop... the HIGH time is 50ns. So in the above scenario you should be comparing 50ns and 75ns by subtracting 50ns from your original readings.
50ns = 100ns - 50ns
75ns = 125ns - 50ns
... So if 50ns is equal to 4 clock cycles (12.5ns * 4 = 50ns) then 75ns is equal to 6 clock cycles (12.5ns * 6 = 75ns)
Citation needed?
That's great! Accurate documentation is a must. Thank you for being on the case.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ sio : "FullDuplexSerial" VAR byte time PUB Start sio.start(341, 30, 0, 9600) cognew(@timer, @time) repeat if (time) sio.dec(time) sio.tx(" ") time~ DAT timer mov count,#24 :tloop neg acc,cnt wrbyte dtime,par add acc,cnt sub acc,#4 mov dtime,acc mov acc,cnt add acc,delay waitcnt acc,#0 add delay,#1 djnz count,#:tloop jmp #$ dtime long 0 delay long 80_000_000/10 acc res 1 count res 1and the output:-Phil
Seriously? Don't you think the docs should match reality?
Not everyone has the PASM chops to figure it out for themselves. I for one don't understand what your program does. Care to elucidate, please?
timer mov count,#24 ' Run this 24 times :tloop neg acc,cnt ' Get current counter value, but make it negative num. wrbyte dtime,par ' dtime=0 first time, below we will calc it. ' Write the dtime value to the hub address represented in par ' spin have already reserved it's hub address with '@time' add acc,cnt ' How long did the above hub-op take? sub acc,#4 ' Subtract 4 cycles for overhead mov dtime,acc ' Move the new answer to dtime. mov acc,cnt ' reset acc with current counter value. add acc,delay ' add the delay we want waitcnt acc,#0 ' Wait add delay,#1 ' Next time wait one more cycle and see if our hub window will be at a better or worse position. djnz count,#:tloop ' is 24 loops up yet? jmp #$ ' jmp forever to this same line. dtime long 0 delay long 80_000_000/10 acc res 1 count res 1I think you misunderstood my comment. (In fact, I hadn't read your comment when I posted my code, else I might have phrased mine differently.) Of course, accurate documentation is a must. I was only responding to Kuroneko's statement, "As of today Parallax have officially (enough for me) acknowledged that hub ops take 8..23 cycles..." Some might interpret this to imply that it's not real until Parallax verifies that it's real. What I was trying to get across is this: Always trust your own experience before you trust anything "official".
tonyp12,
Thanks for commenting my code for me. In my haste to post, I left out that important detail. My apologies to the forum.
-Phil
Personally I don't need any official word. But mismatching documentation somehow gets up my nose especially when it's this easy to fix. As for evidence, why would a newcomer to PASM even question the data sheet? Some of us did for their own reasons and as I'm usually a nice person I don't see why other people should find out the hard way (as it's just an irritating distraction).
Don't read too much into it, it wasn't meant in the way you suggested it could be interpreted
@mpark: re: citation, ATM I'm sorting out some other issues with Jeff Martin, he confirmed this in an email and I'm free to spill the beans. That has to be enough for now.
-Phil
Hell, I'm impressed you even got a response. Well done!
I have looked on this datasheet and still see ERRORS.
On page 5 in Schematics I Don't see any decoupling capacitor. In my opinion it is why all NEW user's on PEKit build theirs experiments on breadboard Without that capacitors and in some cases have problems.
Yes - we need BE
That are good to all - Both Parallax and us to have manual that are correct.