MPLAB Pre-processor

[Justin Richards]

I have been trying to merge free snippets of code and having problems with
the MPLAB pre-processor.

Is there a way to debug the pre-processor directives.

I get the following error,

C:\data\MPLAB\Ethernet\MyPicWeb\src\net\include\StackTsk.h:65:Error [1099]
Invalid MAX_TCP_SOCKETS value specified.

but MAX_TCP_SOCKETS is clearly defined as

#define MAX_TCP_SOCKETS     (8ul)

in an include file that is included before StackTsk.h is included. (in
tick.c)

I tried

#define MAX_TCP_SOCKETS     (9ul)

  just before

#if (MAX_TCP_SOCKETS <= 0 || MAX_TCP_SOCKETS > 255)
#error Invalid MAX_TCP_SOCKETS value specified.
#endif

and get

C:\data\MPLAB\Ethernet\MyPicWeb\src\net\include\StackTsk.h:61:Error [1034]
previous definition of macro 'MAX_TCP_SOCKETS' does not agree

so I tried

#define MAX_TCP_SOCKETS     (8ul)

just before the #if ... #endif

and no problems.

So the pre-processor is aware the label is pre-defined but complains.

I am obviously missing the point, any suggestion exactly what the compiler
is complaining about.

I have tried going thru the help with search words like preprocessor and
#define but they dont really give me an insight into the way include files
and the corresponding pre-processor directives are processed.

Any links pointers etc welcome,

Cheers Justin
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Isaac Marino Bavaresco]

Justin Richards escreveu:

> I have been trying to merge free snippets of code and having problems with
> the MPLAB pre-processor.
>
> Is there a way to debug the pre-processor directives.
>
> I get the following error,
>
> C:\data\MPLAB\Ethernet\MyPicWeb\src\net\include\StackTsk.h:65:Error [1099]
> Invalid MAX_TCP_SOCKETS value specified.
>
> but MAX_TCP_SOCKETS is clearly defined as
>
> #define MAX_TCP_SOCKETS     (8ul)
>  

This message is probably not being issued by the preprocessor itself,
but by some #error directive inside an #if.

The author of the code is probably testing for invalid values that won't
work when compiled.

Regards,

Isaac

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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan B. Pearce-2]

>but MAX_TCP_SOCKETS is clearly defined as
>
>#define MAX_TCP_SOCKETS     (8ul)
>
>in an include file that is included before StackTsk.h is
> included. (in tick.c)

This suggests that the directory for the include file is not in the include
files search path.

Alan (been there, missed the include path ...)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan B. Pearce-2]

>but MAX_TCP_SOCKETS is clearly defined as
>
>#define MAX_TCP_SOCKETS     (8ul)
>
>in an include file that is included before StackTsk.h is
> included. (in tick.c)

This suggests that the directory for the include file is not in the include
files search path.

Alan (been there, missed the include path ...)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Justin Richards wrote:
> I have been trying to merge free snippets of code and having problems
> with the MPLAB pre-processor.

There is no such thing as a "MPLAB preprocessor".

MPASM doesn't really have a preprocessor.  My PREPIC program is a
preprocessor for MPASM, which adds a bunch of nice features to PIC assembler
source code.

> C:\data\MPLAB\Ethernet\MyPicWeb\src\net\include\StackTsk.h:65:Error
> [1099] Invalid MAX_TCP_SOCKETS value specified.

Judging fromt the .h suffix, this looks like you're asking about the
preprocessor for whatever C compiler you are using.

Step back and understand the distinction between MPLAB, your C compiler, and
its preprocessor.  Until then things won't make any sense and you will
continue to ask questions that don't make sense.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Justin Richards]

I agree with Olin.  I need help understanding difference between MPLAB and
the c compiler (in this case c18) and you have helped.

I have had good success using the IDE for assembler with all my own code but
this is my first project with c and its modifying the Microchip stack. .

I could start with a simpler project perhaps but I am certain if I just get
over a few hurdles I should be ok.

I find these processor directives difficult because I cant tell what the
processor thinks their values are.  I managed to work out how to pass a
structure by reference because the debugger gives me feedback.

Is there a directive that I can use to echo the value of the various defines
or better yet is there documentation that describes these directive.  What
confuses me even more is that some people put these in a section of their
code called Macros.

>From what Olin has said these must be c18 directives so I will go thru all
the c18 help files and c what I can find.

Cheers Justin


Step back and understand the distinction between MPLAB, your C compiler, and

> its preprocessor.  Until then things won't make any sense and you will
> continue to ask questions that don't make sense.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> [phone].  Gold level PIC consultants since 2000.
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Tamas Rudnai]

On Fri, Jun 26, 2009 at 1:32 AM, Justin Richards
<justin.richards@...>wrote:

> I agree with Olin.  I need help understanding difference between MPLAB and
> the c compiler (in this case c18) and you have helped.


