Searching \ for '[PIC]Function declaration causes error in one prog' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Function declaration causes error in one prog'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]Function declaration causes error in one prog'
2010\02\25@120938 by Jason Hsu

picon face
The code is as follows:

void delay_1_msec (void)
       {
       count = 110;
       while (count>0)
               {
               count--;
               }
       }

Everything compiles and works when I use this function declaration in Program A.

I have a second program, Program B that also works as expected.

However, when I cut and paste this code snippet from Program A to
Program B (which also worked), Program B refuses to compile (even with
the line calling the function commented out).  The errors I'm getting
are:
no identifier in declaration

missing basic type; int assumed

";" expected

Given that this same code worked in another program, I doubt that this
is a syntax error.  Yes, I have declared the variable count as an
unsigned char.  In fact, I have a similar pre-existing function in
Program B that caused no problems.  The function declaration is:

void delay_20_usec(void)
       {
       count = 2;
       while (count>0)
               {
               count--;
               }
       }

What am I overlooking?

--
Jason Hsu
http://www.jasonhsu.com/swrwatt.html
http://www.jasonhsu.com/swrwatt-c.txt
http://www.jasonhsu.com/swrwatt-asm.txt

2010\02\25@121409 by Jason Hsu

picon face
When I comment out the new function in Program B as follows:
//void delay_1_msec (void)
       //{
       //count = 110;
       //while (count>0)
               //{
               //count--;
               //}
       //}

Program B compiles as expected.  Uncommenting these lines stops the
program from compiling.  So I have confirmed that there is a problem
with my function declaration, but I can't for the life of me figure
out what it is.


--
Jason Hsu
http://www.jasonhsu.com/swrwatt.html
http://www.jasonhsu.com/swrwatt-c.txt
http://www.jasonhsu.com/swrwatt-asm.txt

2010\02\25@121915 by Alan B. Pearce

face picon face
>missing basic type; int assumed
>
>";" expected

This often means you are missing an ';' earlier in the program.

2010\02\25@122353 by sergio masci

flavicon
face


On Thu, 25 Feb 2010, Jason Hsu wrote:

{Quote hidden}

Check your source code (including header files) to see if 'delay_1_msec'
has been delared as a macro (or manifest constant).

Check that you have actually inserted the code in a place that is valid.

e.g.

       int        fred
               bert;

changed to


       int        fred

void delay_1_msec (void)
       {
       count = 110;
       while (count>0)
               {
               count--;
               }
       }


               bert;


Regards
Sergio masci

2010\02\25@124113 by Ariel Rocholl

flavicon
face
Your function has an obvious dependency on "count" variable being globally
defined.

Have you defined it on the new program before this function is declared?

2010/2/25 sergio masci <spam_OUTsmplxTakeThisOuTspamallotrope.net>

{Quote hidden}

> -

2010\02\25@124537 by Peter

picon face
>        count = 110;
       int count = 110;

unless count is a global variable

 Peter

2010\02\25@125147 by Mark E. Skeels

flavicon
face
Did you try defining a local var count within the function to see if the
error goes away?

Mark

Ariel Rocholl wrote:
{Quote hidden}

>> --

2010\02\25@130612 by Jason Hsu

picon face
Thanks for all of your responses.  I still have not resolved the
issue, but I have eliminated some possibilities:
1.  Renaming delay_1_msec did not solve the problem, so I don't think
this function was already defined.
2.  Making the count variable local instead of global didn't solve the problem.

I get the feeling that there is something I omitted that
intermittently causes problems (much like the RA4=0 issue in the other
thread - omitting this command was a mistake even though another
program worked without it).

Maybe my way of creating a delay is inferior and needs to be replaced
with something better.

--
Jason Hsu
http://www.jasonhsu.com/swrwatt.html
http://www.jasonhsu.com/swrwatt-c.txt
http://www.jasonhsu.com/swrwatt-asm.txt

2010\02\25@133213 by Isaac Marino Bavaresco

flavicon
face
Em 25/2/2010 14:09, Jason Hsu escreveu:
{Quote hidden}

As others pointed out, it may be that you forgot to declare 'count' in
the other program, or perhaps you defined a macro that has the same name
as some symbol in your function.

It is not good practice to rely in globally declared variables,
specially in this case, where the variable is obviously never needed
outside the function. Declare the 'count' variable inside you function
instead.

Why don't you instead of:

void delay_20_usec(void)
       {
       count = 2;
       while (count>0)
               {
               count--;
               }
       }


Just use:

void delay_20_usec(void)
       {
       char count;

       for( count = 2; count != 0; count-- );
       }


The 'for' construct is much more concise, elegant and easier to understand.


Best regards,

Isaac
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\02\25@133221 by William \Chops\ Westfield

face picon face

On Feb 25, 2010, at 10:06 AM, Jason Hsu wrote:

> 2.  Making the count variable local instead of global didn't solve  
> the problem.

What about renaming the variable as well as making it local (using  
global variables for this sort of thing is ... bad.)

As a general technique for debugging more obscure C problems, you can  
try running your program through the pre-processor only (it'd be -E on  
a standard unix-like compiler.  YMMV.)  Looking at the pre-processed  
output can be ... very educational.

BillW

2010\02\25@134256 by Isaac Marino Bavaresco

