Searching \ for '[PIC] C18 function prototypes (pic18f8627)' 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=18F
Search entire site for: 'C18 function prototypes (pic18f8627)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] C18 function prototypes (pic18f8627)'
2010\07\22@110028 by Matt Rhys-Roberts

flavicon
face
Please can someone faimilar with C kindly help clear up my confusion here?

I'm declaring a couple of SPI function prototypes, see below. Not
wishing to waste too much time testing awkward things, shouldn't the
common variables (sync_mode, bus_mode etc.) be specified more uniquely
for each SPI channel? Will the following, although it compiles ok, cause
ambiguity when it comes to execution? I can't tell whether prototyping a
function is the same as declaring a variable by name, nor how it's
allocating the names following "unsigned char".

Many thanks,
Matt



void OpenSPI1
(
unsigned char sync_mode,
unsigned char bus_mode,
unsigned char smp_phase
);
unsigned char WriteSPI1(unsigned char data_out );

void OpenSPI2
(
unsigned char sync_mode,
unsigned char bus_mode,
unsigned char smp_phase
);
unsigned char WriteSPI2(unsigned char data_out );

void Open1USART
(
unsigned char config,
unsigned int spbrg
);

2010\07\22@112413 by Isaac Marino Bavaresco

flavicon
face
Em 22/7/2010 12:00, Matt Rhys-Roberts escreveu:
{Quote hidden}

Why don't you pass the port as an argument to the functions?
Instead of duplicating a lot of code, just duplicate and select between
the code that access the hardware?

Or you could do as in desktop systems, OpenSPI takes the port number and
returns a handle which must be passed to the other functions or -1 if it
fails?

This way you could share the SPI ports between threads (if you are using
a RTOS). I do it this way in my designs, for SPI, USART, etc.


Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\07\22@113617 by Paul Hutchinson

picon face
> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu On Behalf Of Matt Rhys-Roberts
> Sent: Thursday, July 22, 2010 11:01 AM
>
> Please can someone faimilar with C kindly help clear up my
> confusion here?
>
> I'm declaring a couple of SPI function prototypes, see below. Not
> wishing to waste too much time testing awkward things, shouldn't the
> common variables (sync_mode, bus_mode etc.) be specified more
> uniquely for each SPI channel? Will the following, although it
> compiles ok, cause ambiguity when it comes to execution? I can't
> tell whether prototyping a function is the same as declaring a
> variable by name, nor how it's allocating the names following
> "unsigned char".
>
> Many thanks,
> Matt
>

The parameter identifiers in a C function prototype are optional and have a
scope limited to the prototype list so, there will be no conflicts or
ambiguity.

More info @ <http://www.ericgiguere.com/articles/ansi-c-summary.html>

Paul Hutch

{Quote hidden}

2010\07\22@114458 by Dave Tweed

face
flavicon
face
Matt Rhys-Roberts wrote:
> I'm declaring a couple of SPI function prototypes, see below. Not
> wishing to waste too much time testing awkward things, shouldn't the
> common variables (sync_mode, bus_mode etc.) be specified more uniquely
> for each SPI channel?

Function arguments in C are treated exactly the same, including the
scoping rules, as automatic (local) variables within the function.
So, it's perfectly fine to reuse the same argument names in different
functions.

-- Dave Tweed

2010\07\22@115027 by Matt Rhys-Roberts

flavicon
face

> Why don't you pass the port as an argument to the functions?
> Instead of duplicating a lot of code, just duplicate and select between
> the code that access the hardware?
>
> Or you could do as in desktop systems, OpenSPI takes the port number and
> returns a handle which must be passed to the other functions or -1 if it
> fails?
>
> This way you could share the SPI ports between threads (if you are using
> a RTOS). I do it this way in my designs, for SPI, USART, etc.
>
>
> Isaac
>    

Hi Isaac,

Thanks for the reply... Sorry to sound stupid, but you've lost me
altogether with "pass the port as an argument to the functions", and
"duplicate and select between the code that accesses the hardware"
confuses me. Can you suggest an example please?

Referring to http://en.wikipedia.org/wiki/Function_prototype , I
understand that prototyping functions before using them helps to make
the compiler's job easier and prevents confusing errors.

I'm not multithreading or using a RTOS here, just trying to configure
things politely in C so that I can make use of C's more elegant
operators when it comes to data manipulation and processing.

NB. I've been using PIC assembly for years, so I'm not familiar with
some of the higher-minded C concepts yet!

Best regards,
Matt.

2010\07\22@115524 by Matt Rhys-Roberts

flavicon
face
On 22/07/2010 16:36, Paul Hutchinson wrote:
>
> The parameter identifiers in a C function prototype are optional and have a
> scope limited to the prototype list so, there will be no conflicts or
> ambiguity.
>
> More info @<http://www.ericgiguere.com/articles/ansi-c-summary.html>
>
> Paul Hutch

