ladyada:First of all, thanks for your reply!!Actually, I am working on parallax RFID Reader Module which is configured as 2400bps. Therefore, I would like to amend the coding in AFSoftSerial in order to support the RFID module.

As mentioned before, I cannot figure out the appropriate _bitDelay for baudrate 2400. Could you do me a favour!? Thanks!!!

How hard do you think it would be to be able to have multiple instances of the class on different pins? It's a bit misleading to be able to create lots of instances of the AFSoftSerial class but only have one of them able to receive data.

this is an unreleased project, i posted it "if someone wants to play with it...", it was designed so i could hack and debug my xport shield.its not a direct replacement for the default softwareserial so if you need multiple serial ports, different baudrates or atmega8/lilypad support then this isnt for you. in fact, it isnt even fully debugged so for all i know it may not work in certain situations.

Sorry, I didn't mean to make unreasonable demands. The library is quite good for an unsupported / unreleased project. The reason I ask is only because I'd really like to replace the current SoftwareSerial library with something along the lines of the AFSoftSerial. I was hoping you might be able to do some of the clean-up / improvements. Do you have any time for that, or might you in the future? Or should I take a shot at it?

this is an unreleased project, i posted it "if someone wants to play with it...", it was designed so i could hack and debug my xport shield.its not a direct replacement for the default softwareserial so if you need multiple serial ports, different baudrates or atmega8/lilypad support then this isnt for you. in fact, it isnt even fully debugged so for all i know it may not work in certain situations.

Don't worry about the Lilypad they join at the hip quite nicely via I2C and are inexpensive enough to stack two together to provide the solution I was looking for.

You did an excellent job it's a good start. And there's a great deal of enthusiasm for this as a solution to the nagging problem of only having one hardware serial, so moving it forward is a big accomplishment.

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?

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;

what baud rates are you specifically referring to? what was your test that you couldnt get working?could you specify where im using timer0 in my code? i dont see it anywhere so im not sure why you're referring to it. there should not be any interrupts that overlap unless, of course, you have the mismatched baud rates, but if you do that you're kinda on your own

In your pin change interrupt handler, if you don't disable interrupts, how can you be assured the timing is correct? What if timer0 overflows during your recv routine? What if people are using other interrupts?

In whackDelay, how can you be sure the compiler won't optimize away your software delay loop? Maybe consider making those variables 'volatile'

In your pin change interrupt handler, if you don't disable interrupts, how can you be assured the timing is correct? What if timer0 overflows during your recv routine? What if people are using other interrupts?

SIGNAL interrupt handlers, by default, call cli() at the beginning, and sei() at the end so no interrupts will get in the way while it receives data. i specifically call sei() and cli() for printingif someone wants an interrupt to go off while receiving/transmitting data, well, they're SOL cause you cant get good timing otherwise

Quote

In whackDelay, how can you be sure the compiler won't optimize away your software delay loop? Maybe consider making those variables 'volatile'

that could be happening, although it doesnt in my version of the Arduino software (10)which version are you using? this would be helpful for debugging. thanks!

The way we measured the receive function was to pin toggle whenever the pin was read. The bit timing look correct, however, it didn't always line up on the waveform correctly. Sometimes the pin reads would be off by 3-5 bits and other times completely off of the waveform.

so, nobody who has had problems with this code has posted a screenshot or even told me what version of software they're using. thus its pretty much impossible for me to debug whats wrong. however, ive posted a new version of the afsoftwareserial library with a volatile asm delay loop.http://www.ladyada.net/make/eshield/download.html