flavicon
face
Em 25/2/2010 15:06, Jason Hsu escreveu:
> Thanks for all of your responses.  I still have not resolved the
> issue, but I have eliminated some possibilities:
> 1.  Renaming delay_1_msec did not solve the problem, so I don't think
> this function was already defined.
> 2.  Making the count variable local instead of global didn't solve the problem.
>
> I get the feeling that there is something I omitted that
> intermittently causes problems (much like the RA4=0 issue in the other
> thread - omitting this command was a mistake even though another
> program worked without it).
>
> Maybe my way of creating a delay is inferior and needs to be replaced
> with something better.
>  

The problem you mentioned is a compile-time one, it is not intermittent
and will last until you solve the error in your source code.

If making the 'count' variable local didn't solve the problem, one
possible alternative is that you have #define'd some symbol (the
function or variable names) to something else.

Another thought, perhaps the problem is in the code above or in some
#include and the error is only detected when parsing the function. It
may be anything, including a missed '}'.


Best regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\02\25@135848 by Jason Hsu

picon face
Thank you for all of your suggestions.

I resolved my problem by bypassing it entirely.  Instead, I'm using
the delay functions in the <htc.h> file.  It was much easier to just
follow the example in the samples directory that came with the PICC
software installation.  It's hard to argue with the successful record
of the HTSOFT/PICC developers, so I'm using their delay routines
instead of creating my own.

All I had to add to the beginning of the program was:
#define _XTAL_FREQ 3579450 // Provide the frequency of the crystal,
necessary for using the delay functions
#include <htc.h> // Needed to access the delay functions.

I used the following commands to call the delay function in my program:
__delay_us(20);
__delay_ms (10);

--
Jason Hsu
http://www.jasonhsu.com/swrwatt.html
http://www.jasonhsu.com/swrwatt-c.txt
http://www.jasonhsu.com/swrwatt-asm.txt

2010\02\25@152125 by ivp

face picon face
> #define _XTAL_FREQ 3579450

Jason, I thought originally that 3579450 was a typo for 3579545.
It seems 3.579450MHz crystals do exist. I'm wondering what they
might be made for. 0x369E3A doesn't seem to have any immediately
obvious factors. 350 ? 487 ? 735 ?

wbr

2010\02\25@154108 by sergio masci

flavicon
face


On Thu, 25 Feb 2010, Jason Hsu wrote:

{Quote hidden}

Jason I understand your frustration and eagerness to move forward BUT your
understanding of compile time problems, how to identify the cause and fix
them is really important! You need to be in control of the compiler. You
should not compromise simply because you don't understand what the problem
is. If you want to be an "outstanding embedded engineer" view problems
such as this as an opertunity to learn.

Regards
Sergio Masci

2010\02\25@194903 by Sean Breheny

face picon face
I cannot stress enough that Alan is right. I highly suspect that this
problem is caused by a missing semicolon somewhere. Can you post the
entire file or send it to my personal email as a ZIP file?

Take a look right before the line "void delay_1_msec (void)" to see if
there is a missing semi-colon. This will often cause a whole cascade
of puzzling errors.

Sean


On Thu, Feb 25, 2010 at 12:19 PM, Alan B. Pearce
<Alan.B.PearcespamKILLspamstfc.ac.uk> wrote:
>>missing basic type; int assumed
>>
>>";" expected
>
> This often means you are missing an ';' earlier in the program.
> -

2010\02\26@041127 by Alan B. Pearce

face picon face
> The 'for' construct is much more concise, elegant
> and easier to understand.

;))) Not according to Chuck Hellebuyuk that wrote "Beginners Guide to
Embedded C Programming" (available through Microchip). He also doesn't like
the ++ and += styles of notation ...

2010\02\26@041525 by Alan B. Pearce

face picon face
>Thank you for all of your suggestions.
>
>I resolved my problem by bypassing it entirely.

I think you have missed the point - there is something else wrong in your
code, and it is likely to come back and bite you.

I haven't seen any suggestion that you checked your code to see if my
suggestion is valid - namely that you are missing a ';' earlier than point
where you inserted that delay routine. I have seen this produce the very
same error message you are seeing. If a ';' is missing, then this means that
something else is badly defined in your code, and while it may compile, it
is not doing what you thing it should be doing.

2010\02\26@042552 by Vitaliy

face
flavicon
face
Alan B. Pearce wrote:
>> The 'for' construct is much more concise, elegant
>> and easier to understand.
>
> ;))) Not according to Chuck Hellebuyuk that wrote "Beginners Guide to
> Embedded C Programming" (available through Microchip). He also doesn't
> like
> the ++ and += styles of notation ...

You know, I use the ++ notation myself, but I choose not to use the += style
notation, because in my mind it's a C-ism that makes the code less readable
while offering no real benefit. Maybe it made sense when screens were 80
characters wide?

Vitaliy

2010\02\26@042625 by Wouter van Ooijen

face picon face
> I think you have missed the point - there is something else wrong in your
> code, and it is likely to come back and bite you.

I agree, but I would have phrased it a bit more, eh, Olin-like.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\02\26@053953 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam.....mit.edu [EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu] On
Behalf
{Quote hidden}

to
> > Embedded C Programming" (available through Microchip). He also
doesn't
> > like
> > the ++ and += styles of notation ...
>
> You know, I use the ++ notation myself, but I choose not to use the +=
> style
> notation, because in my mind it's a C-ism that makes the code less
> readable
> while offering no real benefit. Maybe it made sense when screens were
80
> characters wide?
>
> Vitaliy

