Interrupt-based approach to an Inverted Pedulum Project

Hello, first post here, though I've read the forums a lot. I'm building an inverted pendulum based on a cart and have run into a question on how to structure the code to achieve what I want.

Firstly the general approach: I'm using an Arduino Uno as the microcontroller. The cart motors are controlled by a Sabertooth 2x12 motor driver, and the angle measurement is made by a Sparkfun Rotary Encoder. I tried a potentiometer feeding the Arduino analog in, this worked OK but the pot was a bit stiff for what I wanted.

The encoder is of the incremental type, so I need to make sure I don't miss any pulses, in order to maintain the correct angle measurement. One of the ways to do this is to use the interrupt-based examples from here. The Sabertooth has various operating modes - the one I'd like to use is the packet-based serial mode, which receives commands output over the Arduino's serial Tx pin. There is a nice library for this here.

As I'm new to Arduino and RT SW in general, the question I have is whether the encoder interrupts will cause problems with the serial motor commands. Presumably yes, as they certainly cause problems with serial.print. Is there any way to get around this, and generate serial commands plus handle interrupts? If there's no simple approach, could there be an approach which needs 2 Arduinos - one to process the interrupts and the other to handle the motor - maybe communicating over I2C?

Note there is a workaround: I can use the Sabertooth in analog PWM mode, but I'd really like to stay with the Packetized Serial mode, mainly as a learning exercise!

Interrupts do not cause significant problems with Serial.print, assuming that you write your interrupt service routines to execuite reasonably quickly. What may be confusing you is that you must not call Serial.print from within an interrupt service routine.

dc42: Interrupts do not cause significant problems with Serial.print, assuming that you write your interrupt service routines to execuite reasonably quickly. What may be confusing you is that you must not call Serial.print from within an interrupt service routine.

OK thanks! The ISR basically only reads a digital pin and increments a counter, so should be fairly fast. I suppose if I encounter problems I can always try some of the fast equivalents of digitalRead. I've just about finished putting together the hardware, so I hope to be able to give it a go tomorrow.