atoi problems

"... expecting to get a 4 digit number in command."

Assuming 'index' is 0 upon entry, the loop iterates 5 times.

"But command is always 0 (zero)."

Are you NUL-terminating received digits to make 'comin[]' a proper string or are you relying on some other means of causing atoi() to stop?

"... expecting to get a 4 digit number in command."

Assuming 'index' is 0 upon entry, the loop iterates 5 times.

"But command is always 0 (zero)."

Are you NUL-terminating received digits to make 'comin[]' a proper string or are you relying on some other means of causing atoi() to stop?

Never mind what I said about the loop count.

How atoi() stops is still a valid question.

Dan, I am terminating the string of 4 ASCII chars with a \n. Really strange problem.

If you terminate the array with a '\n', then you do not have a C string. A C string should be terminated with a '\0' which is the character constant corresponding to the numeric value 0.

If you always get the value 0 from atoi(), then your string either contains the numeric string "0" (possibly with an initial whitespace and optional sign) or none of your strings contains anything that may be converted to a number.

Do show the smallest code snippet that shows an incorrect (in your view) return value from atoi(), so we can see what you are doing wrong.

Another point here is how do you know that the value is always 0?

If you are printing it out then remember it is an "int" value returned by ATOI and you need to use the correct print format as it is possible to get silly print values with other formats.

As for the discussion about when ATOI stops, it is clear in the function description that it stops as soon as it encounters a non numeric character (I guess it applies ISDIGIT or something similar). This means a \n should work although is not really preferable over a \0 as described earlier as this is a proper C string terminator.

I use ATOI quite a lot on an 89C51 and it works fine for me.

Cheers,

Dirk

Dirk/Per,
thanks for the feedback. I will take look a bit later tomorrow - I am out on business at the moment.

Cheers
Jason

hi,
today I did some more work on this problem.

1. I corrected the serial routine to collect chars 1 by 1
2. If i look at comin, command and index using the simulator I can see that index is incrementing, comin is collecting the chars (I'm putting in the ascii codes, so i.e. digit '9' is 57decimal
3. the reason atoi is not working is my code never goes through the atoi segment of the code - it always jumps over it.
4. I experimented and removed the if statement and braces arounf th e aoi statement and atoi is working.
5. The problem is my if statement . . .

I have to admit I am stumped at this point.

here is the serial input routine

void uart_rx_isr (void) interrupt 4 using 3
{

        if (RI==TRUE)           /* if  RI  is  set  then  execute       the  RxD routine,  else jump over and exit*/

        {
        comin[index] = SBUF;    // I tried (getchar()) which also works
        ++index;
        RI = FALSE;             /* clear the  RI interrupt flag and exit */
        }

}

here is the fragment that contains the atoi

loop:
        /* this is the  main process  loop  - it services  pushbutton  and  */
        /* rotary encoder  inputs  as  well  as  th e inputs  from the remote */


        if (comin[5]=="\n")
        //if (index==6) can also be  used here, but I prefer the \n or some other command string termiator
        {
        command = atoi(comin);
        txprocess();  // go and process  the command
        index=0;
        }

        command = 0;                    /* now flush command and comin */



goto loop;
  }

Note that "\n" is a C string. The value of the C string is the address of the first character in the string.

What you want to do is to compare characters, so you should use a character constant.

if (comin[5] == '\n') {
    ...
}

Notice the difference between single and double quotes.

If this

if (comin[5]=="\n")

ever compiled without throwing a warning into your face, you run the compiler at an insufficiently high warning level.

Not even to mention you absolutely neet to get yourself a LINT tool and start using it. Now!

It is a common assumption that warnings can be ignored - anything that creates a binary should be good to go.

It is a common assumption that warnings can be ignored

Well, I don't have to tell you, Per, but for the record: most of the time, using sensible tools, that assumption is wrong. Especially so if the person doing the ignoring doesn't know enough C to even understand the warnings' meaning.

Only if you're sure you could explain convincingly to both your grandma and your boss why exactly you're getting this particular warning about this particular piece of code, and why it's harmless in this particular case, you can ignore it. Actually in that case you may even go ahead and disable it for this particular case, if the tools have sufficiently fine-grained control over warnings. That's one reason why LINT is more important than the C compiler in the business of checking warnings: its warnings have the finest controls you're likely to find in any tool.

The atoi statement is wroking now - thank you. I have mad e similar errors in other sections of the code - these are also fixed now.

Jason

Yes, I did get warnings about 'statements that do nothing' but these warnings were for two while (1) statements, not for the atoi statement detailed above.

I have the warning level set to the highest in the compiler.

Do have a recomendation for a lint program?

Jason

PC-Lint from Gimpel Software.
Bradford

I am using version 9. An occasional life saver.

Ok I will give it a try.