Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 6 months ago.
When using multiple Ticker instances, can we not mix attach and attach_us ?
I have five Ticker instances, all with attach (milliseconds) . I need finer resolution on one of them, so I decided to use attach_us and now they all fail....
The ONLY thing I'm doing inside the attach_us routine is updating a volatile counter that is referenced outside of the ISR.
Thoughts?
1 Answer
8 years, 6 months ago.
All the ticker attach function does is call attach_us with the time multiplied by 1,000,000
Other than the time taken to do a floating point multiply attach and attach_us are identical.
void attach(void (*fptr)(void), float t) { attach_us(fptr, t * 1000000.0f); } template<typename T> void attach(T* tptr, void (T::*mptr)(void), float t) { attach_us(tptr, mptr, t * 1000000.0f); }
How many microseconds do you use?
And second question is: Why do you need that? (Since it does not work you probably need to search for a plan B ;) ).
posted by Erik - 31 May 2016I'm running PID control and path planning for two DC servo motors. I was planning on running the loop at 100khz (10us) ... the other processes are all 20-100ms.
posted by Michael Ball 01 Jun 2016I can't answer anymore since you marked it as solved, but your issue is simply that the sum of the ARM interrupt architecture + mbed library overhead + your code is more than 10us. But why are you updating that volatile counter every 10us?
posted by Erik - 01 Jun 2016Thank you for your feedback Erik, and for making me thing deeper/differently on this problem.
The primary process - the actual motion control - is free wheeling at whatever speed it can loop in main. It checks to counter at various times to synchronize certain sub processes. A 100khz counter is about the resolution I was hoping for. The CPU runs at 120Mhz, so this should be a trivial counter speed. I've put some code in to toggle unused GPIO pins during the motion control process, so I can visually see what's going on.
posted by Michael Ball 01 Jun 2016Wouldn't just reading a Timer (or us_ticker_read()) be easier? Then you got it in 32-bit with 1000kHz resolution, and except the reading part no overhead (especially if you use us_ticker_read()).
posted by Erik - 01 Jun 2016Truthfully, I was unaware of us_ticker_read(), and just re-using what I "know" to work. LOL I'll try it. THX.
For the record: The problem was user error... I had a errant "printf" statement buried in code that was intended for debug. It messed with the timer interrupt... removed it,and we are happy again.
Appreciated Erik.
posted by Michael Ball 01 Jun 2016