Try this:

Code:

if ((a ^ b) || (a && b)) {
 // do something
}

the ^ is an XOR, the || is OR, and the && is AND.

A6 is a dedicated analog input; it is one of the (very few) pins on the ATMega328P microcontroller that can't be used as GPIO (digital input/output).

See here: http://www.atmel.com/Images/8271S.pdf and look at section 1.1.9 for more information.

If you need additional GPIO, you may want to look into using a shift register, such as a 74HC595.

Do you have current-limiting resistors on the 7-segment display? You didn't post a datasheet, but many shift registers and similar ICs have a fairly limited capability to supply current. As a result, the voltage output could drop significantly with current load.

I think your problem is simpler than that--I'm not aware of any implementation of SoftwareSerial that can handle 115.2 kbaud reliably. Drop the baud rate, or use the hardware serial port for the higher-speed communications.

[...]
 (because there is no virtual serial device base class I couldn't get rid of the call to Serial.begin(MIDI_BAUDRATE)).
[...]

You can use the magic of OOP and have an overloaded constructor which takes a HardwareSerial*, so that the usage could be either this:

Code:

MidiOutPort midiOut(&softSerial);

or this:

Code:

MidiOutPort midiOut(&Serial);

completely transparent to the user. In the library implementation, the easiest way to do this is to encapsulate the write() function, forex:

Code:

void write(uint8_t b) {
  if (m_hws != NULL) { // set to null in the softwareserial constructor
    m_hws->write(b);
  } else { // not using hardware serial
    m_ss->write(b);
  }
}

The Rover 5's two motors may have different characteristics, and thus draw different amounts of current at a given voltage (this is often a result of friction in the gearbox, or other such mechanical issues). If you want them to have the same speed, you will need to use feedback on the speeds of the output shafts (possibly via encoder) as an input to a control loop.

Replace the WProgram.h in the file Sabertooth.h with Arduino.h, and it should work.

McMaster-Carr is nice for mechanical parts, albeit somewhat more on the expensive side. They've got a warehouse in LA, so shipping is usually one-day, which is a nice benefit, and their quality is very good.

Other than that, local suppliers are best for hardware--it tends to be heavy and vary in quality, so being able to check it out is nice.

If the I2C communication is interrupted, the Arduino will busywait indefinitely for an ack that never comes, which sounds like your problem--make sure that the connections are secure.

You assume that the bytes will be available when they might not be: though you do busy-wait until the first byte has come in, for subsequent bytes, you just delay(100), which does not guarantee that the data has been transmitted. Remember that I2C allows slaves to clock stretch and thus not transmit data until later.

That code won't even compile in Arduino 1.0 -- the Wire.send function is now named Wire.write; and the same goes for Wire.receive / Wire.read

No problem--feel free to ask questions at any time.

The Servo library uses the Timer that generates the PWM output for your fan, so it becomes restricted to binary digital output. You can solve this competition for hardware resources by picking a different PWM pin to run the fan from (The first 8 or so servos will use the same Timer, so there's not much point moving that).

The common FTDI USB to serial chips are quite happy until a few megabaud, and I've used mine reliable at 250kbaud for some time now.

According to the datasheet, at 16MHz 250000baud has a very low error (supposedly 0%)--it's probably the most reliable high-speed rate you can have.

For the implementation of this device, you should note that the Arduino (Mega) pin layout does NOT match the 8-bit registers that are used to read each pin, so for maximum speed you might want to look into the "direct port manipulation" commands and wire the system that way.