Jump to content
Sign in to follow this  
jcourter

Additional String Functions For Boostc?

Recommended Posts

It would be nice to have more of the standard C string functions available in BoostC, like strlen, strcmp, strcmpi, and sprintf.

While strlen, strcmp (probably should make that strncmp) would be nice, I disagree for sprintf. sprintf would have to be a monster function, unless you limited it to only a few capabilities. Just adding '%d' or '%ld' adds a large amount of code. Then there are all the formatting options. And, in the end, storing temporary strings in RAM is extremely wasteful (much better to operate on the string as you build it).

 

At some point, it is time to remember that this is a micro-controller, and that it is better to only implement what is realy needed. Also, it is usually a bad idea to deal with strings in RAM if you have any option at all. They consume an awful lot of that precious commodity.

For the others here you go. Not strictly ansi-c compliant, but good enough for most purposes. You could probably search the internet for 10 minutes, and come up with better implementations, but these wil at least work with boost-c as is.

char strlen(char *a)
{
 char i=0;
 while(a[i]) {
   ++i;
   if(test_bit(i,7))
       break;
 }
 return(i);
}
signed char strncmp(char *a, char *b, char len)
{
 char i;
 for(i=0; i<len; ++i) {
   if(a[i]<b[i])
       return -1;
   if(a[i]>b[i])
       return 1;
   if(! a[i])
       return 0;
 }
 return(i);
}

signed char strncmpi(char *a, char *b, char len)
{
 char i,tmpa;
 for(i=0; i<len; ++i) {
   tmpa=a[i];
   if(tmpa>64 && tmpa<91)
     tmpa+=32)
   if(tmpa<b[i])
       return -1;
   if(tmpa>b[i])
       return 1;
   if(! tmpa)
       return 0;
 }
 return(i);
}
#define strcmp(a,b) strncmp(a,b, 128)
#define strcmpi(,b) strncmpi(a,b,128)

Edited by PhracturedBlue

Share this post


Link to post
Share on other sites
While strlen, strcmp (probably should make that strncmp) would be nice, I disagree for sprintf.  sprintf would have to be a monster function, unless you limited it to only a few capabilities.  Just adding '%d' or '%ld' adds a large amount of code.  Then there are all the formatting options.  And, in the end,  storing temporary strings in RAM is extremely wasteful (much better to operate on the string as you build it).

 

 

Thanks for the response (and the code). My rationale for sprintf is that it could be used in lieu of specialized printf-esque functions. A perfect example is the lprintf function in the lcd driver header included with SourceBoost. If there were a generic sprintf function, all that would be needed to output nicely formatted strings on any interface (serial, LCD, LED matrix, or a laser beam on the moon's surface) would be a puts function, which would be much simpler to code. I realize that the PIC is, by nature, a device with limited resources, but if your particular application is consuming too many resources to use a sprintf function, you always have the option of coding it the hard way to save RAM.

Share this post


Link to post
Share on other sites
While strlen, strcmp (probably should make that strncmp) would be nice, I disagree for sprintf.  sprintf would have to be a monster function, unless you limited it to only a few capabilities.  Just adding '%d' or '%ld' adds a large amount of code.  Then there are all the formatting options.  And, in the end,  storing temporary strings in RAM is extremely wasteful (much better to operate on the string as you build it).

 

 

Thanks for the response (and the code). My rationale for sprintf is that it could be used in lieu of specialized printf-esque functions. A perfect example is the lprintf function in the lcd driver header included with SourceBoost. If there were a generic sprintf function, all that would be needed to output nicely formatted strings on any interface (serial, LCD, LED matrix, or a laser beam on the moon's surface) would be a puts function, which would be much simpler to code. I realize that the PIC is, by nature, a device with limited resources, but if your particular application is consuming too many resources to use a sprintf function, you always have the option of coding it the hard way to save RAM.

 

Sprintf is a necessity not a luxury, if people are worried about space/resources they have the choice to not use Sprintf.

Share this post


Link to post
Share on other sites

To me, this seems like it would go along well with an extra library set simular to float.

 

Including it by default might cause issues by people trying to use it without thinking about the concequences of ram, speed, and space. Altho most people wouldnt use it in my mind anyway, since those functions are more related to console/stream input, but i suppose for fancy interface control or web based control ... altho you could do it on the client side as well.

 

i guess if you follow my rational though, unlike you indicated, you wouldnt be using generic code like printf anyway as the loss of time could potentially be huge due to it's timming delays.

eg. My LCDs have 50us data write cycles and 2.4ms command writes.

 

Maybe we need a Sourceboost user contributed library repository for great little snippets of code like this, it would be easy enough to drop it in your own library on demand if you needed it ...

Share this post


Link to post
Share on other sites

emte,

 

To me, this seems like it would go along well with an extra library set simular to float.

....

Sorry I don't get the point of what you are saying.

 

BTW: Have a look in the BoostC V6.60 reference manual as we now have an sprintf, itoa and some other standard conversion routines. Also there are some light weight non standard conversion routines.

 

Regards

Dave

Share this post


Link to post
Share on other sites
emte,

 

To me, this seems like it would go along well with an extra library set simular to float.

....

Sorry I don't get the point of what you are saying.

 

BTW: Have a look in the BoostC V6.60 reference manual as we now have an sprintf, itoa and some other standard conversion routines. Also there are some light weight non standard conversion routines.

 

Regards

Dave

 

sorry i occasionally wander through my own head that way...

Perhaps more of a fully featured library option set where one is not worried about device constraints, but you only include what you want for libraries anyway so i am not sure that comment makes any sense at all now....

 

How about we disregard that comment all together?

Edited by emte

Share this post


Link to post
Share on other sites

emte,

Perhaps more of a fully featured library option set where one is not worried about device constraints, but you only include what you want for libraries anyway
Only the functions called in a program are included in the final binary, orphan functions are removed.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×