Post by thread:[PIC] C18 compiler preprocessor directives

On Fri, Jun 19, 2009 at 1:03 AM, solarwind <spam_OUTx.solarwind.xTakeThisOuTgmail.com> wrote: > > Does the C preprocessor in the MPLAB C18 compiler support the #warning > directive? #error worked but #warning resulted in a syntax error. > Perhaps its called something else? Is there any other directive that's > useful to output text information to the console? > I'm sure all of the directives are explained in the C18 User's Guide. I don't even know how you'd program in C18 without it. ww1.microchip.com/downloads/en/DeviceDoc/51288F.pdf (Doesn't look like #warning is in there, but I know there's a way to turn off warnings in ASM) -Scott

On Fri, 19 Jun 2009 06:03:16 +0100, you wrote: >Does the C preprocessor in the MPLAB C18 compiler support the #warning >directive? #error worked but #warning resulted in a syntax error. >Perhaps its called something else? Is there any other directive that's >useful to output text information to the console? C18 has no #warning. Any unknown #pragma will produce a warning. I never saw much utility in testing at compile time for something I was going to ignore....

On Fri, Jun 19, 2009 at 2:13 PM, Terry Harris<.....terry.harrisKILLspam@spam@iname.com> wrote: >>Does the C preprocessor in the MPLAB C18 compiler support the #warning >>directive? #error worked but #warning resulted in a syntax error. >>Perhaps its called something else? Is there any other directive that's >>useful to output text information to the console? > > C18 has no #warning. > > Any unknown #pragma will produce a warning. > > I never saw much utility in testing at compile time for something I was > going to ignore.... #if NUM_CHANNELS != 10 #warning If you change NUM_CHANNELS, you must change MyArray[] references #endif Very, very useful. Especially to someone who has to support your code. Bill -- Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org

> #if NUM_CHANNELS != 10 > #warning If you change NUM_CHANNELS, you must change MyArray[] references > #endif What's wrong with this then? #if NUM_CHANNELS != 10 #error If you change NUM_CHANNELS, you must change MyArray[] references #endif ...so they can stop and change the expression not to brake the compilation. Personally a warning in a C compilation is the same as having an error -- so if a code cannot be compiled "cleanly" then it is not considered as a safe code anyway (therefore no matter if I were using #warning or #error). That's why some compiler has a message directive as well, so that you can print out compiler information, like the endianness, or the size of the integer etc -- these can go to the documents as for later prove what were the build setup etc... eg. in Visual C++ you have this: #if _M_IX86 == 500 #pragma message( "Pentium processor build" ) #endif http://msdn.microsoft.com/en-us/library/x7dkzch2(VS.71).aspx Tamas On Mon, Jun 22, 2009 at 3:02 PM, William Couture <bcoutureKILLspamgmail.com> wrote: {Quote hidden}> On Fri, Jun 19, 2009 at 2:13 PM, Terry Harris<.....terry.harrisKILLspam.....iname.com> > wrote: > > >>Does the C preprocessor in the MPLAB C18 compiler support the #warning > >>directive? #error worked but #warning resulted in a syntax error. > >>Perhaps its called something else? Is there any other directive that's > >>useful to output text information to the console? > > > > C18 has no #warning. > > > > Any unknown #pragma will produce a warning. > > > > I never saw much utility in testing at compile time for something I was > > going to ignore.... > > #if NUM_CHANNELS != 10 > #warning If you change NUM_CHANNELS, you must change MyArray[] references > #endif > > Very, very useful. Especially to someone who has to support your code. > > Bill > > -- > Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org > -

On Mon, Jun 22, 2009 at 3:27 PM, Tamas Rudnai<EraseMEtamas.rudnaispam_OUTTakeThisOuTgmail.com> wrote: >> #if NUM_CHANNELS != 10 >> #warning If you change NUM_CHANNELS, you must change MyArray[] references >> #endif > > What's wrong with this then? > > #if NUM_CHANNELS != 10 > #error If you change NUM_CHANNELS, you must change MyArray[] references > #endif What's wrong is that it forces an compilation error which may not be needed. Sometimes just a "warning" is good, especialy when you want to let someone know what's going on in the compile process.

On Mon, 2009-06-22 at 10:02 -0400, William Couture wrote: > On Fri, Jun 19, 2009 at 2:13 PM, Terry Harris<terry.harrisspam_OUTiname.com> wrote: > > >>Does the C preprocessor in the MPLAB C18 compiler support the #warning > >>directive? #error worked but #warning resulted in a syntax error. > >>Perhaps its called something else? Is there any other directive that's > >>useful to output text information to the console? > > > > C18 has no #warning. > > > > Any unknown #pragma will produce a warning. > > > > I never saw much utility in testing at compile time for something I was > > going to ignore.... > > #if NUM_CHANNELS != 10 > #warning If you change NUM_CHANNELS, you must change MyArray[] references > #endif UGH!!! Why arn't the "MyArray" references dependent on the value of NUM_CHANNELS ? Seems you've only half written the code! PeterO