It makes sense to me in the context of a mid-level language; in
assembler an add instruction will typically add the value of one
register to an accumulator or another register and that's the entire
operation

e.g.

   movf b,W
   addwf a,F

which is nicely equivalent to:

   a += b;


The long hand expression implies two distinct operations i.e. the
addition itself and the moving of the result:

   a = b + c

   movf b,W
   addwf c,W
   movwf a

The move is clearly redundant when the result is stored in one of the
original operands, and obviously no modern compiler worthy of
consideration would actually include a redundant move.  However I'm
wondering if this was helpful for early compilers, i.e. that operation
would produce more efficient code without using an optimiser?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2010\02\26@173026 by Isaac Marino Bavaresco

flavicon
face
Em 26/2/2010 06:11, Alan B. Pearce escreveu:
>> The 'for' construct is much more concise, elegant
>> and easier to understand.
>>    
> ;))) Not according to Chuck Hellebuyuk that wrote "Beginners Guide to
> Embedded C Programming" (available through Microchip). He also doesn't like
> the ++ and += styles of notation ...
>  

I could write a book myself, saying what I like and what I don't, in
programming style...

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\02\26@191310 by sergio masci

flavicon
face


On Fri, 26 Feb 2010, Isaac Marino Bavaresco wrote:

{Quote hidden}

What did Chuck Hellebuyuk say is bad about 'for' constructs?

Personally I think they are good (not so much the 'C' version - too lax)
but in general. They allow the compiler to better understand the intent of
the programmer.

Regards
Sergio Masci

2010\02\26@191838 by sergio masci

flavicon
face


On Fri, 26 Feb 2010, Michael Rigby-Jones wrote:

> However I'm
> wondering if this was helpful for early compilers, i.e. that operation
> would produce more efficient code without using an optimiser?

Certainly VERY helpful for interpretors. If you look back into the dim and
distant past you will find that 'C' was derived from 'B' which was
interpreted.

IIRC you will also find that 'C' used to have a '=+' operator which was
the same '+='

Regards
Sergio masci

2010\02\26@194125 by Isaac Marino Bavaresco

flavicon
face
On 27/2/2010 00:58, sergio masci wrote:
{Quote hidden}

The most important advantage of 'for' in C is that the initialization
and step sequences are clearly visible.
With the 'while', the initialization sequence is not obviously linked to
the block itself, being easier to overlook or forget to copy/move
together, and the step sequence is not separated from the "worker"
statements.


Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\02\26@195757 by Marcel Birthelmer

picon face
> The most important advantage of 'for' in C is that the initialization
> and step sequences are clearly visible.
> With the 'while', the initialization sequence is not obviously linked to
> the block itself, being easier to overlook or forget to copy/move
> together, and the step sequence is not separated from the "worker"
> statements.


It's also a bit different in terms of when the "step sequence" is
executed. In a for loop, a 'continue' will execute the step sequence -
in a while loop, you have to do it manually for each continue
statement (or use some unnecessarily complicated branching to execute
it always).

2010\02\27@080541 by sergio masci

flavicon
face


On Fri, 26 Feb 2010, Isaac Marino Bavaresco wrote:

{Quote hidden}

I understand your point of view but it goes much deeper than that. By
telling the compiler "this is a controlled loop, with this initial value,
this terminating condition and this step" the compiler is able to check
the construct for special situations that are (or potentially are) errors.
The compiler is also better able to generate much more optimised code.

consider:

       int        j;
       int        arr[1000];

       for (j=200; j<300; j++)
       {
               arr[j] = 0;
       }

a decent compiler could optimise this to

       unsigned char k;
       int        arr[1000];
       int        *ptr;

       for (k=100, ptr=arr+200; k!=0; k--, ptr++)
       {
               *ptr = 0;
       }

It could also look at something like

       for (j=200; j<300; k++)
       {
               arr[j] = 0;
       }

and flag 'k++' as a probable error


Regards
Sergio Masci

2010\02\27@081354 by sergio masci

flavicon
face


On Fri, 26 Feb 2010, Bob Ammerman wrote:

{Quote hidden}

Granted but a decent compiler can easily inspect the above 'for' loop and
replace it with the preceading while 'loop' equivalent. Going the other
way would be MUCH harder. So there is an advantage to having a 'for' loop
construct in addition to a 'while' loop construct.

>
> or sometimes even:
>
> for (i=10; i !=0;--i)
>     ;

There is no excuse for a compiler that generates inferior code in this
case.

But I ask again specifically why does Chuck Hellebuyuk depricate 'C' 'for'
loops?

Regards
Sergio Masci

2010\02\28@113411 by Alan B. Pearce

face picon face
>But I ask again specifically why does Chuck Hellebuyuk
>depricate 'C' 'for' loops?

It is the syntax he doesn't like. I'll have to look at the book tomorrow
(its at work) as I cannot remember what his preferred layout of the syntax
was, but it just struck me as a strange way of looking at things. Personally
I find the for loop syntax fine.

But for adding things together he would much rather have a = a + b than a +=
b and similarly a = a + 1 than a++. Frankly a decent compiler should be able
to compile to identical code or either version of each instance, so this
probably isn't such a hassle, but to me the for loop is a nice syntax.

2010\02\28@115711 by Russell McMahon

face picon face
Jason,

I'm very surprised that you have not responded to the several comments
re a possibly missing prior ";".

This is a reasonably likely cause of your original problem.
If it is THE reason then you have a 'time bomb" waiting to catch you
out at some future date.
Murphy says it will probably be just before you very very very
urgently need the program to compile in order to meet an important
deadline.

