I know I’ve been bad keeping you guys updated….. This doesn’t mean I haven’t been working on it, however.
I recoded the ISR completely in assembly because I was just plain sick of the damn mandatory 27 cycles worth of instructions that SX/B forces on you. I also recoded things so the very first instruction is the debug pin, so I can clearly now see that the SX is reacting quickly to the edges.
Because I’ve recoded the routines, they are both very streamlined, but about the same size, this means that telling an edge from a high isn’t easily done….. I don’t care because I think I’m getting this part right anyways.
I did change the way I detect an edge — I now look at the RTCC value to determine whether its a rollover or an edge. If its a rollover, the value is ALWAYS 3, or in my case 4, because I store it in another variable. Anything else (and I can add tolerance to this of course) is an edge.
I have more whole ISR down to approximately 580ns total. Much better than the 900 or 1000ns I was seeing before.
Even with this recode, it still appears that for whatever reason, that main isn’t running after the 8th high, and before the edge which would make up the 9th bit. I really can’t figure this out. And the RTCC gets reloaded, so using that to tell the real time between events might be tough, but I might be able to adjust for it.
Before I recoded, the problem “edges” always occurred whenever the RTCC showed a value of 206-219. Any value 221 and up were good edges that main took care of xfering beforehand….. The numbers have changed because ISR is more efficient, but the problem still shows up.
I still don’t know wtf main is not sending the byte before processedge in the ISR runs again.