solarwind wrote: >> #if NUM_CHANNELS != 10 >> #error If you change NUM_CHANNELS, you must change MyArray[] references >> #endif > > What's wrong is that it forces an compilation error which may not be > needed. But that's the point. You don't want someone changing NUM_CHANNELS without taking care of other details. If you changed NUM_CHANNELS and get the error, you take a look at MyArray, adjust as necessary, then change the number in the #IF to your new value. You won't get that error again unless you change NUM_CHANNELS again, in which case you *want* to get the message again. Sticking your head in the sand and having the problem bite you later is really bad software development practise. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

On Mon, Jun 22, 2009 at 8:11 PM, Olin Lathrop<@spam@olin_piclistKILLspamembedinc.com> wrote: > But that's the point. You don't want someone changing NUM_CHANNELS without > taking care of other details. If you changed NUM_CHANNELS and get the > error, you take a look at MyArray, adjust as necessary, then change the > number in the #IF to your new value. You won't get that error again unless > you change NUM_CHANNELS again, in which case you *want* to get the message > again. > > Sticking your head in the sand and having the problem bite you later is > really bad software development practise. No, that's not the point. the #warning directive is useful and has many purposes, including just printing messages to stdout during compilation. For example, #if WEAPON = 1 #warning you will spawn with an M4A1 #endif #if WEAPON = 2 #warning you will spawn with an AK74U #endif

On Mon, 22 Jun 2009 18:23:36 +0100, you wrote: >On Mon, Jun 22, 2009 at 3:27 PM, Tamas Rudnai<KILLspamtamas.rudnaiKILLspamgmail.com> wrote: >>> #if NUM_CHANNELS != 10 >>> #warning If you change NUM_CHANNELS, you must change MyArray[] references >>> #endif >> >> What's wrong with this then? >> >> #if NUM_CHANNELS != 10 >> #error If you change NUM_CHANNELS, you must change MyArray[] references >> #endif > >What's wrong is that it forces an compilation error which may not be >needed. Sometimes just a "warning" is good, especialy when you want to >let someone know what's going on in the compile process. And what is someone going to do armed with the knowledge of what is going on in the compile process? They can decide is isn't a problem in which case there was no point telling them or decide it is a problem which will almost always result in changing something and re-compiling. I would prefer to embed that decision in the code and get an error when I have to do something rather than scan the output and make decisions on every successful compile.

On Mon, Jun 22, 2009 at 8:46 PM, Terry Harris<RemoveMEterry.harrisTakeThisOuTiname.com> wrote: > And what is someone going to do armed with the knowledge of what is going > on in the compile process? > > They can decide is isn't a problem in which case there was no point telling > them or decide it is a problem which will almost always result in changing > something and re-compiling. > > I would prefer to embed that decision in the code and get an error when I > have to do something rather than scan the output and make decisions on > every successful compile. Well, you see, if I spawned with an M4A1, I could kill you simply by aiming at your neck and let the recoil carry the bullets to your head. However, if I spawned with an AK74U, I would have to prepare to aim a little lower due to the increased recoil.

> I would prefer to embed that decision in the code and get an error when I > have to do something rather than scan the output and make decisions on > every successful compile. Sometimes it is not a decision but information. A non-limitative list: - a hash code computed from something that has to be entered into some other tool - an error % (whithin acceptable limites, but still worth knowing, like whether a baudrate is 0.2 or 0.8% off) - a copyright or similar message (not intented for the end user, but for the one who compiles the stuff) - statistics (code size, data size, etc) - hints for a code review -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

solarwind wrote: > No, that's not the point. the #warning directive is useful and has > many purposes, including just printing messages to stdout during > compilation. > > For example, > > #if WEAPON = 1 > #warning you will spawn with an M4A1 > #endif > > #if WEAPON = 2 > #warning you will spawn with an AK74U > #endif Those look more like they should be messages, not warnings. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

On Mon, Jun 22, 2009 at 10:39 PM, Olin Lathrop<spamBeGoneolin_piclistspamBeGoneembedinc.com> wrote: > Those look more like they should be messages, not warnings. *facepalm* #warning doesn't HAVE to he a warning..... It's used many times in many open source projects in non-warning situations. If there was another directive, I'm sure it would be used, but the closest thing in gnu cpp is #warning and people are fine with that. Just need some way to output a message without interrupting the compile process.