If Olin were commenting on this he would by now be very rudely
pointing out that pursuit of excellence and asking for people's advice
both make it desirable that you try out good and simple suggestions
rather than ignoring what people say, that you respect the time they
are spending on you by at least considering what they say after you
have asked for their help, and if you have done what's suggested and
found that it's not the problem, that you let people know that you
have done so. So, in the absence of Olin to put this point rudely,
I'll put it politely as above :-).

Finding the cause of obscure and annoying "faults" is a major source
of quality learning experience, and a good survival habit. Every now
and then you find that it's a compiler peccadillo. Whatever it is, not
finding it is very dangerous for your program's health.


                  Russell

2010\02\28@234730 by Jason Hsu

picon face
I still haven't had any luck figuring out what was causing my problem.

I have uploaded my code (an older version that had this problem) to
http://www.jasonhsu.com/swrwatt_2010_0224_2131.c .  The code as is
will compile.  Uncommenting the delay_1_msec declaration will cause
the error to show up.

I agree that I need to figure out why I was getting these cryptic
function declaration errors even though the same offending lines
(verbatim) had no such effect in another program.  As a student and as
an engineer, I have found all too often that political pressure has
encouraged me to just get the job done rather than take the time to
understand just what I'm doing.  Since I don't have a professor or
boss breathing down my neck over this matter, I cannot use this as an
excuse to pass up this learning opportunity.


'[PIC]Function declaration causes error in one prog'
2010\03\01@001148 by Alex Harford
face picon face
Jason, the strange thing I see is that the newlines are odd looking.
See what it looks like opened on a Linux box in vim:

http://imgur.com/qvgwj

There are ^Ms shown, but where you pasted the code in, there is a ^M
but it didn't cause a newline!?

Maybe a dos2unix / unix2dos pass will straighten things out.

On Sun, Feb 28, 2010 at 8:47 PM, Jason Hsu <jhsu802701spamspam_OUTgmail.com> wrote:
> I still haven't had any luck figuring out what was causing my problem.
>
> I have uploaded my code (an older version that had this problem) to
> http://www.jasonhsu.com/swrwatt_2010_0224_2131.c .  The code as is
> will compile.  Uncommenting the delay_1_msec declaration will cause
> the error to show up.

2010\03\01@001657 by Jason Hsu

picon face
Please use MPLAB to view my code.  That's what I used to create it.

On Sun, Feb 28, 2010 at 11:11 PM, Alex Harford <@spam@harfordKILLspamspamgmail.com> wrote:
> Jason, the strange thing I see is that the newlines are odd looking.
> See what it looks like opened on a Linux box in vim:
>
> http://imgur.com/qvgwj
>
> There are ^Ms shown, but where you pasted the code in, there is a ^M
> but it didn't cause a newline!?
>
> Maybe a dos2unix / unix2dos pass will straighten things out.
>




--
Jason Hsu
http://www.jasonhsu.com/swrwatt.html
http://www.jasonhsu.com/swrwatt-c.txt
http://www.jasonhsu.com/swrwatt-asm.txt

2010\03\01@002239 by Alex Harford

face picon face
I know, but there is something funny going on.  I looked at it with
'xxd' and you have a CR/^M/0x0D with no LF/0x0A, and I will bet that's
confusing the compiler.

I'm willing to bet if you took these lines out:

// This method of providing delays isn't efficient with respect to
clock cycles.  It takes 9 usec to decrement a variable.  However, it
does work.^M// Purists advocate inserting Assembly language into the
code.  My attempts to implement this were not successful.
// Executing delay_1_msec 1000 times takes about 1 sec.^M//void
delay_1_msec (void)

and retyped

void delay_1_msec (void)

with the remaining part of the function uncommented, it would work.

On Sun, Feb 28, 2010 at 9:16 PM, Jason Hsu <KILLspamjhsu802701KILLspamspamgmail.com> wrote:
{Quote hidden}

>

2010\03\01@012234 by Russell McMahon

face picon face
> Please use MPLAB to view my code.  That's what I used to create it.

But, the compiler doesn't care WHAT you created it with OR what someone
viewed it with, it just cares about what's in the file.

It's looking strongly, based on various prior posts, and on Alex's last two,
that the file has content which is interpreted by various things in various
ways and, importantly, the compiler appears to see something that MPLab+your
eyes+ your brain can't see.

It sounds like your system has provided you with an immensely valuable
embedded (and other) programming learning experience :-).

Suggestion:

Try typing in the 'identical" code as you see it after cut and pasting and
then delete the cut and pasted code and see if it compiles OK. If so, THEN
go back and hunt it down and kill it. You then can chalk another "mission
flown" symbol on the side of your cockpit.




  Russell


