Nick_Pyner:
I'm wondering how thisGets squared with this
That wouldn't matter too much. It's increasing error over time that I want to avoid. I don't intend to do real time analysis of any data, and a second or two delay in measuring encoders and displaying it is fine.
Here is a try at explaining my plan:
Slave: read encoder value all the time
Master: get encoder values from slave (6 bytes in 7 SPI calls, encoder values being stored in valueToSend variable on first call)
get time straight after and record it
process encoder values+recorded time
display something on the screen depending on those values
repeat or wait for button instruction
The encoder values measure the rotation of 2 perpendicular axis of a telescope mount. But the stars move all the time, so getting just the encoder value won't give me enough information to know which star I'm pointing at.
There will be an initialisation of the program where I would point at stars of known positions and click on q button to record the encodervalues/time. This then calibrates the program to then be able to give the sky coordinates from a couple (encoder values/time). This takes into consideration time between measures. So as long as I do (master get value from slave; master get time) in the same order without anything in between to record any couple of (encoder values/time), even if the time I record doesn't correspond to the time the encoder had those values, time between to record of (encoder values/time) will be the time I want anyway. Even if the call to slave take 0.2s and the call to time take 0.1s.
Even if I can get good accuracy for the calibration, after let's say 3 hours of use (typical observation session time), the program will still use the initial calibration, and calculates the roation of the stars to know where the telescope is pointing at. If at that point it is of by 10s, the position will be off by a little bit too, so I prefer to avoid that if I can.
In the end, I will need more than 32k of memory anyway, so I might get an arduino mega, which comes with a crystal.
DrDiettrich:
Ordinary controller activity does not block interrupts. If you find a problem with 2 encoders then your encoder ISR is designed badly, spending too much time in the ISR itself. Another ISR design problem is debouncing of buttons in an ISR - that's fatal abuse of interrupts.
With 2 encoders on the board, there is no problem at all. It is with one (or 2) encoders plus tft screen that there was some problem. My ISR code (in bith cases, master/slave or everything on the same board) is here, I don't think it can be much faster than that, but if it can I'm happy to learn how:
// Altitude encoder interrupt routine
ISR(INT0_vect)
{
// Activated if channel A of the altitude encoder (pin 2) changes state
// Check channel B of the altitude encoder to determine the direction (pin 4)
switch (PIND & 20) {//20 = b00010100, used to read pin 2 and 4
case 20:
++altEncoderCount;
break;
case 0:
++altEncoderCount;
break;
default:
--altEncoderCount;
}
} // end of altitude encoder interrupt routine