MPLAB is only the IDE, while C18 is the compiler that IDE will invoke when
you do a build.


> I find these processor directives difficult because I cant tell what the
> processor thinks their values are.  I managed to work out how to pass a
> structure by reference because the debugger gives me feedback.


You can invoke the compilation with command line using the MCC18.EXE located
in your MCC18 installation/bin directory, then you can apply -E option to
generate a "<filename>.i" file so you can see what the compiler will see
after the preprocessor.


> Is there a directive that I can use to echo the value of the various
> defines
> or better yet is there documentation that describes these directive.  What
> confuses me even more is that some people put these in a section of their
> code called Macros.


The directives are documented in the C18 user's manual. You can use that -E
option to see your values... However, I would not call it value, as #define
is only defining a macro which is a kind of replacement string. The
preprocessor only blindly replaces the string whatever you put after #define
MAX_TCP_SOCKETS so for example if you have a

myVar = MAX_TCP_SOCKETS;

in your code you will see

myVar = (9ul);

in the .i file... like a search and replace...

But in the .i file you will see NO #if statements whatsoever, those are
already preprocessed by that stage... You need to put a string that the
preprocessor can replace but will not remove or otherwise processes, so you
can even put a plain text without concerning of C language syntax therefore
would not compiled by C18 but at least can be used as a diagnostic on your
preprocessor experiments -- like:

...
...
...
>>> well, the current value of MAX-TCP-SOCKET: MAX_TCP_SOCKETS
...
...
...
(note that I replaces the original underscore to dash otherwise that string
would have been replaced by the preprocessor as well)

Tamas

>
> >From what Olin has said these must be c18 directives so I will go thru all
> the c18 help files and c what I can find.
>
> Cheers Justin
>
>
> Step back and understand the distinction between MPLAB, your C compiler,
> and
> > its preprocessor.  Until then things won't make any sense and you will
> > continue to ask questions that don't make sense.
> >
> >
> > ********************************************************************
> > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> > [phone].  Gold level PIC consultants since 2000.
> > --
> > http://www.piclist.com PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.mcuhobby.com
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Justin Richards wrote:

> I find these processor directives difficult because I cant tell what
> the processor thinks their values are.  I managed to work out how to
> pass a structure by reference because the debugger gives me feedback.
>
> Is there a directive that I can use to echo the value of the various
> defines or better yet is there documentation that describes these
> directive.  What confuses me even more is that some people put these
> in a section of their code called Macros.

In C, everything that's defined with a #define directive is called a
"macro". It may be a simple value (often used for defining constants
without spending RAM on them) or a complex construct with arguments and
multiple levels of substitution. The C preprocessor is not always
intuitive, so when you get to more complex constructs, don't be
surprised about surprises :)

AFAIK there's no way to directly display preprocessor values. Your
compiler may have a non-standard way, though, so check its manual.

If you suspect what the value is, you can use an #if variable ==
suspected_value/#error construct to confirm your suspicion. (This is
similar to what you did, so you're on the right track :)

Usually a compiler has a way to either invoke the preprocessor
separately, to stop its processing after the preprocessor run or to
output and/or preserve the file contents after the preprocessor went
over it. This can help a lot figuring out what the preprocessor does.
Again, your compiler's manual should show you how to do this.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Justin Richards]

Thanks to all those that provided some great assistance.

I got very strange results when changing the lower part of the conditional
statement so i figured that the conditional statement must be trashed in
memory somehow and must be due to something I was doing wrong.

With the help of

>>> well, the current value of MAX-TCP-SOCKET: MAX_TCP_SOCKETS

I could prove that the define worked as expected just the conditional
statement lost the plot.

I discovered that there was a circular reference ie a .h file referred to a
.h file that included the first .h file.

Thanks again.

Cheers Justin



.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan B. Pearce-2]

>I discovered that there was a circular reference ie a .h
>file referred to a .h file that included the first .h file.

This is why all the statements in the .h file are usually inside a #ifdef
statement, that includes a #define of the value the #ifdef checks. Then if
the .h file is called again in such a loop, it is not reused.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Justin Richards wrote:
> I discovered that there was a circular reference ie a .h file
> referred to a .h file that included the first .h file.

That's why you often see interlocks on include files.  Each include file
defines a symbol derived from the name of the file.  A IFDEF is used around
the entire file contents to prevent it being read if the symbol is already
defined, meaning that file was already processed.  The special symbol is
then defined inside the IFDEF.

Personally I don't like this method.  Include files shouldn't include other
include files.  The dependencies should be published and the caller should
include the necessary files.  That allows substitution of different
libraries with the same interface at the program level.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Olin Lathrop wrote:

> Personally I don't like this method.  Include files shouldn't include
> other include files.  The dependencies should be published and the
> caller should include the necessary files.  That allows substitution
> of different libraries with the same interface at the program level.

