Conceptual help using timers to read motor encoders

[rstofer]

There may be an 'oopsie' in trying to use 12 inputs for interrupt-on-change.  There is an absurdity in the way pins are handled by the NVIC:

http://stm32f4-discovery.net/2014/08/stm32f4-external-interrupts-tutorial/

It might be possible to code around it but apparently we can only get individual interrupts on 5 pins and then two pins.

[dannyf]

I said it for the longest time: the eint modules in stm8 and stm32 are designed and approved by morons.

[rstofer]

I said it for the longest time: the eint modules in stm8 and stm32 are designed and approved by morons.

It certainly seems odd...

Nevertheless, we can keep a shadow copy of the previous state of the inputs and when we get an interrupt on one of the multi-input interrupts we can just process all of the changed bits.  Unfortunately, that only accounts for 11 inputs over two interrupts plus another single pin interrupt.  There is also the possibility of a race condition where a pin gets set while we're in the ISR and when we clear the interrupt that waiting interrupt gets cleared as well.  It depends on how they implemented the hardware.

More and more I get back to the idea of a CPLD.  This is just becoming too worrisome.  Not the interrupt technique, I wouldn't trade it for timers, but the implementation on the STM32F4.

[dannyf]

some rough numbers:

20 ticks to process the isr itself is reasonable but let's budget for 80 ticks.

XC8 1.12 free mode, PIC12F675 @ 1MIPS, 2x 1Khz pulse trains (=1 encoder), cpu  load is 25 - 28%. That translates into about 75 ticks per isr invocation, vs. 80 ticks estimated above. (edit: I should add that the implementation processes both edges using IOC interrupts, entirely in the isr).

the gist of the code contains 3 lines:

Code: [Select]

    //read the enc port -> done in clearing the gpif flag
   
    //update encoder state
    _enc_state << = 2;              //left shift for new input
    _enc_state |= (IO_GET(tmp, ENC_A)?0x02:0) | (IO_GET(tmp, ENC_B)?0x01:0);
    return _enc_dir[_enc_state & 0x0f];


1khz per pulse train, 2 pulse trains per encoder, 6 encoders total means 1k x 2 x 6 x 100 or 1.2 mips on the high side and 0.5mips on the low side.

1.2MIPS for 6 encoders seems pretty accurate,

There are chances for improvement, however.

[techy101]

Wow, I've had to be away for the last week and just checked this again. I'm floored at all of the responses and suggestions. Thank you very much; it's going to take a while to think through and dig into some of these, but I think it'll be extremely helpful moving forward.

Thanks again,
Matthew

[tatus1969]

when you say 1khz I assume that this is the "tick" rate of each encoder based on the motor RPM. That means each encoder produces two quadrature signals of 250hz each. So my suggestion is to use a timer based approach: sample the state of *all* encodery simultaneously at a eate of at least 2khz, compare against previous states (use a table based approach to speed up code execution). That is easily doable with that controller. If you are not sure about the absolute maximum RPM you can choose 10khz interrupt rate, still no problem.

[techy101]

I wanted to say thank you again for all the input. We took the time to measure the time within a timer interrupt handler and found out that it's much much faster than we'd expected based on using external interrupts in the past. It was actually pretty neat to be able to add lines of code into the handler and see the time increase!

With the code needed it appears to take about 350ns to process the interrupt, not counting getting into/out of. Total processing time for the 6000 (only concerned with rising edges; don't have any need for both in the application) events that could occur in a given second is ~2.1ms. Even padding that heavily for other overhead it seems that this will be way more than acceptable.