Thanks Paul, I think that begins to clear things up a bit.

Matt

2010\07\22@123730 by John Temples

flavicon
face
On Thu, 22 Jul 2010, Paul Hutchinson wrote:

> The parameter identifiers in a C function prototype are optional

No, they aren't.  A function declaration that doesn't specify the
number and types of the parameters is not a function prototype.
Something like this:

void func();

void main(void)
{
    func();
}

will correctly generate a "missing prototype" warning from some
compilers (e.g., Microchip's C18).

--
John W. Temples, III

2010\07\22@123730 by John Temples

flavicon
face
On Thu, 22 Jul 2010, Paul Hutchinson wrote:

> The parameter identifiers in a C function prototype are optional

No, they aren't.  A function declaration that doesn't specify the
number and types of the parameters is not a function prototype.
Something like this:

void func();

void main(void)
{
    func();
}

will correctly generate a "missing prototype" warning from some
compilers (e.g., Microchip's C18).

--
John W. Temples, III

2010\07\22@132857 by Bob Ammerman

flavicon
face


> On Thu, 22 Jul 2010, Paul Hutchinson wrote:
>
>> The parameter identifiers in a C function prototype are optional
>
> No, they aren't.  A function declaration that doesn't specify the
> number and types of the parameters is not a function prototype.
> Something like this:

Well, yes they are. If you read carefully the original comment stated that
the parameter _identifiers_ were optional. The parameter types are not. So,
for example all three of the following prototypes function identically:

void func(int,char,int *);
void func(int i, char c, int *p);
void func(int isomething, char csomethingelse, int *pointer_to_yet_another)

-- Bob Ammerman
RAm Systems


2010\07\22@134340 by Isaac Marino Bavaresco

flavicon
face
Em 22/7/2010 12:51, Matt Rhys-Roberts escreveu:
{Quote hidden}

Example (pseudo-code, not compiled):

static char portisopen[2] = { 0 , 0 };

signed char OpenSPI( char port, unsigned char sync_mode, unsigned char
bus_mode, unsigned char smp_phase )
{

   if( port < 1 || port > sizeof portisopen / sizeof portisopen[0] )
       return -1;

   if( portisopen[port-1] != 0 )
       return -1;

   portisopen[port-1] = 1;

   if( port == 1 )
   {
   // Initialize the hardware of SPI port 1 here.
   }
   else
   {
   // Initialize the hardware of SPI port 2 here.
   }
 
   return 0;
}

void CloseSPI( char port )
{
   if( port < 1 || port > sizeof portisopen / sizeof portisopen[0] )
       return -1;

   if( portisopen[port-1] == 0 )
       return;

   if( port == 1 )
   {
   // Stop the hardware of SPI port 1 here.
   }
   else
   {
   // Stop the hardware of SPI port 2 here.
   }

   portisopen[port-1] = 0;
}

unsigned char TransceiveSPI( char port, unsigned char data_out )
{
   unsigned char data_in;

   if( port < 1 || port > sizeof portisopen / sizeof portisopen[0] )
       return -1;

   if( portisopen[port-1] == 0 )
       return 0;

   if( port == 1 )
   {
   // Send data_out and receive_data_in to/from SPI port 1.
   }
   else
   {
   // Send data_out and receive_data_in to/from SPI port 2.
   }

   return data_in;
}


{Quote hidden}

I understand, your questions were more about of C language techniques
than implementation...
Welcome to the C language world!


Best regards,

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\07\22@140059 by Paul Hutchinson

picon face
{Quote hidden}

Only identifiers are optional, the types are not optional. Your example
leaves out both making it an invalid function prototype.

Here's an example of a valid prototype in ANSI C without an identifier.

void func(int);

It gives the type and number of parameters but does not include an
identifier.

The C99 standard (Section 6.7.5.3 paragraph 6) says:
"A parameter type list specifies the types of, and may declare identifiers
for, the
parameters of the function."

Paul Hutch

2010\07\22@152812 by Alan B Pearce

face picon face
> Please can someone faimilar with C kindly help clear up my confusion
here?

Well I don't really claim familiarity with C, but have done a little bit
with it.

> I'm declaring a couple of SPI function prototypes, see below. Not
> wishing to waste too much time testing awkward things, shouldn't the
> common variables (sync_mode, bus_mode etc.) be specified more uniquely
> for each SPI channel? Will the following, although it compiles ok,
cause
{Quote hidden}

Note that the variables declared inside each function are not declared
'static' so each time the function gets called they are recreated on the
stack, and are unique to that function. So the variables inside OpenSPI1
are different variables to OpenSPI2, even though they have the same
name. The scope of each name is limited to the code inside that
function. The variables are cleared to all zeros on creation on the
stack if I understand the C standard correctly, but may need correction
here. If you attempt to look at the values of these variables with a
debugger such as MPLAB/ICD combination, you get strange results unless
you are single stepping through the code inside that function.

When the function terminates by executing a 'return' the variables are
removed from the stack, and no longer exist. At this stage your debugger
will again go strange with the values of these variables (IIRC it gives
an error message that says they are 'Out of Scope'). If the other
routine is now called the variables for that function are automatically
created on the stack, and are unique to that function, even if they
happened to reside at the same position in the stack.

If the variables are declared 'static' in addition to the other
attributes they have, then they are created in the normal RAM area, and
are persistent between calls to the function, i.e. they keep their last
value from the last time the function was called, or are uninitialized
before the first call of the function unless initialisation values are
declared. But they are still separate variables even though they have
the same name. I don't know how the debugger identifies which one you
wish to watch, I haven't had occasion to go down this road at this
stage.


--
Scanned by iCritical.

2010\07\22@154437 by Isaac Marino Bavaresco

flavicon
face
Em 22/7/2010 16:28, alan.b.pearcespamKILLspamstfc.ac.uk escreveu:
> Note that the variables declared inside each function are not declared
> 'static' so each time the function gets called they are recreated on the
> stack, and are unique to that function. So the variables inside OpenSPI1
> are different variables to OpenSPI2, even though they have the same
> name. The scope of each name is limited to the code inside that
> function. The variables are cleared to all zeros on creation on the
> stack if I understand the C standard correctly, but may need correction

No, automatic variables are not cleared upon function entry, they may
contain garbage.

Global variables are cleared to zero at program start, but some
tool-chains support a switch
to disable this feature.

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\07\23@171915 by Barry Gershenfeld

picon face
> No, automatic variables are not cleared upon function entry, they may
> contain garbage.
>

Even more dangerous...they may sometimes contain the correct value :-o

My understanding about function parameters are that the compiler needs to
know how much (generally, stack) space to allocate for each variable so
things don't get misaligned.  Error messages from the compiler are about the
consistency between the declaration and usage of a function.  I think it is
safe to say that if a variable is named in a function template, it is
ignored.  Hmm, I can test this...Well, in a sample size of 1, the compiler
didn't care

2010\07\26@042502 by Matt Rhys-Roberts

flavicon
face
On 22/07/2010 18:43, Isaac Marino Bavaresco wrote:

[snip]
> I understand, your questions were more about of C language techniques
> than implementation...
> Welcome to the C language world!
>
>
> Best regards,
>
> Isaac

Many thanks for all the above, I begin to see your method more clearly.

Regards
Mat

2010\07\26@044000 by Matt Rhys-Roberts

flavicon
face
On 22/07/2010 20:28, .....alan.b.pearceKILLspamspam.....stfc.ac.uk wrote:

[snip]
{Quote hidden}

Regards,
Mat

2010\07\27@042905 by Tamas Rudnai

face picon face
On Thu, Jul 22, 2010 at 8:43 PM, Isaac Marino Bavaresco <
EraseMEisaacbavarescospam_OUTspamTakeThisOuTyahoo.com.br> wrote:

> No, automatic variables are not cleared upon function entry, they may
> contain garbage.
>

That's why you need to initialize all variables you have. Not sure about C18
but some compilers throws warnings at compilation time about using
uninitialized variables. As a practise I found it easier to write "int myVar
= 0;" as opposed to "int myVar;" so the initialization will not be forgotten
-- however, sometimes it is only a way to suppress those warnings...

Tamas


Global variables are cleared to zero at program start, but some
> tool-chains support a switch
> to disable this feature.
>
> __________________________________________________
> Fale com seus amigos  de graça com o novo Yahoo! Messenger
> http://br.messenger.yahoo.com/
>
>


'[PIC] C18 function prototypes (pic18f8627)'
2010\08\26@194316 by Gerhard Fiedler
picon face
Tamas Rudnai wrote:

> On Thu, Jul 22, 2010 at 8:43 PM, Isaac Marino Bavaresco wrote:
>
>> No, automatic variables are not cleared upon function entry, they may
>> contain garbage.
>
> That's why you need to initialize all variables you have. Not sure
> about C18 but some compilers throws warnings at compilation time
> about using uninitialized variables. As a practise I found it easier
> to write "int myVar = 0;" as opposed to "int myVar;" so the
> initialization will not be forgotten -- however, sometimes it is only
> a way to suppress those warnings...

(A bit late here, but still...)

Doing this out of habit is dangerous.
If 0 is a sensible initial value for myVar -- that is, it will result in
the correct output/action if myVar is not otherwise set --, it's the
right thing to do.
But if this is not given -- sometimes there is no sensible initial value
for a variable --, setting myVar to 0 as a matter of habit just
suppresses the compiler warning without actually solving the problem
that there may be code paths where myVar is not initialized to something
sensible. It essentially disables the compiler warning.

Gerhar

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