(Lancaster "G for George", which rests in the brightly lit darkness of the
Canberra National War Memorial Museum in Canberra Australia has (AFAIR)
about 100 mission-flown symbols on the side of its cockpit. Each one denotes
a safely survived wartime mission. Statistically, the odd aircraft has to
manage this sort of result - but happy indeed the crew that get to fly in
it. You'll be a few mission symbols short of that so far I suspect. After
you find your bug you can paint on another one and look forward to the day
that you've achieved 120 missions equivalent :-)).

upload.wikimedia.org/wikipedia/commons/c/cb/G_for_george_panorama.jpg
Despite the artificial look in the photo it's the real thing.










On 1 March 2010 18:16, Jason Hsu <spamBeGonejhsu802701spamBeGonespamgmail.com> wrote:

{Quote hidden}

>   -

2010\03\01@032646 by Dario Greggio

face picon face
Alex Harford ha scritto:
> I know, but there is something funny going on.  I looked at it with
> 'xxd' and you have a CR/^M/0x0D with no LF/0x0A, and I will bet that's
> confusing the compiler.


same here, opening with MSVC's editor
so I'm almost sure it causes problems.

I can save it and send you back the file if you want..

--

Ciao, Dario
--
Cyberdyne

2010\03\01@033412 by Dario Greggio

face picon face
cyberdyne.homeip.net/public/swrwatt_2010_0224_2131.c

--

Ciao, Dario
--
Cyberdyne

2010\03\01@033503 by cdb

flavicon
face

<snip>
:: and similarly a = a + 1 than a++.
</snip>

Strangely enough I have a 'C' compiler that will actually provide
different assembler for

a = a +1

to

a+= 1

One uses movlw and goes through all sorts of contortions and'ing and
or'ing all over the place - the other   inc a .

It even gives different results depending on whether it is part of a
While or For loop.

Colin
--
cdb, RemoveMEcolinspamTakeThisOuTbtech-online.co.uk on 3/1/2010

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359








2010\03\01@061759 by Isaac Marino Bavaresco

flavicon
face
Em 1/3/2010 05:35, cdb escreveu:
{Quote hidden}

So you have an Old School compiler :)

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\03\01@105234 by Bob Ammerman

picon face
>I still haven't had any luck figuring out what was causing my problem.
>
> I have uploaded my code (an older version that had this problem) to
> http://www.jasonhsu.com/swrwatt_2010_0224_2131.c .  The code as is
> will compile.  Uncommenting the delay_1_msec declaration will cause
> the error to show up.
>
> I agree that I need to figure out why I was getting these cryptic
> function declaration errors even though the same offending lines
> (verbatim) had no such effect in another program.  As a student and as
> an engineer, I have found all too often that political pressure has
> encouraged me to just get the job done rather than take the time to
> understand just what I'm doing.  Since I don't have a professor or
> boss breathing down my neck over this matter, I cannot use this as an
> excuse to pass up this learning opportunity.

Jason,

IIRC you are including some compiler-specific file in the version of the
program that doesn't work. Is it possible that somewhere in those includes
there is a

   #define delay_1_msec

This could certainly cause much trouble.

One way to check for this, or similar macro hosings is to get your compiler
to output a preprocessed source and take a look at it.

-- Bob Ammerman
RAm Systems

2010\03\01@110221 by Jason Hsu

picon face
Thanks, Alex.  As you suspected, the problem turned out to be in the
comment lines immediately preceding the delay_1_msec function
declaration.  The errors disappeared once I removed those comment
lines.

Now I understand why it's so important to archive the source code as
you accomplish various things while working on a program.  Even
comment lines can be misinterpreted by a compiler.

How can comment lines be misinterpreted by a compiler?  Comment lines
are SUPPOSED to be ignored by the compiler.  What went wrong here?

More importantly, how do you tell if a compiler is misinterpreting
your source code?  My code looked fine in MPLAB, Geany, and Leafpad.
I don't know how I'm supposed to tell if I'm relying on editing tools
that don't show me what the compiler sees.

On Sun, Feb 28, 2010 at 11:22 PM, Alex Harford <harfordEraseMEspam.....gmail.com> wrote:
{Quote hidden}

--
Jason Hsu
http://www.jasonhsu.com/swrwatt.html
http://www.jasonhsu.com/swrwatt-c.txt
http://www.jasonhsu.com/swrwatt-asm.txt

2010\03\01@113249 by Alex Harford

face picon face
On Mon, Mar 1, 2010 at 8:02 AM, Jason Hsu <EraseMEjhsu802701spamgmail.com> wrote:
>
> How can comment lines be misinterpreted by a compiler?  Comment lines
> are SUPPOSED to be ignored by the compiler.  What went wrong here?
>
> More importantly, how do you tell if a compiler is misinterpreting
> your source code?  My code looked fine in MPLAB, Geany, and Leafpad.
> I don't know how I'm supposed to tell if I'm relying on editing tools
> that don't show me what the compiler sees.

It's not the comment lines, it's the EOL marker which is handled
differently between Unix and DOS.

http://en.wikipedia.org/wiki/Newline

But like I said earlier, you had a very weird case where you had the
CR character, but not the LF!  I noticed that you mentioned earlier
you were doing this in Linux under WINE... perhaps it was a bug in the
cut and paste between those systems.

2010\03\01@115823 by Bob Ammerman

picon face


>I know, but there is something funny going on.  I looked at it with
>'xxd' and you have a CR/^M/0x0D with no LF/0x0A, and I will bet that's
>confusing the compiler.

If that's what is confusing the compiler then the compiler is broken. CR and
LF are both defined as whitespace characters and any number of consecutive
whitespace characters is treated as equivalent to a single space.

-- Bob Ammerman
RAm System

2010\03\01@120534 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesEraseMEspamEraseMEmit.edu [RemoveMEpiclist-bouncesspam_OUTspamKILLspammit.edu] On
Behalf
> Of Jason Hsu
> Sent: 01 March 2010 16:02
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC]Function declaration causes error in one program but
not
{Quote hidden}

