Quote:
Originally Posted by Ether
It sounds like you are setting one pin high "at the start of our loop" and you are toggling a second pin at the start of the same loop. Am I reading that correctly? If so, couldn't you trigger the scope on the rising edge of pin1, measure the periodic rate as the distance between pin1 rising edges, and measure the loop run time as the distance between pin1 rising and falling edges?
|
Yes, you are correct. That is what we are doing. Yes, the periodic rate could be measured that way, when all is well and working correctly. We did this 3 years ago when this was all very new. Our periodic rate was set much faster and we were attempting to transfer much more data. So, our code run time was longer than the periodic rate. We were in trouble shooting mode. When we finally realized the code was taking longer than the period things started to make sense. I just like the redundancy of measuring them independently so we still do it that way. Seeing both signals on the scope is a good visual confidence monitor.
Quote:
Originally Posted by Ether
In the blocked waiting state, the thread releases the CPU so other threads can run. So if it's blocked waiting, would it be possible to put the CAN data gathering in a separate 200ms thread so you wouldn't have to multiplex it?
|
We are planning to try a scheme like that this year.
-Hugh