chipKIT® Development Platform

Inspired by Arduino™

String Object

Created Fri, 15 Jul 2011 08:03:41 +0000 by admalakhov

admalakhov

Fri, 15 Jul 2011 08:03:41 +0000

Hi. I can't use Strings. why? mpide ver. win-20110619

hairymnstr

Fri, 15 Jul 2011 09:44:40 +0000

Can you provide a little more information? What are you trying to do with strings, can you provide some example code and describe how it is failing?

admalakhov

Sat, 16 Jul 2011 08:28:24 +0000

void setup() { Serial.begin(9600); }

void loop() { String stringOne = "Hello String";
Serial.println(stringOne); // prints "Hello String"

while(true); }

Error on Serial.println(stringOne);

davec

Sun, 17 Jul 2011 10:33:25 +0000

They left Print.print(String) out of the Print port for some reason.

Also even code with just a String declaration as in the above example is not linking, with this error:

sketch_jul17a.cpp:(.text.loop+0x10): undefined reference to `String::String(char const*)'

There is a WString.h but no WString.cpp under hardware/pic32.

The only workaround I can think of is to use

const char *stringOne = "Hello String";
Serial.println(stringOne); // prints "Hello String"

Mark

Wed, 20 Jul 2011 23:13:52 +0000

I and several others were very much against the string library being included at all. The first version had serious memory leaks, most but not all of them have been addressed. It still has issues.

On the atmel chips, there is not enough ram to EVER use malloc (in my opinion)

On the PIC parts, we have a bit more memory but still. In an embedded environment, without memory management, I STRONGLY recommend using malloc or the string library.

Just my $0.02 worth

KM6VV

Thu, 21 Jul 2011 18:25:20 +0000

Mark,

You do or DON'T recommend using malloc or the string library?

Alan KM6VV

I and several others were very much against the string library being included at all. The first version had serious memory leaks, most but not all of them have been addressed. It still has issues. On the atmel chips, there is not enough ram to EVER use malloc (in my opinion) On the PIC parts, we have a bit more memory but still. In an embedded environment, without memory management, I STRONGLY recommend using malloc or the string library. Just my $0.02 worth

svofski

Thu, 21 Jul 2011 21:45:36 +0000

I'm betting on a DO NOT.

Some OS's have their own memory managers designed for tight memory spaces, they could be handy if you're desperate for dynamic allocation. I'm pretty sure FreeRTOS has something for this, although I poorly remember.

ron.dunn

Fri, 22 Jul 2011 00:04:45 +0000

I think the root of the problem is Arduino compatibility.

If you claim to be "compatible", you shouldn't make philosophical decisions to drop features of that platform.

The library should be supported, and entries made in documention/wiki/whatever to recommend against its use.

Mark

Fri, 22 Jul 2011 00:58:27 +0000

You do or DON'T recommend using malloc or the string library?

I recommend to NEVER use the string library. It uses malloc() and it has memory leaks. It works but for something that is going to run a long time you WILL run out of memory.

I also recommend to NEVER use malloc. If you need memory, it should either be statically allocated as a global or just be a variable within a routine.

Let me give an example why NOT to use malloc

myPtr1 = malloc(256); myPtr2 = malloc(512);

free(myPtr1);

now you have a 256 byte hole in memory. Unless myPtr2 is also freed, you will never recover myPtr2.

This is because the memory management is EXTREAMLY simplified. There simply is not enough memory to keep track of what memory is used etc.

KM6VV

Fri, 22 Jul 2011 17:23:41 +0000

Even compilers for PC systems can get into the problem of memory "holes" if one thrashes storage around a lot. If you know you are going to need a lot of storage, it may be better (as has been recommended) to control some of the reallocation yourself.

Alan KM6VV

Digger450

Mon, 01 Aug 2011 05:10:54 +0000

I recommend to NEVER use the string library. It uses malloc() and it has memory leaks. It works but for something that is going to run a long time you WILL run out of memory.

This is unfortunate, I wish I would have read this post before purchasing 4 max32s. It also makes me wonder what you consider a long time? I've currently got at least 20 Arduino boards using String that have been running for more than a year with no crashes. I guess I'll have to shelve these max32s until I find another use for them :cry:

GeneApperson

Tue, 02 Aug 2011 23:40:06 +0000

The String object class is implemented in the file WString.cpp. This file got left out of the core files for the pic32 platform. I think that this was an oversight, and it should be in the next release. It is present in the core files for the Arduino platform, however. You can try copying the WString.cpp from the arduino cores to the pic32 cores and see if it works. The code should be pretty processor independent, so there is a good chance it will work.

It's on my task list to verify this in the next few days, but I haven't gotten to it yet.

As several people have suggested, you may not really want to use String objects, C style strings would probably be better.

Gene Apperson Digilent

andreibadilacg

Fri, 19 Aug 2011 08:42:29 +0000

Some sugestion? Code:

#include <SoftwareSerial.h> #include <String.h> #define rxPin 39 #define txPin 40

// set up a new serial port SoftwareSerial mySerial = SoftwareSerial(rxPin, txPin);

void setup() { // define pin modes for tx, rx, led pins: pinMode(rxPin, INPUT); pinMode(txPin, OUTPUT);

// set the data rate for the SoftwareSerial port mySerial.begin(9600); Serial.begin(9600); }

void receive()// asteapta comanda { String comands; char chr; comands=" ";

while(chr!='\229') ; Serial.println(" "); Serial.print("Receive ");

}

void loop() {

receive();

}

Error:

serialCom.cpp.o: In function receive()': serialCom.cpp:(.text._Z7receivev+0x14): undefined reference to String::String(char const*)' serialCom.cpp:(.text._Z7receivev+0x24): undefined reference to String::String(char const*)' serialCom.cpp:(.text._Z7receivev+0x30): undefined reference to String::operator=(String const&)' serialCom.cpp:(.text._Z7receivev+0x68): undefined reference to String::String(String const&amp;)' serialCom.cpp:(.text._Z7receivev+0x74): undefined reference to String::String(char)' serialCom.cpp:(.text._Z7receivev+0x80): undefined reference to String::operator+=(String const&amp;)' serialCom.cpp:(.text._Z7receivev+0x8c): undefined reference to String::String(String const&)' serialCom.cpp:(.text._Z7receivev+0x98): undefined reference to `String::operator=(String const&)' collect2: ld returned 1 exit status

