pYro_65:
@holmes4
The ( Hardware ) serial data is allocated statically:
And so is software serial and altsoftware serial.
The reason is
class HardwareSerial : public Stream
{
...
unsigned char _rx_buffer[SERIAL_BUFFER_SIZE];
unsigned char _tx_buffer[SERIAL_BUFFER_SIZE];
...
};
Combined with
extern HardwareSerial Serial1;
in hardwareSerial.h and because of that the needed
HardwareSerial Serial1(&UBRR1H, &UBRR1L, &UCSR1A, &UCSR1B, &UCSR1C, &UDR1, RXEN1, TXEN1, RXCIE1, UDRIE1, U2X1);
In other words the class gets instantiated as a global variable in the arduino core and as such the buffer gets added to the data section.
Remove the last 2 definitions and you save some space but lose the serial functionality.
That won't really help me as I need them.
pYro_65:
@Jantje, you said:
To be able to do so I overload the virtual SerialCommunicator::setReceivedMessage but this stopped working.
Where did you overload it, in SerialCommunicator or in SerialBridgeCommunicator
[EDIT: changed the code after the remark of Pyro]
Simplified the code looked like
class SerialCommunicator
{
protected:
virtual void setReceivedMessage(const char* newMessage);
public:
void loop();
};
class SerialBridgeCommunicator: public SerialCommunicator
{
protected:
virtual void setReceivedMessage(const char* newMessage)
{
.......
SerialCommunicator::setReceivedMessage(newMessage);
}
};
I changed it to
class SerialCommunicator
{
protected:
void setReceivedMessage(const char* newMessage);
public:
void loop();
};
class SerialBridgeCommunicator: public SerialCommunicator
{
protected:
void setReceivedMessage(const char* newMessage)
{
the same code goes here
}
public:
void loop()
{
code copied from SerialCommunicator.loop
}
};
By copying the code I changed the namespace and as such the correct setReceivedMessage is called. This was easy as setReceivedMessage is only called once.
In the mean time I have been able to do more code schrinking (I'll be an expert some day XD ) and I'm now at
Program: 29368 bytes (89.6% Full)
(.text + .data + .bootloader)
Data: 1958 bytes (76.5% Full)
(.data + .bss + .noinit)
I'm still experiencing problems. But with these figures (and my coding rules as mentioned above) I think we can rule out stack and heap problems in the pre setup code.
holmes4:
There is a way (playground) to get the amount of free ram left at run time and it would be very easy to write a stub program to check how well the reported ram usage matches the actual at the beginning of setup().
I see 2 problems here
- The report in setup does not take into account the top heap/stack usage before the processor came to setup
- When the problems happen the processor doesn't get to setup.
Best regards
Jantje