SoftwareSerial problems

 Hello everybody:

Any known reason why SoftwareSerial can not be used in the NanodeRF if used as emonBase ?

I want to display the received data in a 7-Seg display using serial protocol and I can not make it works.

Tryied several different Digital Outputs available in my Nanode but none of them work, the software restarts each time attemps to write data to the SoftwareSerial port.

Any help will be welcome.

Thanks a million. Nelson.


TrystanLea's picture

Re: SoftwareSerial problems

 Hello Nelson, Im afraid I havent tried this, has anyone else?

stuart's picture

Re: SoftwareSerial problems

I used the SoftSerial as part of my SMA PV interface software, might be of some use to you.


nejemia's picture

Re: SoftwareSerial problems

 Thank you Stuart, Trystan:

I solved the problem but I'm afraid it is a very rudimentary solution.

Problem is with mySerial.print() statement - I've used mySerial.write() and I'm sending 1 Byte at a time to the Display and it works happy.

Weird, but... Learning the hard way.

Now, I'm facing another problem which involves RF12 module init.

Have 2 sketches which uses exactly the same init procedure, one works, the other does not...

I am using Trystan examples Fixed_Packets and Basic_multinode_webclient.

Fixed_Packets works, the other hungs at: if (rf12_recvDone() && rf12_crc == 0 && (rf12_hdr & RF12_HDR_CTL) == 0)

Never gets TRUE -

Well, lets continue working and thanks a lot !


nejemia's picture

Re: SoftwareSerial problems

 Hello pal's:

I just detected the RF12 module has problems during initialization-

It hungs right  after :  rf12_initialize(10,RF12_433MHZ,210); // NodeID, Frequency, Group

                                    Serial.println("Inicia RF12");
Main problem: this failure is not always, with some sketches it works with some others doesn`t ... 
Any ideas? Suggestions ? 
Thanks a lot --
robinsmh's picture

Re: SoftwareSerial problems

I'm not sure about the Nanode, but on the emonGLCD, the standard PV sketch uses nearly all the available memory (which is only 1K max to start with!) so any extra global variables or extra libraries added tend to make it crash in wierd and unpredictable ways.

There's a forum thread here which describes how to measure free memory:

Here's their code:

extern void __bss_end;
extern void *__brkval;

int get_free_memory()
  int free_memory;

  if((int)__brkval == 0)
    free_memory = ((int)&free_memory) - ((int)&__bss_end);
    free_memory = ((int)&free_memory) - ((int)__brkval);

  return free_memory;

This returns the free bytes between heap and stack. If the stack grows doen to meet th heap (or static data) then it will crash. Maybe that's the problem here?



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.