Thanks

avenue33

Fri, 19 Aug 2011 09:49:38 +0000

Actually, pins 39 and 40 are already defined as RX and TX for the 2nd hardware serial port on UNO32.

Simply use [color=#0000FF]Serial1[/color], which is already defined just like [color=#0000FF]Serial[/color].

GeneApperson

Fri, 19 Aug 2011 20:50:13 +0000

These errors are link errors most likely resulting from the fact that the WString.cpp file got left out of the distribution. This should be fixed in the current test build being prepared for release.

The WString.cpp file is in the arduino side of the distribution in hardware/arduino/cores/arduino. You can try copying it to hardware/pic32/cores/pic32.

Gene Apperson Digilent

mongo

Fri, 19 Aug 2011 21:36:54 +0000

itoa is not defined with several data types is another issue on some platforms.

e.g. I only see char int int defined from the github source.

stdlib.h:extern char * itoa(char * buf, int val, int base);

WString.h trys to call iota with these data types and fails due to a mismatch on types.

I changed the following on 64 bit linux (made from source with the included 64bit compiler tarball) and it is working.

I do not know if the use of sprintf adds to the code size in a significant way.

The default graph example compiles as:

Binary sketch size: 7124 bytes (of a 126976 byte maximum)

Here is the diff on my file, for those who have not seen one the --- lines were replaced by the +++ lines in my file, the others are just the unchanged lines above and below.

The "@@ -63,3 +63,3 @@" means that the -63,3 line was at line 63 and it is showing 3 lines, the +63,3 is the location and number of lines from the original file.

The file will be in "hardware/pic32/cores/pic32" under your install directory.

--- WString.cpp.orig 2011-08-19 13:54:33.801796977 -0700 +++ WString.cpp 2011-08-19 14:12:54.550499520 -0700 @@ -63,3 +63,3 @@ char buf[33];

  • itoa((signed long int)value, buf, base); +sprintf (buf, "%ld", (signed long int)value); getBuffer( _length = strlen(buf) ); @@ -72,3 +72,3 @@ char buf[33];
  • ultoa((unsigned long)value, buf, base); +sprintf (buf, "%lu", (unsigned long)value); getBuffer( _length = strlen(buf) ); @@ -81,3 +81,3 @@ char buf[33];
  • ltoa(value, buf, base); +sprintf (buf, "%d", value); getBuffer( _length = strlen(buf) ); @@ -90,3 +90,3 @@ char buf[33];
  • ultoa(value, buf, 10);
  • sprintf (buf, "%u", value); getBuffer( _length = strlen(buf) );

andreibadilacg

Sat, 20 Aug 2011 09:27:50 +0000

Tank you very much

Mark

Mon, 22 Aug 2011 18:04:02 +0000

This is unfortunate, I wish I would have read this post before purchasing 4 max32s. It also makes me wonder what you consider a long time? I've currently got at least 20 Arduino boards using String that have been running for more than a year with no crashes. I guess I'll have to shelve these max32s until I find another use for them :cry:

Digger450

I recommend the EXACT same for Arduino, that is DONT USE STRING. If it works for you on the Arduino board, then it WILL work on the chipkit boards, it is the SAME code. I dont recommend it for either. The String class has documented memory leaks. (your mileage my vary)

mongo

Mon, 22 Aug 2011 23:46:50 +0000

The good news is that the beta of the new arduino 1.0 does not use malloc().

Unfortunately it does still use non-standard non-portable itoa etc...

It appears the base gcc string capability is included in the distributed compiler.

I see no reason WString.cpp couldn't be rewritten to us the native and portable functions.