I've had odd control characters in source code causing compilation
issues in the past.  I'm not sure how they got there but some kind of
copy/paste bug is the most likely. This kind of thing is certainly
'interesting' to track down if it's the first time you've experienced
it.

Most text editors will not show non-printing characters by default; the
source would look a mess otherwise.  However, decent editors will either
have an option to display line breaks (carriage returns/linefeeds) or
you can view the file in a hex editor and check the suspect lines for
any odd characters.  MPLAB has never had what I would call a decent
editor...

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2010\03\01@121502 by Dave Tweed

face
flavicon
face
Bob Ammerman wrote:
> > I know, but there is something funny going on.  I looked at it with
> > 'xxd' and you have a CR/^M/0x0D with no LF/0x0A, and I will bet that's
> > confusing the compiler.
>
> If that's what is confusing the compiler then the compiler is broken. CR and
> LF are both defined as whitespace characters and any number of consecutive
> whitespace characters is treated as equivalent to a single space.

Well, yes, but the concept of "newline" is still significant, especially
with //-style comments.

In this case, the compiler is not recognizing a bare CR as a newline, and
therefore, the first line of the function definition is being commented out.

-- Dave Tweed

2010\03\01@121536 by Jan-Erik Soderholm

face picon face


On 2010-03-01 17:58, Bob Ammerman wrote:
>
>
>> I know, but there is something funny going on.  I looked at it with
>> 'xxd' and you have a CR/^M/0x0D with no LF/0x0A, and I will bet that's
>> confusing the compiler.
>
> If that's what is confusing the compiler then the compiler is broken. CR and
> LF are both defined as whitespace characters and any number of consecutive
> whitespace characters is treated as equivalent to a single space.
>
> -- Bob Ammerman
> RAm System
>

whitespace != newline.

2010\03\01@122655 by Mark E. Skeels

flavicon
face
This is really cool!

Mark Skeels
Engineer
Competition Electronics, Inc.
TEL: 815-874-8001
FAX: 815-874-8181
http://www.competitionelectronics.com


Dave Tweed wrote:
{Quote hidden}

2010\03\01@123153 by Jan-Erik Soderholm

face picon face
On 2010-03-01 18:15, Dave Tweed wrote:
> Bob Ammerman wrote:
>>> I know, but there is something funny going on.  I looked at it with
>>> 'xxd' and you have a CR/^M/0x0D with no LF/0x0A, and I will bet that's
>>> confusing the compiler.
>>
>> If that's what is confusing the compiler then the compiler is broken. CR and
>> LF are both defined as whitespace characters and any number of consecutive
>> whitespace characters is treated as equivalent to a single space.
>
> Well, yes, but the concept of "newline" is still significant, especially
> with //-style comments.
>
> In this case, the compiler is not recognizing a bare CR as a newline, and
> therefore, the first line of the function definition is being commented out.
>
> -- Dave Tweed


Another thing that I do not think have been mentioned here yet...

The *list file* from the compiler should tell what the actual
interpretation of the input file was. It should tell if what
looks like multiple lines was read as a single line by the
compiler, not ?

Jan-Erik.

2010\03\01@123635 by Bob Ammerman

picon face
> Well, yes, but the concept of "newline" is still significant, especially
> with //-style comments.
>
> In this case, the compiler is not recognizing a bare CR as a newline, and
> therefore, the first line of the function definition is being commented
> out.
>
> -- Dave Tweed

Now it makes sense.

-- Bob Ammerman
RAm Systems

2010\03\01@130034 by William \Chops\ Westfield

face picon face

On Mar 1, 2010, at 9:31 AM, Jan-Erik Soderholm wrote:

> The *list file* from the compiler should tell what the actual
> interpretation of the input file was.

Looking at the pre-processor output would have shown this as well.

BillW

2010\03\01@130035 by William \Chops\ Westfield

face picon face

On Mar 1, 2010, at 8:02 AM, Jason Hsu wrote:

> How can comment lines be misinterpreted by a compiler?  Comment lines
> are SUPPOSED to be ignored by the compiler.  What went wrong here?

You used the "//" form of comments, which are terminated by an end-of-
line, with an editor that showed/treated a bare CR as end-of-line, and  
a compiler that didn't.

I blame the editor.  EOL these days is either CRLF (windows, netascii)  
or just LF (unix.)  CR has never been an end-of-line except when  
received from a keyboard.

BillW

2010\03\01@130102 by William \Chops\ Westfield

face picon face

On Mar 1, 2010, at 8:02 AM, Jason Hsu wrote:

> How can comment lines be misinterpreted by a compiler?  Comment lines
> are SUPPOSED to be ignored by the compiler.  What went wrong here?

You used the "//" form of comments, which are terminated by an end-of-
line, with an editor that showed/treated a bare CR as end-of-line, and  
a compiler that didn't.

I blame the editor.  EOL these days is either CRLF (windows, netascii)  
or just LF (unix.)  CR has never been an end-of-line except when  
received from a keyboard.

BillW

2010\03\01@135517 by Dave Tweed

face
flavicon
face
William "Chops" Westfield wrote:
> I blame the editor.  EOL these days is either CRLF (windows, netascii)  
> or just LF (unix.)  CR has never been an end-of-line except when  
> received from a keyboard.

AIUI, Apple MacOS uses bare CR to represent newline, at least through
version 9. I've never used one, so I wouldn't know. And the OP never
mentioned a Mac being used anywhere in this process.

-- Dave Tweed

2010\03\01@141752 by Bob Ammerman

