review of timing details

I set up a couple more hardware flags on my software so I could see things like, edge detections vs rollover detections vs PC transmissions, etc. It all looks perfect to me. I took maybe a dozen different samples, looking for problems, and everything lines up well. Edges are detected where they should be, high’s are detected properly, transmissions happen every 8 bits, etc.

I also manually counted cycles for both the ISR and the main routine, and made sure that I wasn’t exceeding the number of cycles in the ISR. I also checked to see if the ISR is starving main, it’s not — main is soo tiny, it only takes at most 200-300 ns to process the “send” which is really all main does.

I did find one problem. I noticed that the number of stored bits BEFORE I reached the PC send routine was reaching exactly 9 bits(never 10 or greater) for some reason. I also checked to see if an edge or a HIGH was consistently triggering causing the shift register to overflow. I found that an edge-trigger is consistently overflowing it, and that a HIGH never caused it to overflow.

This means I’m losing one bit on a regular basis — the lost bit just gets shifted off the left hand side. I made a correction by forcing a PC xfer IN THE ISR right before the 9th bit gets added. Normally main handles the PC comm. This did fix the problem I was seeing, but it really did not improve the results at all. I was hoping that would be the “big problem”. I want to narrow down WHY that was happening though, and see if that sheds light. It has something to do with the timing of an edge vs the transmission.

I guess the problem I’m having now is that everything looks kosher. I want to put up some more timing images showing just how well it looks like its working.

Onward and forward.


Amateur Electronics Design Engineer and Hacker

1 comment

  • Can you sort of post a sketch or something like scan of a handdrawn block algorithm of your code? This sometimes helps me – you know, drawing all these circles, blocks and arrows.