First C Program, Problems getting serial data

[Chuck Faranda]

I'm trying to debug my first C program (firmware for PIC MCU). The problem
is getting serial data back from my device. My get commands have to be sent
twice for the PIC to respond properly with the needed data. Any ideas?
Here's the code in question, see any reason why a command would not trigger
the 'kbhit' the first time a serial command is sent?: Thanks!

Chuck

****************************************************
while(1) // loop forever
{

// check for a request via serial
if (kbhit())
{
gets(cmd);
//flash the LED to show a command is being processed
output_high(LED_PIN);
delay_ms(200);
output_low(LED_PIN);
//check for proper request
strcpy(cmdcheck,"CFGET");
if (strcmp(cmd, cmdcheck)=1) // if it is our command return the value
of current
//read the adc value
set_adc_channel(CURRENT_CHANNEL);
delay_us(ADC_DELAY);
s1 = read_adc();
current = (0.05*s1); // check this scaling (10 bits all 1's = 5.0)
//send the requested data
printf("CF%3.1f\r\n", current);
}
delay_ms(50); // delay 50 ms and do another cycle
} // end while
}
****************************************************

 

[Walter Roberson]

I'm trying to debug my first C program (firmware for PIC MCU). The problem
is getting serial data back from my device. My get commands have to be sent
twice for the PIC to respond properly with the needed data. Any ideas?
Here's the code in question, see any reason why a command would not trigger
the 'kbhit' the first time a serial command is sent?: Thanks!

****************************************************
while(1) // loop forever
{

// check for a request via serial
if (kbhit())

kbhit() is not a standard part of the C library, and you have not provided
code for it nor documentation on what *exactly* it does. Any guesses we might
make about why your code does not do what you expect would be... well, guesses.
You need to check out your platform-specific documentation.

Wild guess: the other end is a C program and the other end is set to buffer
output [probably by default] and the other end does not specifically
fflush() to force the output to be sent from the buffers to the device driver.

 

[Chuck Faranda]

Oops, sorry. Here's the only docs that came with the compiler:

It may be possible fot the buffers to be full, I'll see what can be done
about flushing, thanks.

KBHIT()


Syntax:
value = kbhit()



Parameters:
None



Returns:
0 (or FALSE) if getc() will need to wait for a character to come in, 1
(or TRUE) if a character is ready for getc()



Function:
If the RS232 is under software control this function returns TRUE if
the start bit of a character is being sent on the RS232 RCV pin. If the
RS232 is hardware this function returns TRUE is a character has been
received and is waiting in the hardware buffer for getc() to read. This
function may be used to poll for data without stopping and waiting for the
data to appear. Note that in the case of software RS232 this function
should be called at least 10 times the bit rate to ensure incoming data is
not lost.



Availability:
All devices.



Requires
#use rs232



Examples:
char timed_getc() {



long timeout;



timeout_error=FALSE;

timeout=0;

while(!kbhit()&&(++timeout<50000)) // 1/2 second

delay_us(10);

if(kbhit())

return(getc());

else {

timeout_error=TRUE;

return(0);

}

}



Example Files:
ex_tgetc.c



Also See:
getc(), #USE RS232



--

Regards,
Chuck Faranda
http://ccdastro.net

I'm trying to debug my first C program (firmware for PIC MCU). The
problem
is getting serial data back from my device. My get commands have to be
sent
twice for the PIC to respond properly with the needed data. Any ideas?
Here's the code in question, see any reason why a command would not
trigger
the 'kbhit' the first time a serial command is sent?: Thanks!

****************************************************
while(1) // loop forever
{

// check for a request via serial
if (kbhit())

kbhit() is not a standard part of the C library, and you have not provided
code for it nor documentation on what *exactly* it does. Any guesses we
might
make about why your code does not do what you expect would be... well,
guesses.
You need to check out your platform-specific documentation.

Wild guess: the other end is a C program and the other end is set to
buffer
output [probably by default] and the other end does not specifically
fflush() to force the output to be sent from the buffers to the device
driver.

 

[regis]

I'm trying to debug my first C program (firmware for PIC MCU).

if (strcmp(cmd, cmdcheck)=1) // if it is our command return the value

you probably want :

if (strcmp(cmd, cmdcheck) == 0)

i.e. use the equality operator instead of the assignment operator,
and compare the return value of strcmp with zero...

 

[Chuck Faranda]

I'll give that a try to see what happens. Thanks.

 

[Burton Samograd]

you probably want :

if (strcmp(cmd, cmdcheck) == 0)

actually, you probably want:

if (!strcmp(cmd, cmdcheck))

remember, 0 is false, anything else is true in C (not just 1). A lot
of functions in the C/Unix libraries return 0 for sucess (and then set
errno), so most of your calls will be of the if(!function()) style, at
least if you're checking the return value.

Of course the parent was also correct in that you should have the ==
instead of the =, but that goes without saying ;-)

 

[Simon Biber]

actually, you probably want:

if (!strcmp(cmd, cmdcheck))

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.

remember, 0 is false, anything else is true in C (not just 1). A lot
of functions in the C/Unix libraries return 0 for sucess (and then set
errno), so most of your calls will be of the if(!function()) style, at
least if you're checking the return value.

But you can also write the if(function() == 0) style, as it's exactly
the same.

Of course the parent was also correct in that you should have the ==
instead of the =, but that goes without saying ;-)