picon face

> I blame the editor.  EOL these days is either CRLF (windows, netascii)  
> or just LF (unix.)  CR has never been an end-of-line except when  
> received from a keyboard.
>
> BillW

Or on a MAC
Or on a Data General system
Or on...

-- Bob Ammerman
RAm Systems

2010\03\01@171855 by Jason Hsu

picon face
I compiled the suspect version of my program, uncommented the
declaration of delay_1_msec,  and looked at the *.pre file.

I found that the line "void delay_1_msec (void)" was missing.  The
other function declaration lines (like the one for the delay_20_usec
function) was unaffected.

So the preprocessor apparently ignored the "void delay_1_msec (void)"
line.  From other replies, it seems that the preprocessor interpreted
this line as part of the previous line (which is a comment).

The big question: When you create a new line in your C code, how do
you make sure that the preprocessor recognizes it as a new line rather
than part of the previous line?

--
Jason Hsu
http://www.jasonhsu.com/swrwatt.html
http://www.jasonhsu.com/swrwatt-c.txt
http://www.jasonhsu.com/swrwatt-asm.txt

2010\03\01@175225 by Jan-Erik Soderholm

face picon face
On 2010-03-01 23:18, Jason Hsu wrote:
> I compiled the suspect version of my program, uncommented the
> declaration of delay_1_msec,  and looked at the *.pre file.
>
> I found that the line "void delay_1_msec (void)" was missing.  The
> other function declaration lines (like the one for the delay_20_usec
> function) was unaffected.
>
> So the preprocessor apparently ignored the "void delay_1_msec (void)"
> line.  From other replies, it seems that the preprocessor interpreted
> this line as part of the previous line (which is a comment).
>
> The big question: When you create a new line in your C code, how do
> you make sure that the preprocessor recognizes it as a new line rather
> than part of the previous line?
>

Very few editors today would make it into anything else then
a true "newline". In particular if you create this new line in
the same enviroment as where the compile runs. I do not remember
the thread history, but wasn't the actual lines copied from
some other environment ?

So in short, this isn't a problem realy and you will probably not
see it again in many years, so don't bother...

Jan-Erik.

2010\03\01@180006 by Lee Jones

flavicon
face
William "Chops" Westfield wrote:
>> I blame the editor.  EOL these days is either CRLF (windows,
>> netascii) or just LF (unix.)  CR has never been an end-of-line
>> except when received from a keyboard.

> AIUI, Apple MacOS uses bare CR to represent newline, at least
> through version 9. I've never used one, so I wouldn't know.
>
> -- Dave Tweed

That was true for the old Mac operating system.  With the release
of Mac OS X, it is a Unix core with a pretty GUI on top.  Standard
line terminator is now linefeed (like every other Unix around).
I spend most of my day in a terminal window on a Mac -- it's Unix.

There are a few old programs that still require carriage return
as line terminator.  But they are rare.

                                               Lee Jones

2010\03\01@203933 by Russell McMahon

face picon face
> > The big question: When you create a new line in your C code, how do
> > you make sure that the preprocessor recognizes it as a new line rather
> > than part of the previous line?

> Very few editors today would make it into anything else then
> a true "newline". In particular if you create this new line in
> the same enviroment as where the compile runs. I do not remember
> the thread history, but wasn't the actual lines copied from
> some other environment ?

> So in short, this isn't a problem realy and you will probably not
> see it again in many years, so don't bother...

Let me translate that into Murphy-language, lest the lesson be lost :-) :

The problem was apparently caused by cutting and pasting between two
systems which dealt with the end of line condition differently.

This will very very likely never happen if a single system, or set of
consistently behaving systems* are used.

(*"A set of consistently behaving systems" is any set of systems in
which you have not yet found an inconsistency.**)

So you are quite likely to not see this again for a long while.

*SO* note very very very carefully what happened and why and how it
may apply in the most general terms to other similar and even not
similar actions, so that when it finally does happen again you have
enough memory of this event that the priosr knowledge process
invaluable.

Note that Murphy seems to know how long one's memory span is and what
the lesson was that we learned, and waits a suitable time before
providing a similar problem which we might otherwise solve too easily.



     Russell


** Similarlly: A bug free program is a program in which the latest bug
has not yet been noticed.

2010\03\02@013516 by cdb

flavicon
face
May I suggest you look at EditPad pro as an IDE it will convert Unix
style to Window styles and variations in between - not free requires
payment, think it only has a Windows version.

It understands the 'c' language so will indent and do all sorts of
wonderful stuff, you can even command line to your
assembler/programmer.

Colin
--
cdb, RemoveMEcolinTakeThisOuTspamspambtech-online.co.uk on 3/2/2010

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359






2010\03\02@072807 by Isaac Marino Bavaresco

flavicon
face
Em 2/3/2010 03:35, cdb escreveu:
> May I suggest you look at EditPad pro as an IDE it will convert Unix
> style to Window styles and variations in between - not free requires
> payment, think it only has a Windows version.
>
> It understands the 'c' language so will indent and do all sorts of
> wonderful stuff, you can even command line to your
> assembler/programmer.
>
> Colin
>  

Perhaps this message would be better off with [AD] tag, but I would
suggest Notepad++, for Windows only, but free and open source.


Isaac
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\03\02@082129 by sergio masci

flavicon
face


On Mon, 1 Mar 2010, Bob Ammerman wrote:

{Quote hidden}

I wish it were that simple :-)

