Where can I get old version of SoftwareSerial

I want to run an Attiny at 1Mhz and it seems that the current version of SoftwareSerial only supports 8Mhz and higher. I have the impression that the old version of SoftwareSerial didn't have that limitation and may be suitable for my needs.

My main requirement is to receive data over an IR link but it would be a benefit if I could also transmit for debugging purposes - connect the Tx line to my PC using an FTDI cable while the Rx is connected to the IR detector.

Does anyone have a link from which I can download the old SoftwareSerial library?

Thanks

...R

Robin2:
I want to run an Attiny at 1Mhz...

Why?

This is the version from version 0023, but as far as I remember there were more problems with that, than the new version

http://arduino-0023.googlecode.com/svn/trunk/libraries/SoftwareSerial/

@Erni, thanks for the link

@CodingBadly, I believe it uses less power at 1Mhz and it will be quite fast enough for what I want. And it's the default setting.

I've been trying to follow the long thread about "SoftwareSerial unusable ..." in which your code seems to feature prominently but I haven't quite got a clear picture of the whole process as most people who comment seem to know what they are all talking about. As far as I can see you stuff is designed as a simple process for transmitting debug messages without being able to read incoming serial stuff. My requirement is really the other way round.

...R

I want to run an Attiny at 1Mhz and it seems that the current version of SoftwareSerial only supports 8Mhz

With som math you might be able to derive the table of speeds for 1Mhz.

static const DELAY_TABLE table[] PROGMEM = 
{
  //  baud    rxcenter    rxintra    rxstop  tx
  { 115200,   1,          5,         5,      3,      },
  { 57600,    1,          15,        15,     13,     },
  { 38400,    2,          25,        26,     23,     },
  { 31250,    7,          32,        33,     29,     },
  { 28800,    11,         35,        35,     32,     },
  { 19200,    20,         55,        55,     52,     },
  { 14400,    30,         75,        75,     72,     },
  { 9600,     50,         114,       114,    112,    },
  { 4800,     110,        233,       233,    230,    },
  { 2400,     229,        472,       472,    469,    },
  { 1200,     467,        948,       948,    945,    },
  { 300,      1895,       3805,      3805,   3802,   },
};

for a 1Mhz clock I would start with a table like this, I expect speeds above 19200 to be very errorprone

static const DELAY_TABLE table[] PROGMEM = 
{
  //  baud    rxcenter    rxintra    rxstop  tx
  { 115200,   0,          0,         0,      0,      },
  { 57600,    0,          2,        2,     2,     },
  { 38400,    0,          3,        3,     3,     },
  { 31250,    1,          4,        4,     4,     },
  { 28800,    1,         4,        4,     4,     },
  { 19200,    2,         7,        7,     6,     },
  { 14400,    4,         10,        9,     9,     },
  { 9600,     6,         14,       14,    14,    },
  { 4800,     14,        28,       27,    27,    },
  { 2400,     28,        56,       56,    56,    },
  { 1200,     56,        118,       118,    118,    },
  { 300,      224,       475,      475,   475,   },
};

You can derive a formula as in - SoftwareSerial magic numbers - Libraries - Arduino Forum -
this might take some time, but a formula uses less RAM and allows you to tune the baud rate e.g. 9650 baud to match the 9600 baud of a PC/sensor.

Thanks Rob, your link is fascinating.

I had looked at the tables in SorftwareSerial but because, for example, the 8MHz numbers are not double the 16MHz numbers (though close) I figured somebody had derived them empirically - perhaps with an oscilloscope.

I will certainly think more about this option. I will be quite happy to get a row of numbers for a single baud rate - 2400 would do.

Unfortunately I can only test it at 1MHz on an Attiny. With an Uno you can monitor progress on the UART serialport.

If I get something working I will report back.

Incidentally I put the numbers from your three formulas (for the three MHzs) on three lines of a spreadsheet and it looks like it may make more sense to use the long formula (line 1) to calculate tx and then derive rxStop from that as the adjustment for tx would always be -6. I thought by doing this the adjustment for rxStop might be frequency related but it doesn't seem to be. In any case the variation in the adjustment is only about 1% of the calculated value of rxStop and I wonder have you tested whether the variation is actually necessary?

...R

Robin2:
..
Incidentally I put the numbers from your three formulas (for the three MHzs) on three lines of a spreadsheet and it looks like it may make more sense to use the long formula (line 1) to calculate tx and then derive rxStop from that as the adjustment for tx would always be -6. I thought by doing this the adjustment for rxStop might be frequency related but it doesn't seem to be. In any case the variation in the adjustment is only about 1% of the calculated value of rxStop and I wonder have you tested whether the variation is actually necessary?

no, I just wanted to be close the empirical numbers,

Can you post your variation of the formulas (preferably in the other thread)

Hi Rob,

I've written a post in the other Thread as you requested.

...R