Indeed.

Simon.

 

[Burton Samograd]

Those two lines have exactly the same effect. Writing (foo == 0) is
equivalent to writing (!foo). If foo has a zero value (or is a null
pointer) then the result is 1, otherwise the result is 0.

Yes, but one seems a bit more clear than the other, and since he's a
bit new, I thought I would point that out to him, not the other
experts around here

But you can also write the if(function() == 0) style, as it's exactly
the same.

Well, it doesn't seem as clear to me stylisticly (and it's also
shorter), and although teachers are pushing the == 0 style instead of
the ! style, the ! style is still the more 'C like' way to check
return values, at least for unix and standard library.

 

[Kenneth Brody]

Yes, but one seems a bit more clear than the other, and since he's a
bit new, I thought I would point that out to him, not the other
experts around here

"A bit more clear", but "wrong". "Wrong" in the sense that strcmp()
returns zero if the strings compare equal, and using "!strcmp()" gives
the impression that you want "not equal", as in "the comparison failed".

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Default User]

Well, it doesn't seem as clear to me stylisticly (and it's also
shorter), and although teachers are pushing the == 0 style instead of
the ! style, the ! style is still the more 'C like' way to check
return values, at least for unix and standard library.

I have the exact opposite opinion. I feel the == form is clearer for
new learners of the language than applying the ! operator.



Brian

 

[Chuck Faranda]

I appreciate the insight in to the different ways to do this, it's helpful
in understanding the logic.

 

[Keith Thompson]

Yes, but one seems a bit more clear than the other, and since he's a
bit new, I thought I would point that out to him, not the other
experts around here

I agree that one is clearer than the other; I disagree about which one
it is.

Personally, I use !, and other operations that act on boolean values,
only for values that really are boolean. The strcmp() function yields
one of three possible kinds of result: <0, ==0, >0. If its name were
"strings_differ(), I'd happily write (!strings_differ(cmd, chdcheck)),
but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.

Yes, this is largely a matter of style, and plenty of smart people
prefer the !strcmp() form.

 

[Keith Thompson]

I have the exact opposite opinion. I feel the == form is clearer for
new learners of the language than applying the ! operator.

I find the == form much clearer for myself, and I've been using the
language on and off for about a quarter century.

 

[Default User]

I find the == form much clearer for myself, and I've been using the
language on and off for about a quarter century.

I would not disagree. I tended to use the ! form years back, but use
the == version these days.



