@evanh said:
Some things are in a defined start state, others are not. That's one that isn't.
You see it not defined, I see it defined except one case... point of view, i guess.
The SEx event flags initial state are explicitly not defined by the fact that a SETSEx used with a different mode is guaranteed not to clear the event flag. That means the flag is not defined, just like uninitialised RAM.
But it doesn't have to clear the event... it is the first time it is used, there aren't events to clear... and in fact the events are all cleared except one!
I'm talking generally. The Cordic is a clear easy to understand example of concurrency that can still get into a jumbled sequence. The event system is more open and therefore more prone to such issues, whether by in sequence bugs or just not fully initialising it.
So, you are saying that before using cordic I sould always call getqx/getqy to be sure there are no phantom results in the queue ? One time is enough or should I call it a couple tens of times ? Maybe I can use pollmq to be sure... oh wait, but the event may be in an undetermined state, so I should clear that event as well... but the cordic may be in a undertermined state, how do I know when the state is finally determined ?
Yes, I'm joking... a bit...
The SEx event flags initial state are explicitly not defined by the fact that a SETSEx used with a different mode is guaranteed not to clear the event flag. That means the flag is not defined, just like uninitialised RAM.
But it doesn't have to clear the event... it is the first time it is used, there aren't events to clear... and in fact the events are all cleared except one!
Incidently.
But they're all undefined. That means your software should explicitly clear any SEx flag before use.
I'm talking generally. The Cordic is a clear easy to understand example of concurrency that can still get into a jumbled sequence. The event system is more open and therefore more prone to such issues, whether by in sequence bugs or just not fully initialising it.
So, you are saying that before using cordic I sould always call getqx/getqy to be sure there are no phantom results in the queue ? One time is enough or should I call it a couple tens of times ? Maybe I can use pollmq to be sure... oh wait, but the event may be in an undetermined state, so I should clear that event as well... but the cordic may be in a undertermined state, how do I know when the state is finally determined ?
Yes, I'm joking... a bit...
You have no initial state at all. A P2 started with a boot code, loaded the program from the flash and then executed. I don't know what the bootcode and flash loader does, but it can use se1 and left it in another state than the rest of them. That's why you can have different behavior only in se1 and only in cog0
Here's a snippet from some old library code where I wanted to use the Cordic and didn't trust its state at that time. The code flushes the pipeline while waiting for the result.
emitclkfrq
qdiv clk_freq, ##1_000_000
pollqmt 'clear old event
.flushloop
getqx pa 'MHz whole number - at final pipeline result
jnqmt #.flushloop 'loop until Cordic pipeline is empty, results are in
...
EDIT: Here's the remainder of this routine. As well using the Cordic itself, it also calls itod which uses the Cordic too and finally calls putch while waiting for the last result. I remember I wanted to make sure it didn't get jumbled. The check at the start was partly a peace of mind thing.
getqy temp2 'remainder - six decimal places
call #itod 'uses cordic!
qdiv temp2, #100 'remove least two digits
mov temp2, bcdlen 'preserve bcdlen
callpb #".", #putch
mov bcdlen, #$104 'format to four decimal places with leading zeros
getqx pa
call #itod 'uses cordic!
_ret_ mov bcdlen, temp2 'restore bcdlen
Comments
But it doesn't have to clear the event... it is the first time it is used, there aren't events to clear... and in fact the events are all cleared except one!
So, you are saying that before using cordic I sould always call getqx/getqy to be sure there are no phantom results in the queue ? One time is enough or should I call it a couple tens of times ? Maybe I can use pollmq to be sure... oh wait, but the event may be in an undetermined state, so I should clear that event as well... but the cordic may be in a undertermined state, how do I know when the state is finally determined ?
Yes, I'm joking... a bit...
I think we can stop here.
Incidently.
But they're all undefined. That means your software should explicitly clear any SEx flag before use.
You aren't wrong about the complexity there.
You have no initial state at all. A P2 started with a boot code, loaded the program from the flash and then executed. I don't know what the bootcode and flash loader does, but it can use se1 and left it in another state than the rest of them. That's why you can have different behavior only in se1 and only in cog0
Here's a snippet from some old library code where I wanted to use the Cordic and didn't trust its state at that time. The code flushes the pipeline while waiting for the result.
emitclkfrq qdiv clk_freq, ##1_000_000 pollqmt 'clear old event .flushloop getqx pa 'MHz whole number - at final pipeline result jnqmt #.flushloop 'loop until Cordic pipeline is empty, results are in ...EDIT: Here's the remainder of this routine. As well using the Cordic itself, it also calls
itodwhich uses the Cordic too and finally callsputchwhile waiting for the last result. I remember I wanted to make sure it didn't get jumbled. The check at the start was partly a peace of mind thing.getqy temp2 'remainder - six decimal places call #itod 'uses cordic! qdiv temp2, #100 'remove least two digits mov temp2, bcdlen 'preserve bcdlen callpb #".", #putch mov bcdlen, #$104 'format to four decimal places with leading zeros getqx pa call #itod 'uses cordic! _ret_ mov bcdlen, temp2 'restore bcdlen