Is "new" broken for ATTiny?

Hi All,

I’m having trouble using SoftwareSerial on an ATTiny85. I don’t think that it’s specific to the tiny, however, so I’m looking here for help.

The following code works as expected:

////////////<Code>//////////////////////////
#include <SoftwareSerial.h>

SoftwareSerial serial(0, 1);

void setup()
{
serial.begin(4800);
serial.println("hi");
}
void loop()
{
}
////////////</Code>//////////////////////////

However, if I make serial a pointer and allocate it using the “new” operator - it doesn’t work at all:

#include <SoftwareSerial.h>

SoftwareSerial *serial;

void setup()
{
serial = new SoftwareSerial(0, 1);
serial->begin(4800);
serial->println("hi");
}
void loop()
{
}

Is this a known issue? It seems to be breaking a library I use (MeetAndroid), which uses “new” to create a SoftwareSerial object with the pins I send to its constructor.

Sean

Moderator edit:
</mark> <mark>[code]</mark> <mark>

</mark> <mark>[/code]</mark> <mark>
tags added.

Is this a known issue? It seems to be breaking a library I use (MeetAndroid), which uses "new" to create a SoftwareSerial object with the pins I send to its constructor.

You are trying to use MeetAndroid on a ATTiny? Don't you need a ATHuge for that?

You are trying to use MeetAndroid on a ATTiny? Don't you need a ATHuge for that?

It seems to fit fine. Running at a cool 7.5k. Any ideas about the issue with new? I generally prefer dynamic allocation to static so this is a pretty general problem for me =/

thebiglebowski2:
I generally prefer dynamic allocation to static

That's not a habit that will stand you in good stead on an Arduino, especially an ATTiny. In this case you're only allocating memory at startup and never releasing it so you're unlikely to encounter the heap corruption and fragmentation issues associated with dynamic allocation, but it's not giving you any benefit and it you extend that approach and make more widespread use of heap memory you could be heading for trouble.

Other than the philosophical objection, is there anything stopping you from declaring the SoftwareSerial statically?

In terms of getting the new() operator working, I'd suggest using the simplest and most direct approach to getting serial comms working (because I've seen comments suggesting that it can be problematic on the ATTiny) and once you have, investigate any remaining dynamic allocation problems separately (I suspect you will find that new() actually works just fine and all you're seeing is a SoftwareSerial problem).

Thanks PeterH for the reply - I do probably need to start thinking more procedurally when designing my arduino codes.

In any event - the plot thickens! I did a bunch of experimenting and found that the serial output fails if the SoftwareSerial object is created outside of the main .ino file. Normally, the library does the following in its constructor:

MeetAndroid(int baud, int rx, int tx)
{
SSerial = new SoftwareSerial(rx, tx);
SSerial->begin(baud);
}

I assumed it was "new" that was making this fail because if I use the same code directly in the arduino setup() method it fails to work, whereas statically declaring "SoftwareSerial serial(rx, tx);" works just fine.

However, if I change that to:

MeetAndroid(int baud, int rx, int tx)
{
SoftwareSerial s(rx, tx);
s.begin(baud);
SSerial = &s;
}

This also fails to work! Does anyone have a clue why the SoftwareSerial object seems to fail on an ATTiny85 if the object is either:

a) Created dynamically in the main ino file
b) Created dynamically in an included library
c) Created statically in an included library

Any ideas?

thebiglebowski2:
a) Created dynamically in the main ino file
b) Created dynamically in an included library
c) Created statically in an included library

…forgot one…

e) There is a bug in my code

MeetAndroid(int baud, int rx, int tx)
{
SoftwareSerial s(rx, tx); // <<<<< s is an automatic variable. Its entire scope is this function.
s.begin(baud);
SSerial = &s;
// <<<<< s is now out of scope and is destroyed. SSerial is a reference to an object that no longer exists.
}

:astonished:

Right so that's clearly why the "static declaration in library" doesn't work - my bad! I forgot that C does have a certain degree of "garbage collection". Any idea why the original didn't work? That is, using:

MeetAndroid(int baud, int rx, int tx)
{
SSerial = new SoftwareSerial(rx, tx);
SSerial->begin(baud);
}

?

thebiglebowski2:
Right so that's clearly why the "static declaration in library" doesn't work - my bad!

Actually, it's why "declaration as a local automatic variable" doesn't work. There's nothing wrong with "static declaration in library" as long as you do it right.