simple atoi() function on CF V1

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

simple atoi() function on CF V1

ソリューションへジャンプ
707件の閲覧回数
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.

ラベル(1)
0 件の賞賛
1 解決策
480件の閲覧回数
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 件の賞賛
2 返答(返信)
481件の閲覧回数
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 件の賞賛
480件の閲覧回数
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 件の賞賛