I don't quite understand your argument. The advantage of include
directives in include files is exactly that you don't have to change
your code in case you want to use a different library with the same
interface.

  #include "library1.h"
  int main()
  {
    return library_function();
  }

becomes (after a library switch)

  #include "library2.h"
  int main()
  {
    return library_function();
  }

no matter what the dependencies of library1 and library2 are.

With your method, it seems to me that for a switch of libraries you'd
have to update the include directives according to the library
dependencies in each file that uses that library. I find this tiresome;
that's why I use includes inside include files. The user doesn't have to
worry about dependencies; they are included automatically.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Gerhard Fiedler wrote:
> I don't quite understand your argument. The advantage of include
> directives in include files is exactly that you don't have to change
> your code in case you want to use a different library with the same
> interface.

No, it is that you don't have to know the dependencies.  However, the choice
of library include file to use is then buried below where the application
can control it.

Suppose the STUFF library has routines that call into the BLOBIO library.
If you just want to use the STUFF interface and don't care that it uses
BLOBIO, then nested include files is fine.

If you have applications that want to chose one of a set of
BLOBIO-compatible libraries, then it's a problem.  In this case, you want
the application to include its BLOBIO-compatible library of choice, then the
STUFF library.  That doesn't work if the STUFF include file includes BLOBIO
underneath.

I used to think having include files automatically grab anything they
depended on was a good idea until I had a case just like I described above.
Since then I've been making include files stand alone and making
applications include the required prerequisites.  It's really no problem
since the compiler will tell you right away when a required symbol is
missing.  If on the first compile you see "BLOBIO_INIT not defined", you'll
know quickly enough what you forgot.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Ruben Jönsson]

> Olin Lathrop wrote:
>
> > Personally I don't like this method.  Include files shouldn't include
> > other include files.  The dependencies should be published and the
> > caller should include the necessary files.  That allows substitution
> > of different libraries with the same interface at the program level.
>
> I don't quite understand your argument. The advantage of include
> directives in include files is exactly that you don't have to change
> your code in case you want to use a different library with the same
> interface.
>
>   #include "library1.h"
>   int main()
>   {
>     return library_function();
>   }
>
> becomes (after a library switch)
>
>   #include "library2.h"
>   int main()
>   {
>     return library_function();
>   }
>
> no matter what the dependencies of library1 and library2 are.
>
> With your method, it seems to me that for a switch of libraries you'd
> have to update the include directives according to the library
> dependencies in each file that uses that library. I find this tiresome;
> that's why I use includes inside include files. The user doesn't have to
> worry about dependencies; they are included automatically.
>
> Gerhard

Yes, the include file should include other include files that its  
implementation (source file) is depending upon. But only those and no others.

This could mean that the same include file is indirectly included several times
for one implementation file. Say that I have one implementation file for a
circular buffer "buffer.h", one for lcd routines "lcd.h" and one for rs232
communication "rs232.h". Both the lcd and the rs232 routine uses "buffer.h" so
the include files for those both include "buffer.h". If I call functions from
both the lcd and the rs232 modules in one implementation file I should include
"lcd.h" and "rs232.h" in that file but not "buffer.h" since the buffer
functions are hidden for me here (unless, of course, I also explicitly use the
buffer functions).

This simplifies modular and hierarchical coding using library modules.

As Gerhard also says, if I sometimes want to change the communication to use
usb instead of rs232 I just include "usb.h" instead of "rs232.h" and change the
function calls accordingly. The usb modules may or may not use the "buffer.h"
functions. By using this include scheme I don't need to care about that here
since including of sub modules is all handled automatically.

/Ruben


==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT [phone]
FAX INT [phone]
ruben@...
==============================

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Ruben Jönsson]

> Gerhard Fiedler wrote:
> > I don't quite understand your argument. The advantage of include
> > directives in include files is exactly that you don't have to change
> > your code in case you want to use a different library with the same
> > interface.
>
> No, it is that you don't have to know the dependencies.  However, the choice
> of library include file to use is then buried below where the application
> can control it.
>
> Suppose the STUFF library has routines that call into the BLOBIO library.
> If you just want to use the STUFF interface and don't care that it uses
> BLOBIO, then nested include files is fine.
>
> If you have applications that want to chose one of a set of
> BLOBIO-compatible libraries, then it's a problem.  In this case, you want
> the application to include its BLOBIO-compatible library of choice, then the
> STUFF library.  That doesn't work if the STUFF include file includes BLOBIO
> underneath.
>

Then you can have a define that determines which BLOBIO compatible library you
want to use and have one main BLOBIO include file which in turn calls the
correct BLOBIO include file depending on the defined value. The defined value
should be set before including the STUFF include file, perhaps even on a
project basis. Just like UNICODE/ANSI or DEBUG/RELEASE.

