simple atoi() function on CF V1

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

simple atoi() function on CF V1

Jump to solution
684 Views
exfae
Contributor I

Hi group,

 

I have just ran into a snag that I dearly hope has an easy fix.

Have been using the MCF51AC256 on a project for a while now and all is great... so far.

 

The problem is this.

 

I have an ASCII string coming in from the serial port that is obviously stored into a char array in ram , say char tempbuf[100].

The application needs to convert this string of 0 to 9 into an integer. Simple right?

When I use the standard library atoi() function, I get compile errors because it actually wants a constant string from code space as if any and all application of atoi() would be in the atoi("12345") format instead of atoi(tempbuf[0]) .

Digging into it, the atoi is actually a define that points to strtol() function and it expects a const string ptr* (rom based from my understanding) as opposed to my RAM based string ptr*.

 

Is there a quick fix to tell the function to get it's const from ram instead?

 

I hope my somewhat limited knowledge of the standard MSL is at fault here.

Thank you in advance for your help.

Labels (1)
0 Kudos
1 Solution
457 Views
CompilerGuru
NXP Employee
NXP Employee

Can you provide, copy paste, the exact error you get?

CF does not differentiate rom pointers from data pointers. Everything is in a flat 32 bit address space.

 

Not sure what a "const string ptr*" is, did you mean "const char ptr*". A function expecting a "const char*" should be callable with a char* pointer (or a char array) without any troubles.

 

Also the sample should not be "atoi(tempbuf[0])" but atoi(tempbuf) or atoi(&tempbuf[0]), is that the actual issue?

 

Make sure to include <stdlib.h>.

 

Daniel

 

BTW: atoi does not allow to detect parsing errors, so using strtol might be beneficial.

View solution in original post

0 Kudos
2 Replies
458 Views
CompilerGuru
NXP Employee
NXP Employee

Can you provide, copy paste, the exact error you get?

CF does not differentiate rom pointers from data pointers. Everything is in a flat 32 bit address space.

 

Not sure what a "const string ptr*" is, did you mean "const char ptr*". A function expecting a "const char*" should be callable with a char* pointer (or a char array) without any troubles.

 

Also the sample should not be "atoi(tempbuf[0])" but atoi(tempbuf) or atoi(&tempbuf[0]), is that the actual issue?

 

Make sure to include <stdlib.h>.

 

Daniel

 

BTW: atoi does not allow to detect parsing errors, so using strtol might be beneficial.

0 Kudos
457 Views
exfae
Contributor I

Hi Daniel,

 

Indeed, this error was my own poor understanding of the C language pointer syntax in general.  ;o)

10 years without coding will do that to you.

 

By using  atoi(&tempbuf[0])  or atoi(tempbuf+0) the compile error went away. 

The error was:  illegal implicit converstion from 'char' to 'const char *'

 

I used the bracket [0] because I need an index in the string, i.e   tempbuf[k] where k points at different locations.

the sample code is

 

    switch (parse_state)
    {
      case JobParseState_head:
        while ((tempbuf[k]==0)||(tempbuf[k]=='*'))
        {
          job.Job_id = atoi(tempbuf[k]);
          do { k++;} while (tempbuf[k]!=' ');
          k++;
         .....  
        }

 

I agree with you that  the address space is flat but  the modifier const  tells the compiler that the variable is not  changed during execution and it gets placed in the same segment as code (.rodata and .text respectively). The linker command file then places them into the flash portion of that linear address space.  (0x0 on the MCF51AC256)

I guess what threw me off is the difference between atoi(tempbuf+k) and atoi(tempbuf[k]) when accessing a char array. It has nothing to do with const from my embedded point of view.

 

At any rate... thank you !!!

 

0 Kudos