A compiler relies on end-of-line (whatever you decide it should be) to
identify where in the source an error has occured. Not only that, but if
the compiler is to emit source level debug information for the debugger
(so that it can display where in the source the executing program is) then
this is another reason why the compiler needs to differentiate between
white spase and end-of-line.

end-of-line needs to be well defined and strictly observed. What
combination of CR/LF is treated as a end-of-line? If the compiler
encounters CR on its own should it be treated as end-of-line? Should CR/LF
be treated the same as LF/CR? Should CR/CR/LF be treated as 1 end-of-line
or 2? What about LF/LF/CR? what happens when you mix and match LF and CR
as end-of-line in the same source? How many end-of-line is one "vertical
tab" or "form feed" equivalent too?

It is far far simpler for the compiler (or preprocessor) to catch
unexpected special characters and flag these as an error and use the
system wide well defined end-of-line than it is for the compiler to guess
what an out of place special character should actually mean.

Regards
Sergio Masci

2010\03\02@083959 by sergio masci

flavicon
face


On Tue, 2 Mar 2010, Russell McMahon wrote:

{Quote hidden}

Actually I see this several times a year. It's one of the joys of
maintaining systems that run on both unix and windoz. But it's normally an
imported header file that causes the problem not a cut and paste (I think
the editors are trying to be too clever here).

The end-of-line problem had crossed my mind when Jason originally posted
but after several responses from others it seemed that Jason wasn't
interested in pursuing the problem so I also lost interest in trying to
help.

The funniest similar problem I came across many years ago involved a
makefile with a backslash at the end of a line (for continuation). For
those that don't know, putting a backslash at the end of the line escapes
the following end-of-line. After a lot of head scratching as to why the
make file wasn't working as expected it was discovered that there was a
space character after the backslash and before the end-of-line. You
couldn't see the space so the line looked ok. Once the space was removed
everything worked as expected.

Regards
Sergio Masci

2010\03\02@115346 by Russell McMahon

face picon face
> end-of-line needs to be well defined and strictly observed. What
> combination of CR/LF is treated as a end-of-line? If the compiler
> encounters CR on its own should it be treated as end-of-line? Should CR/LF
> be treated the same as LF/CR? Should CR/CR/LF be treated as 1 end-of-line
> or 2? What about LF/LF/CR? what happens when you mix and match LF and CR
> as end-of-line in the same source? How many end-of-line is one "vertical
> tab" or "form feed" equivalent too?


Your pint is well taken but, seing you asked ;-), a wrokable rulle seems to be.

- Any contiguous group of CR or LF caharcters is taken a s single EOL.

This may break some visual formatting but seems liable to work for
code compilation.

Vertical tab or form feed can be given rules which also do not "break"
compilation.

The present problems seemed to arose froman isolated CR NOT being
ddemd to be an EOL at all.
Some systems may allow it as of right, but I'd consider that strange.



      RM

2010\03\02@122253 by Alan B. Pearce

face picon face
>The present problems seemed to arose froman isolated CR
>NOT being ddemd to be an EOL at all.

I thought the problem was the editor didn't think of it as EOL, but the
compiler did, which was why code the OP thought he had commented out (and it
certainly showed as commented in my Ultraedit) the compiler didn't think was
commented.

2010\03\02@125039 by sergio masci

flavicon
face


On Wed, 3 Mar 2010, Russell McMahon wrote:

{Quote hidden}

But visual formatting (line numbers) is VERY important. The compiler needs
to be consistant with your editor and debugger. Yes you can do anything
you want in the compiler but it needs to be consistant with the other apps
in your system. If the compiler tells you there is a problem on line 1000
of your source you want to be able to open your source with ANY editor you
choose, go to line 1000 and fix it. You don't want to hunt around trying
to figure out that the compiler's understanding of line 1000 is actually
the editors line 950. Worse still, when you are debugging, you want the
next source line under the hammer to really be the one you think it is
(the one you are looking at) not a different one that the debugger thinks
it is because the compiler got the line numbers wrong.

It needs to be consistant across all your apps. What better way to ensure
this than to use the system definition of EOL. Ok, we've seen a problem
but that was really down to the editor trying to be clever and doing its
own thing rather than respecting the system definition of EOL.

Friendly Regards
Sergio Masci

2010\03\02@131525 by Isaac Marino Bavaresco

flavicon
face
Em 2/3/2010 13:53, Russell McMahon escreveu:
{Quote hidden}

When I write code for parsers, I use something like this:

if( *p == '\r' )
   {
   p++;
   if( *p == '\n' )
       p++;
   return EOL;
   }
else if( *p == '\n' )
   {
   p++;
   if( *p == '\r' )
       p++;
   return EOL;
   }
else ...

This give good results independently of how the line endings are configured.


Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\03\03@094448 by Eoin Ross

flavicon
face
Looks like you took a few more than one pint  ;)

>>> On 02 Mar 10 at 11:53:26, in message
<EraseME1be516741003020853i3989407u3b0842fea410e883spamspamspamBeGonemail.gmail.com>, Russell McMahon
<RemoveMEapptechnzKILLspamspamgmail.com> wrote:
><SNIP>
>
> Your pint is well taken but, seing you asked ;-), a wrokable rulle seems to
> be.
>
><SNIP>
>        RM


2010\03\03@104939 by Russell McMahon

face picon face
> Looks like you took a few more than one pint  ;)

Aye. 3 quarks for Muster Mark!

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...