On Mon, Jun 22, 2009 at 9:57 PM, solarwind <TakeThisOuTx.solarwind.xEraseMEspam_OUTgmail.com> wrote: > However, if I spawned with an AK74U, I would have to prepare to aim a > little lower due to the increased recoil. > Have you ever shoot with such a weapon? The same they say about AK47, however, in fact I could shoot down the target from 250 meters using one bullet per target. You only have to know how to hold it properly. Anyway, these things nothing to do with compiler directives anyway. Tamas -- http://www.mcuhobby.com

>- an error % (whithin acceptable limites, but still worth >knowing, like whether a baudrate is 0.2 or 0.8% off) An example of this is the 'uart2.c' and corresponding .h file that comes with the USB Device CDC examples in the USB stack. It has a #warning statement inside a #if/#endif and I believe this is supposed to compile on C18 - but it may be that there is a check for the compiler to see if that is for C18 or C30/C32.

solarwind wrote: > #warning doesn't HAVE to he a warning. But it should be. > It's used many times in > many open source projects in non-warning situations. So you're saying 10000 monkeys at keyboards can't be wrong? Most software is crap. That doesn't make it right. > If there was > another directive, I'm sure it would be used, but the closest thing in > gnu cpp is #warning and people are fine with that. Just need some way > to output a message without interrupting the compile process. Doesn't the compiler have something like #message for things like that? Or maybe there is something in the preprocessor? I use my /SHOW assembler preprocessor command for this purpose routinely. The point is you don't want something looking like it might be a problem when it isn't. Responsible programmers will want to chase down the cause of all warnings from a compile and fix them. Ususally messages specifically intended as warnings cause the compiler to output them with a specific format that looks visually distinct from a arbitrary message. If you just want to output informational messages that don't indicate something wrong, then you want them undecorated by the compiler. I expect #warning doesn't do that. If there isn't something that does then that's a important missing feature. You're always on about open source software. Go add it. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

On Tue, 23 Jun 2009 08:20:45 -0400, you wrote: >> Just need some way >> to output a message without interrupting the compile process. #ifdef SOLARWIND #pragma I_should_read_what_people_tell_me #endif >The point is you don't want something looking like it might be a problem >when it isn't. Responsible programmers will want to chase down the cause of >all warnings from a compile and fix them. If you turn on strict ANSI gcc issues a warning when #warning is used :).

{Quote hidden}> -----Original Message----- > From: piclist-bouncesEraseME.....mit.edu > [EraseMEpiclist-bouncesmit.edu] On Behalf Of Olin Lathrop > Sent: 23 June 2009 13:21 > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] C18 compiler preprocessor directives > > solarwind wrote: > > #warning doesn't HAVE to he a warning. > > But it should be. > > > It's used many times in > > many open source projects in non-warning situations. > > So you're saying 10000 monkeys at keyboards can't be wrong? > Most software is crap. That doesn't make it right. > > > If there was > > another directive, I'm sure it would be used, but the > closest thing in > > gnu cpp is #warning and people are fine with that. Just > need some way > > to output a message without interrupting the compile process. > > Doesn't the compiler have something like #message for things > like that? That's the whole point, '#message' does not exist on any C compiler I am aware of. '#warning' exists on some compilers, and is therefore sometimes used in place of a '#message'. A universal way of coercing the compiler to write arbitrary data to stdout at compile time and from within the source code would be most useful. 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. =======================================================================

www.picinf.blogspot.com for more projects of pic controller. --- On Tue, 6/23/09, solarwind <RemoveMEx.solarwind.xTakeThisOuTspamgmail.com> wrote: From: solarwind <EraseMEx.solarwind.xspamspamBeGonegmail.com> Subject: Re: [PIC] C18 compiler preprocessor directives To: "Microcontroller discussion list - Public." <RemoveMEpiclistKILLspammit.edu> Date: Tuesday, June 23, 2009, 4:24 PM On Tue, Jun 23, 2009 at 8:24 AM, Tamas Rudnai<tamas.rudnaiSTOPspamspam_OUTgmail.com> wrote: > Have you ever shoot with such a weapon? The same they say about AK47, > however, in fact I could shoot down the target from 250 meters using one > bullet per target. You only have to know how to hold it properly. I'm talking about spraying with it, not one bullet at a time.

>> Have you ever shoot with such a weapon? The same they say about AK47, >> however, in fact I could shoot down the target from 250 meters using one >> bullet per target. You only have to know how to hold it properly. OK subject on [PIC] for a mention or two in the original context (ie that limit has now been reached)(no problem with that). Please take to [OT] if discussion of shooting techniques or my M61 is bigger than your AK47 is desired. Please take offlist if any sort of detauled discussion re weaponry is desired. ( ... Sherman Firefly's rule(d). OK! ... ) Russell