View Single Post
  #8   Spotlight this post!  
Unread 11-22-2011, 04:30 PM
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,003
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: [DFTH] We eat what we CAN, and what we can't, we CAN...

Quote:
The toggle is to measure the periodic rate and trigger the scope. The Hi/Low measures our total code run time.
Bear with me? I'm still not clear on this. You said "We monitor the code run time by setting a digital output pin high at the start of our loop, setting it low at the end of the loop and a second pin is a toggle at the start of the loop." (emphasis mine).

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?


Quote:
We call a function to send data. It does not return until the data is sent and the ACK comes back from the CAN bus. I call that blocking because the thread is stopped from running while waiting for the function to return.
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?


Reply With Quote