Ladyada,
Tom and I put your software serial up on the scope at the last hack to verify it's correct operation. We couldn't get it to work for the slower baud rates and came to a couple of conclusions about why. First off, thanks everyone at the Hacklab for helping!
Looking through your code, here are some suggestions to help improve your library...
You need to make sure multiple interrupts aren't stacking up without being handled so,
Having delays based on an overflowing timer0 interrupt inside of a pinChange interrupt handler is asking for trouble.
Also, why not disable the pin change interrupt (clear the mask) after the start bit?
When using a software serial, make sure other interrupts aren't screwing up recv delay;
Since you calculate constants for the delays anyway, why not use unoptimizable loops to generate your bit timing delays?
So maybe it could go like this (without a buffer of course),
pinChangeInterruptHandler()
{
if ( (RX pin is low) && (startBitArrived == FALSE) )
{
startBitArrived = TRUE
pinChangeMask = Disabled;
}
}
//the receive function
recv()
{
recvDone == FALSE;
while(recvDone == FALSE)
{
if (startBitArrived)
{
cli(); //disable interrupts
delay(bitTime/2); //use a fixed delay not based off of interrupts
for (unsigned char bit =0; bit < 8; bit++)
{
read RX pin;
delay(bitTime);
}
delay(bitTime/2); //put us at the end of the stop bit
recvDone = TRUE;
pinChangeMask = ENABLED;
startBitArrived = FALSE;
sei(); //enable interrupts
} //end if
} //end while
} //end recv