/Ruben


/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT [phone]
FAX INT [phone]
ruben@...
==============================

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Ruben Jönsson wrote:
> Then you can have a define that determines which BLOBIO compatible
> library you want to use and have one main BLOBIO include file which
> in turn calls the correct BLOBIO include file depending on the
> defined value. The defined value should be set before including the
> STUFF include file, perhaps even on a project basis. Just like
> UNICODE/ANSI or DEBUG/RELEASE.

But that assumes that all possible BLOBIO-compatible libraries are known.
This procludes the case, for example, of making a custom BLOBIO library to
hook certain features, which was in fact the case I ran into.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Justin Richards]

> That's why you often see interlocks on include files.


 Then the use of interlocks is not required if the caller includes the
necessary files.  Is my understanding correct.


>
> Personally I don't like this method.  Include files shouldn't include other
> include files.  The dependencies should be published and the caller should
> include the necessary files.


Does "published" refer to documenting dependencies in a comment block.

I have virtually zero experience here so I am not aware of the pros and cons
of both approaches.  However, I would prefer to see all the dependencies
listed in the include section.

As a novice, I found it difficult to follow what was using what in the case
of the Microchip TCPIP Stack.

/Ruben commented

"By using this include scheme I don't need to care about that here
since including of sub modules is all handled automatically"

but so far I seem to have a need to examine what is in the sub modules and
their purpose so I can taylor the project for my needs.

I thought this was because I am a novice but I can see no way to escape it.
I need to examine the _NODE_INFO structure (for example) somehow (which is
buried deep) so I can use it to stuff with values to use for my purposes.

Cheers Justin

>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> [phone].  Gold level PIC consultants since 2000.
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Ruben Jönsson]

> Ruben Jönsson wrote:
> > Then you can have a define that determines which BLOBIO compatible
> > library you want to use and have one main BLOBIO include file which
> > in turn calls the correct BLOBIO include file depending on the
> > defined value. The defined value should be set before including the
> > STUFF include file, perhaps even on a project basis. Just like
> > UNICODE/ANSI or DEBUG/RELEASE.
>
> But that assumes that all possible BLOBIO-compatible libraries are known.
> This procludes the case, for example, of making a custom BLOBIO library to
> hook certain features, which was in fact the case I ran into.
>
>

Then the interface for the BLOBIO functions can require a project-include file  
which just includes the needed include files (only for the BLOBIO functions)
for this project. Only the name of this include file is standardized so the
BLOBIO library knows which file to include.

The benefit from this is that you only have one place where you tell the
project which include files to use for this library in this project.

I guess this can be compared to an object oriented class which uses virtual
functions.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT [phone]
FAX INT [phone]
ruben@...
==============================

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Justin Richards wrote:

>> That's why you often see interlocks on include files.
>
>  Then the use of interlocks is not required if the caller includes the
> necessary files.  Is my understanding correct.

It is correct, if you don't have a deep #include tree and if you control
all the sources. But those interlocks don't cost much if anything
(depending on your editor, you can create a macro that creates them for
you when you create a header file), and they simply make things smoother
-- even if you should have a multiple include hidden somewhere. They are
highly recommended, especially if you don't know very well what you're
doing.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Ruben Jönsson wrote:

>> Ruben Jönsson wrote:
>>> Then you can have a define that determines which BLOBIO compatible
>>> library you want to use and have one main BLOBIO include file which
>>> in turn calls the correct BLOBIO include file depending on the
>>> defined value. The defined value should be set before including the
>>> STUFF include file, perhaps even on a project basis. Just like
>>> UNICODE/ANSI or DEBUG/RELEASE.
>>
>> But that assumes that all possible BLOBIO-compatible libraries are
>> known. This procludes the case, for example, of making a custom
>> BLOBIO library to hook certain features, which was in fact the case
>> I ran into.
>
> Then the interface for the BLOBIO functions can require a
> project-include file which just includes the needed include files
> (only for the BLOBIO functions) for this project. Only the name of
> this include file is standardized so the BLOBIO library knows which
> file to include.
>
> The benefit from this is that you only have one place where you tell
> the project which include files to use for this library in this
> project.
>
> I guess this can be compared to an object oriented class which uses
> virtual functions.

I agree with Ruben. I've done something similar (both the required
define method and the required include file method), for example when
shared code depends on some project-specific features (like the BLOBIO
code in this example). I find that this is the exception, and the small
complication is worth it.

OTOH, I also can see that for such cases (which for me are the
exception), it also can work to document that this module requires such
and such functions to be defined in the project, no matter how and
where. Then it's up to the project to do so adequately. Yet, this
wouldn't affect the overall rule to include known and fixed dependencies
in header files. (I'd probably still create a header file that declares
the required functions. Any custom implementation would use that header
file, and can add its own additions.)

Gerhard

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist