Pages: 1 [2] 3   Go Down
Author Topic: software serial2  (Read 2631 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Newbie
*
Karma: 0
Posts: 3
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

However, after go through the source code of AFSoftSerial.cpp, it seems that it only supports down to 4800........


Code:
 _baudRate = speed;
  switch (_baudRate) {
  case 57600:
    _bitDelay = 17; break;
  case 38400:
    _bitDelay = 28; break;
  case 31250:
    _bitDelay = 36; break;
  case 19200:
    _bitDelay = 62; break;
  case 9600:
    _bitDelay = 128; break;
  case 4800:
    _bitDelay = 270; break;
  default:
    _bitDelay = 0;
  }
« Last Edit: February 10, 2008, 09:59:40 am by kwan6887 » Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 239
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

well its pretty trivial to add support for any baudrate. i havent officially released this so ill add 2400 - i didnt realize anything out there used < 4800 smiley-razz
« Last Edit: February 10, 2008, 10:20:21 pm by ladyada » Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 3
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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!!!

Code:
 _baudRate = speed;
  switch (_baudRate) {
...
...
case 2400:    _bitDelay = XXX ; break;
     default:    _bitDelay = 0;
  }  

Ref.
http://www.parallax.com/Store/Microcontrollers/BASICStampModules/tabid/134/txtSearch/rfid/List/1/ProductID/114/Default.aspx?SortField=ProductName%2cProductName
Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 9
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 239
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 9
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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?
Logged

0
Offline Offline
God Member
*****
Karma: 0
Posts: 731
skcor oniudrA
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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.


  
Logged

USA
Offline Offline
Jr. Member
**
Karma: 0
Posts: 73
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged


0
Offline Offline
Full Member
***
Karma: 0
Posts: 239
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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
Logged

USA
Offline Offline
Jr. Member
**
Karma: 0
Posts: 73
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I am referring to 9600 baud.

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'

When do you disable the pinchange mask?
Logged


0
Offline Offline
Full Member
***
Karma: 0
Posts: 239
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I am referring to 9600 baud.

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 printing
if someone wants an interrupt to go off while receiving/transmitting data, well, they're SOL cause you cant get good timing otherwise smiley

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!
Logged

USA
Offline Offline
Jr. Member
**
Karma: 0
Posts: 73
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
thanks

No problem!

It's really exciting seeing this library evolve into a powerful and robust library for the Arduino community. Great work everyone!
« Last Edit: February 25, 2008, 03:35:27 pm by AVRman » Logged


0
Offline Offline
Full Member
***
Karma: 0
Posts: 239
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

please answer the questions so that i can verify the problems you had

"which version of arduino software are you using? this would be helpful for debugging. thanks!"
Logged

USA
Offline Offline
Jr. Member
**
Karma: 0
Posts: 73
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I am not sure, it was on Tom's machine -you'll have to ask him.

Does 9600 work correctly on your version?

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.
Logged


0
Offline Offline
Full Member
***
Karma: 0
Posts: 239
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Pages: 1 [2] 3   Go Up
Jump to: