CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

#define history

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
bkamen



Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA

View user's profile Send private message

#define history
PostPosted: Sat Feb 06, 2010 3:56 pm     Reply with quote

When I look at CCS code vs. MCHP code, I see they use a lot of

#define SOMETHING (10u)

It was easy for me to determine what that means -- but I've looked around for the history of that syntax and was googled to death with non-answers.

I don't see it used at all in CCS examples and was wondering why.

Anyone wanna toss in their $0.02? I'd love to hear it.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
mbradley



Joined: 11 Jul 2009
Posts: 118
Location: California, USA

View user's profile Send private message Visit poster's website

PostPosted: Sat Feb 06, 2010 5:44 pm     Reply with quote

mah 2 cents....make that 1...

I am a little confused, are you referring to #define in general? it is used alot in CCS C. pretty much all that is in a chip def file, such as 18f2525.h

We use stuff like, #define LED PIN_C1, and in the some_chip.h file, PIN_C1 is defined something like #define PIN_C1 0x1200

CCS has done a wonderful job of putting all the defines in the .h files for us, as related to general chip definitions.

I may be lost, is this what you were referring to?
_________________
Michael Bradley
www.mculabs.com
Open Drivers and Projects
bkamen



Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sat Feb 06, 2010 5:55 pm     Reply with quote

my bad...

I'm talking about the (10u) where it's shorthand for 10unsigned

or something like 10ul (unsigned long) -- if I'm reading this correctly.

I never use it.. but I've seen it a lot and thought, "when did this come about?"

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
mbradley



Joined: 11 Jul 2009
Posts: 118
Location: California, USA

View user's profile Send private message Visit poster's website

PostPosted: Sat Feb 06, 2010 5:58 pm     Reply with quote

Oh, the infamous 10u, I though I misunderstood your question (I have seen you around on the forum so I was like, no way is he asking this)

ok the 10u, I have no idea.

Perhaps just a MCHP variable, that is akin to the int8 that is not used by them, perhaps each compiler has there own way of doing it? actualy, I think I lost myself here. ok, it apears I have been of no help.
_________________
Michael Bradley
www.mculabs.com
Open Drivers and Projects
bkamen



Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sat Feb 06, 2010 6:57 pm     Reply with quote

mbradley wrote:
Oh, the infamous 10u, I though I misunderstood your question (I have seen you around on the forum so I was like, no way is he asking this)


Yea, I worded that question pretty poorly. Oops.

Quote:

Perhaps just a MCHP variable, that is akin to the int8 that is not used by them, perhaps each compiler has there own way of doing it? actualy, I think I lost myself here. ok, it apears I have been of no help.


It's not being used as a var and I've seen it in .C code in linux programs that typically pass through gcc... so I was just wondering the history.

Now that I've thought about it.. it's not #define, but "constants" I could look up and here it is in my K&R "The C Language".. Page 37, talking about constants...

"An integer constant like 1234 is an int. A long constant is written with a terminal l (ell) or L, as in 123456789L; an integer too big to fit into and int will also be taken as a long. Unsigned constants are written with a terminal u or U, and the suffix ul or UL indicates unsigned long.

This says what I've already figured out... but still leaves me wondering about why I see it some places and not others... must be a matter of style. (I know there's different camps of writing styles for programming...) And that's why I asked the question.

Neato, eh?

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
mbradley



Joined: 11 Jul 2009
Posts: 118
Location: California, USA

View user's profile Send private message Visit poster's website

PostPosted: Sat Feb 06, 2010 7:03 pm     Reply with quote

OMG, now I feel dumb, I just saw this in another post, and I was like, ok, I learned something new..

http://www.ccsinfo.com/forum/viewtopic.php?p=127645&highlight=#127645

they talk about an L, as in 200L
_________________
Michael Bradley
www.mculabs.com
Open Drivers and Projects
bkamen



Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sat Feb 06, 2010 7:37 pm     Reply with quote

Right.

And still, I understand *what* is does.

Where I've seen it in MCHP's tcp stack, it's apparent the author wants to make absolute that a value like 0xf is in a 32bit int because the #define says to shift the bits over some amount greater than 4 (where f would get slid off the left end).

So there it makes sense.

In the case you linked where someone was setting duty cycle, I would think that would be unnecessary as the incoming value should get type converted properly. (well, I would HOPE.)

But if the case is programmers always wondering how a called function would convert a passed argument's type is in question: why don't I see more constant suffix usage than I do.

The plot thickens.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
Ttelmah
Guest







PostPosted: Sun Feb 07, 2010 2:59 am     Reply with quote

The syntax is standard. Part of C itself.

The 'reason', is where they are reworking/writing examples, to be more portable between the PCD, ANSI, and 'normal' CCS syntax. Problem is that data sizes change with the versions, so where they want to force particular interpretation, they have started using this.
Older examples, generally don't use this, it is reserved for a very few later examples, where the size 'matters'.

Best Wishes
Ttelmah
Guest







PostPosted: Sun Feb 07, 2010 3:14 am     Reply with quote

Ongoing, the point about 'duty cycle', is that CCS has different behaviour for an 8bit value, and a long value. If a value is 8bit (it will be assumed to be so, if it is <256), the compiler puts it into the high 8bits of the 10bit duty cycle, leaving the two low bits unchanged. If instead the value is 16bit, it'll be written to the whole 10bits. Hence the size is 'critical' in this case.

Best Wishes
bkamen



Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Feb 07, 2010 9:13 pm     Reply with quote

I see what you're saying... I just found it interested that "suddenly" a different syntax was seen is if another programmer was writing the code with a different style.

Certainly makes sense now that something like the TCPIP stack runs on several different families of CPU's with different bit-sizes.

(shrug)

Anyway - just wondering.

Cheers,

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
Ttelmah
Guest







PostPosted: Mon Feb 08, 2010 2:53 am     Reply with quote

Yes.
I'd suspect that one of the programmers has been 'caught' by the size problems, and has got into the habit of being explicit. Not a bad habit.... Smile

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group