What is it that can cause scheduling issues on a microcontroller?

[mstacho]

This is probably a very specific post, but here's the deal:

I want to read 7 encoders using webbotlib on my Axon.  I've been told that this might cause scheduling issues, where (I presume) this means that with so many encoders running on interrupts, it's possible that two or more encoders will try to trigger an interrupt at the same time, and some of the data gets lost (am I right so far?)

So...what is it that causes these issues?  Is it the encoders themselves (which implies that no matter which uC I use I'll still run into the issues) or is it something to do with the uC (which implies that if I use a faster/better one I can get around the issues)?

Now, I'm aware that I can probably just hook up all my encoders and see what happens, but the robot is still being built so I'm not at that stage.  Plus I'd rather not run into the issues in the first place, so if I can avoid them somehow it'd be great to know.

Anyone have any thoughts?

MIKE

[garrettg84]

I would assume that it might be an issue of speed for the uC itself. What sampling rate are your encoders to run at? Most common (read: cheap) sensors and encoders only update a maximum of a few hundred times a second,  and some less times than that. If this is the case, you likely won't have an issue unless you are actively processing on the interrupt instead of just gathering data on the interrupt and throwing it into a buffer of some sort for later processing.

If this does turn out to be an issue, it may be in your interest to use a few smaller uCs and 'network' them together gathering data and then use a single uC to do the crunching.

What are the encoder specs?

[Kylepowers]

The other idea you could use Is a cascade inturupts. So you could set the system to look at each encoder at a certain time. The loop it so the system we update in an order you also could do this in groups aswell.

[mstacho]

I'm not sure of the sampling time of my encoders, but they are 1360 pulses per revolution.  With the motors running at max. 2rpm, we're looking at a maximum of 2720 pulses per second per encoder.  At 7 encoders, that'll be a max. of 21000 pulses per second (plus some for added room).  I wonder if that's a lot?

I was thinking about the networking of multiple uCs together, and it may come to that eventually.  I guess the only thing to do now is make the robot and see what happens :-)

MIKE

[garrettg84]

With the way you have described this, it seems like you could use the pulsein function. It wont really matter the frequency on any of the encoders. It would measure the time between peaks, from that you could determine speed from each increment and make a decision as fast as you'd like.

What functionality will these encoders provided? What time space do you expect to ( are you ABLE to ) respond to a change in rate?

[mstacho]

The encoders are supposed to be telling me position for the fingers in a hand.  Before, I was using 8-bit potentiometers (Um...pots hooked up to an 8 bit ADC).  I'm only changing to encoders because the pots were never as reliable as I wanted, so really the number of pulses/rev can be quite low.  I might actually take some of the magnets out of the encoders to reduce the number if I DO end up getting scheduling issues.  We're basically doing the assembly of the first prototype  tomorrow, so in the next few days I should know.

MIKE

[Webbot]

I'm not sure of the sampling time of my encoders, but they are 1360 pulses per revolution.  With the motors running at max. 2rpm, we're looking at a maximum of 2720 pulses per second per encoder.  At 7 encoders, that'll be a max. of 21000 pulses per second (plus some for added room).  I wonder if that's a lot?

I was thinking about the networking of multiple uCs together, and it may come to that eventually.  I guess the only thing to do now is make the robot and see what happens :-)

MIKE

WebbotLib has two encoder implementations:
Fast Quadrature use the (rare) INT pins - quick to process but not many of them - see metrics at http://webbot.org.uk/WebbotLibDocs/39894.html. Can cope with a total of 144,000 ticks per second.
Quadrature uses Pin Change interrupts - slower to process but more of them - see metrics at http://webbot.org.uk/WebbotLibDocs/34557.html. Can cope with a total of 32,000 ticks per second.

According to your previous post then your 7 encoders should only emit a max of 21,000. So either method should work. Guess you wont have enough INT pins for the Fast Quadrature method - which is a shame.
Using the Quadrature approach then you will probably spend 66% of your CPU time just processing encoder interrupts.

[mstacho]

So could I then use as many of these fast interrupt pins as I have available for some encoders and put the rest on the regular pins?  Does the Axon have any such fast interrupt pins available?

MIKE

[Webbot]

So could I then use as many of these fast interrupt pins as I have available for some encoders and put the rest on the regular pins?  Does the Axon have any such fast interrupt pins available?

MIKE

Yes - you can mix'n'match. As for finding out what pins to choose from then I suggest you use my Project Designer from webbot.org.uk as it will show you what pins you can choose from.