Brian

 

[Keith Thompson]

"A bit more clear", but "wrong". "Wrong" in the sense that strcmp()
returns zero if the strings compare equal, and using "!strcmp()" gives
the impression that you want "not equal", as in "the comparison failed".

If you think of strcmp(x, y) as meaning that the strings x and y are
unequal, !strcmp(x, y) makes sense. I suspect that those programmers
who are comfortable with the "!" form do think of it that way, at
least in that context. I'm not, and I don't -- but as C programmers,
we all need to be able to deal with code written by programmers who
don't think about these things quite the same way we do.

Write code that's as clear as possible. Be prepared to read code
written by programmers who *don't* write code that's as clear as
possible, or who have different opinions about what's clear than you
do.

 

[Vladimir S. Oka]

Chuck Faranda opined:

I appreciate the insight in to the different ways to do this, it's
helpful in understanding the logic.

Please don't top-post.

Your reply belongs below, or interspersed with the text you're replying
to. Especially, don't stick quoted text below your signature, as most
sane news readers will not quote it automatically (see how most of
your post is missing from mine). It then becomes difficult for others
to post a well-formed reply.

--
The only "intuitive" interface is the nipple. After that, it's all
learned. (Bruce Ediger, (e-mail address removed), in comp.os.linux.misc,
on X interfaces.)

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

 

[jaysome]

I agree that one is clearer than the other; I disagree about which one
it is.

Personally, I use !, and other operations that act on boolean values,
only for values that really are boolean. The strcmp() function yields
one of three possible kinds of result: <0, ==0, >0. If its name were
"strings_differ(), I'd happily write (!strings_differ(cmd, chdcheck)),
but since the name of the function doesn't indicate a boolean result,
I find it a bit confusing to treat it as if it did.

An explicit comparison, (strcmp(cmd, cmdcheck) == 0) makes it much
clearer what's actually going on.

Yes, this is largely a matter of style, and plenty of smart people
prefer the !strcmp() form.

Keith, you are right on. A true Boolean variable should use Boolean
opeartors such as !, and never comparison operators such as ==. A
Boolean value by definition has a binary state, so the C standard
supports it quite nicely:

/* The true condition */
if ( is_on )

/* The false condition */
if ( !is_on )

There is no reason whatsoever to compare a Boolean value to another
value like this:

if ( is_on == TRUE )

or like this:

if ( is_on == FALSE )

or like the myriad other variations of these.

See the C FAQ Section 5.3 for further info:

http://c-faq.com/

 

[Chris Hills]

Hi Chuck

You are in completely the wrong NG

try comp.arch.embedded

This lot have no idea about embedded C much less about PIC C they only
do standard ISO C.

there are a lot more people how understand PICs on comp.arch.embedded

regards
Chris

 

[Chuck Faranda]

Hi Chuck

You are in completely the wrong NG

try comp.arch.embedded

This lot have no idea about embedded C much less about PIC C they only
do standard ISO C.

there are a lot more people how understand PICs on comp.arch.embedded

Thanks Chris, I will try there. The replies thus far have been helpful in
other areas though.

Chuck

 

[Richard Bos]

Keith, you are right on. A true Boolean variable should use Boolean
opeartors such as !, and never comparison operators such as ==. A
Boolean value by definition has a binary state, so the C standard
supports it quite nicely:

/* The true condition */
if ( is_on )

/* The false condition */
if ( !is_on )

There is no reason whatsoever to compare a Boolean value to another
value like this:

if ( is_on == TRUE )

or like this:

if ( is_on == FALSE )

or like the myriad other variations of these.

Imprimis, this is a style matter; if someone finds an explicit mention
of TRUE or FALSE clearer than the presence or absence of a !, is that a
problem?
Secundis, while I do agree with your style myself, there is one place
where you can't escape using == on boolean values without jumping
through silly hoops:

if (left_valve_open == right_valve_open)

Richard