all are fine
You have to oversample each encoder, meaning sample faster than they are moving. assuming that 300Hz is correct. 1kHz is plenty fast, enough headroom just in case. Assuming a 2 pin encoder? There are only two valid next states from the current state yes? Updated your position based on current state and next state (increment a position or decrement, or whatever your solution is). For each wheel. value stored in a global used by the foreground task
if you can have it so any of the gpio pins changing state causes an interrupt that works too, less interrupt overhead, but if there is any bounce in the state change, you may get multiple interrupts (with bogus values). (oversampling you can also have bounce problems).
You need to be careful with interrupts and your code. Check the compiler output. Rusty on AVR but the registers are 8 bit yes? The loads and stores appear to be 8 bit. So if you have a 16 bit position counter your forground task is reading that counter which means it has to do at least two instructions to get the two parts from the global variable written by the isr and read by the application. Current position is 0x0FFF. You read 0x0F, get an interrupt, position changes to 0x1000, return from interrupt, forground task reads the second half 0x00, and thinks the position is 0x0F00. 255 counts wrong. for one loop of the forground task. So you need to be careful that this doesnt happen, many general ways to avoid it, but specific for this target, I dont remember off hand.
or you can do the math such that your position per wheel fits in one byte.
polling, so long as you poll fast enough, that works just fine (well bounce if there is any in your encoder is not fine, lets assume you dont have any). sometimes you have to poll more than once through the loop, make it a function
while(1)
{
do stuff
poll_wheels();
do stuff
poll_wheels();
...
poll_wheels();
}
or maybe the worst case loop is fast enough
while(1)
{
poll_wheels();
do stuff.
}
you need to deal with invalid states in some way, perhaps during development if you ever see an invalid state set a panic variable then just stop motors and everything and or set an led or something like that to visually indicate that this happened. not much you can do but should still have extra code that if the current state of an encoder is not a valid next state to the last state of that encoder, then other than setting the alarm variable/led/bit/counter, dont update the position but use the current state as the last state for the next test. just pretend from a position perspective that no movement happened but are at a new encoder position. if you have three bit encoders or more then you can see if you missed one and jumped two, but if it is just a two bit encoder you cant necessarily do that.