Searching \ for '[PIC]: C expert required' 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/languages.htm?key=c
Search entire site for: 'C expert required'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: C expert required'
2004\05\05@095621 by hael Rigby-Jones

picon face
{Quote hidden}

>{Original Message removed}

2004\05\05@100829 by Ake Hedman

flavicon
face
>The problem is that I don't want the overhead of checking for the
functions
>existance at run time, I want to offload this task to the pre-processor
>(this will be running on a PIC, forgot to put the subject tag in
though!).

OK, that's a totally different thing then....

I usually end up with defines in this situation and it often get rather
messy. But with a central "options.h" header file it is still workable.

Regards
/Ake

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

2004\05\05@102550 by Anthony Toft

flavicon
face
{Quote hidden}

This is the only way _I_ can think of to avoid having the linker scream about
unresolved symbols. One question though, are you attempting the infeasable
(notice not impossible) task of making modules that are "all things to all
mankind"?

As a software engineer, I can't plead with you enough not to do this, code
maintenance will be a nightmare, with each new #ifdef line of code needing
regression testing of ALL the code pathways, and they will go up exponentally.

If you are just trying to ensure the modules are compiled in properly, just let
the linker do it for you, save you reinventing the wheel

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2004\05\05@103832 by hael Rigby-Jones

picon face
{Quote hidden}

The object of this is actually to improve maintainability (in theory). My
device is based on a common PCB, but with several different options fitted.
It is essentialy a fibre optic transceiver, but may only be fitted with a
receiver OR a transmitter in some cases.  There are several different
transmitters and receivers that can be fitted, all of which need different
control algorithms.  In total there are dozens of different variants.

I was hoping to have a scheme whereby I can just include the relevant header
files for each of the main functional blocks, and the code will automagicaly
be compiled with the correct functions.  There is also a comprehensive
communications subsystem for control and monitoring.  The scheme that I want
would automaticaly make commands return a "function unavailable" to the host
controller.

I have the functionality I require at the moment, but only through checking
return values of functions at runtime which is a not insignificant overhead
on a small PIC.  If you have any suggestions to make configuring the
software somewhat foolproof I would be very glad to hear them!

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.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
postmasterspamspam_OUTbookham.com.

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2004\05\05@110605 by James Caska

flavicon
face
If you were writing this in java then you could use the concept of an
'interface' to represent the definition of the functionality,
TransmitterInterface, ReceieverInterface etc and then you could
implement each of the different modules you have in mind as a java class
that implements that interface. You could then create a factory pattern
which binds in the implementations available. The functionality
available and classes 'automagically' bound is determined by the factory
used, and you can then create a runtime Exception if the required
functionality is not available in that factory at runtime.

I think you have very elegently described one of the problems nicely
addressed by the java language... Not that it helps you much for the 'C'
problem at hand.

Cheers,

James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\05\05@151605 by Sergio Masci

picon face
----- Original Message -----
From: Michael Rigby-Jones <KILLspamMichael.Rigby-JonesKILLspamspamBOOKHAM.COM>
To: <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU>
Sent: Wednesday, May 05, 2004 2:55 PM
Subject: Re: [PIC]: C expert required


{Quote hidden}

>{Original Message removed}

2004\05\05@170729 by Wouter van Ooijen

face picon face
>(snip)
> used, and you can then create a runtime Exception if the required
> functionality is not available in that factory at runtime.
>
> I think you have very elegently described one of the problems nicely
> addressed by the java language...

It does, except that it does so at a rather high cost in code size and
execution time. No problem on a modern desktop computer, but inadequate
for a lowly PIC.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu

2004\05\06@001630 by William Chops Westfield

face picon face
What we used to do was create a "stub" file containing symbol
definitions for all the "optional" functions in the system, all
pointing at the same tiny piece of code:

get_temp:
get_humid:
get_pres:
get_alt:
       move reg, FALSE
       return

Assembler was used to equate multiple symbols to the same C-callable
function...   A simpler version uses more space and has tiny functions
for each full function that might be absent.

(ok, actually we had one such stub file for each possible image that
was built.  I'm not entirely sure whether you can do magic with
libraries to put all the possible stubs in a single file, and only use
the ones you want.  You COULD even parse linker output to generate the
appropriate stub file on the fly.)

Then the mainline code would look like:

       if (get_temp(&temp)) {
           /*
            * We have a temp.  Do stuff with it...
            */
           calc_stuff(temp);
           save_log(temp);
       }

Will something like that help?

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\05\06@025922 by hael Rigby-Jones

picon face
{Quote hidden}

That is exactly what I have now.  All functions that may or may not be
present return a bit variable (not ANSI but a usefull HiTech extension).

in temp.c

bit get_temperature( int *temperature )
{
       *temperature = read_adc( ADC_CHAN1 );
       return 1;
}

in temp_dummy.c

bit get_temperature( int *temperature )
{
       return 0;
}

In my makefile I simply link in the modules as I need them.  The system
works, and works well from a confiuration management point of view.
However, the code for calling the stub functions and the stub functions
themselves are effectively redundant.  I won't ever have a device that
implements everything, it simply not possible, so including the calls to all
these stubs is an overhead I really need to remove.  The previous code was
not very modular, with lots of global varibles and maintenance was a
problem.  However, execution time was significantly faster than the code I
have now, mainly due to passing values between modules via access functions
rather than globals.

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.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
EraseMEpostmasterspambookham.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\05\06@031622 by hael Rigby-Jones

picon face
{Quote hidden}

HiTech does not remove calls to empty stubs, something I am surprised about
given it's otherwise excellent reputation for optmisation.  However, this
technique still works if you just don't assign a value to the dummy macro:

#define func1 func1_present     // call function in this configuration
#define func1                   // don't call function

The compiler does however give a warning that no code is generated for the
expression. With a bit more work, defining function-like macros works and
give no warnings:

#define func1(x) func1_present(x)       // call function in this
configuration
#define func1(x)                                // don't call function



{Quote hidden}

I do like this idea in some respects. However, it has the downside that you
would have to remember to rebuild the library if any functons were added.

>I prefer the first method since a good compiler will also be
>able to remove any code that generates arguments to your
>function which are not used.
>
><plug>
>The XCSB compiler (structured BASIC) does dead code elimiation
>and does remove unused functions from the executable :-) </plug>

I downloaded the demo a few months back and gave it a try and it certainly
does seem to generate tight code.  I don't know how well this is selling for
you, but it blows Picbasic Pro etc out of the water IMO.

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.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
RemoveMEpostmasterTakeThisOuTspamspambookham.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\05\06@081049 by Gerhard Fiedler

picon face
> I was hoping to have a scheme whereby I can just include the relevant header
> files for each of the main functional blocks, and the code will automagicaly
> be compiled with the correct functions.

What I usually do in such situations is to use normal defines that switch
on or off certain functionality. Properly structured, I think this is not
inferior to the scheme you envision, and can even be more flexible -- in
the sense that not always everything can be sensibly decided by the
presence or not of functions. For example a certain function could do one
thing in one case and a slightly different thing in another case (more or
less functionality or return codes or something the like).

In the case you describe, possibly having a central configuration file with
all the defines for receivers and transmitters could provide such a
solution. The defines also control what gets included and what not. It may
not be that much different having such a project configuration file that's
different for each project than having different includes for each project.
It may even be a more modular solution, with all the configuration together
in one file.

Gerhard

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\05\06@083538 by Anthony Toft

flavicon
face
> transmitters and receivers that can be fitted, all of which need different
> control algorithms.  In total there are dozens of different variants.

Aha!!!!

I have done a similar thing in the past, what I did was make a dummy
library with the exact same external interfaces as the real library. The
hardware implementation is encapsulated in the library, the software
just needs to know not to barf when receive gets no data all the time
(which it probably does already).

This comes with the overhead of making empty function calls and all the
stack work that's involved, but a decent optimizer should be able to
work that out.

No conditional compiling just conditional linking, this _reduces_ your
codebase and if each library is properly independant you can reuse it
through projects (a good thing)

The main gotcha on this is the interface spec. define it, etch it in
stone and stick to it. I can gather a GCC example of this if you'd like
to see what I am refering to.

--
Anthony Toft <EraseMEtoftatspamspamspamBeGonecowshed.8m.com>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\05\06@095534 by hael Rigby-Jones

picon face
{Quote hidden}

Anthony, that would be very helpful!

Thanks

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.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
spamBeGonepostmasterSTOPspamspamEraseMEbookham.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\05\06@141002 by Sergio Masci

picon face
Michael Rigby-Jones wrote

> >Sergio Masci wrote
> >
> HiTech does not remove calls to empty stubs, something I am surprised about
> given it's otherwise excellent reputation for optmisation.  However, this
> technique still works if you just don't assign a value to the dummy macro:
>
> #define func1 func1_present     // call function in this configuration
> #define func1                   // don't call function
>
> The compiler does however give a warning that no code is generated for the
> expression. With a bit more work, defining function-like macros works and
> give no warnings:
>
> #define func1(x) func1_present(x)       // call function in this
> configuration
> #define func1(x)                                // don't call function

Yes I do something similar for debug code (not on the PIC though - I don't use C
on the PIC ;-)

{Quote hidden}

I'm sure the linker would remind you :-) In any case you should be able to use
multiple libraries so rebuilding should be cut down to a minimum.

> >
> ><plug>
> >The XCSB compiler (structured BASIC) does dead code elimiation
> >and does remove unused functions from the executable :-) </plug>
>
> I downloaded the demo a few months back and gave it a try and it certainly
> does seem to generate tight code.  I don't know how well this is selling for
> you, but it blows Picbasic Pro etc out of the water IMO.

Actually some of the things I've read about some of the available PIC C
compilers lead me to think XCSB would blow some of these out of the water as
well. I'll have to do some real comparisons and publish the "good" ones ;-)

The free version is selling like hot cakes, the non-free versions not so
hot-cake-ish.

Regards
Sergio Masci

http:://http://www.xcprod.com/titan/XCSB - optimising PIC compiler

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\05\07@045418 by Alan B. Pearce

face picon face
>Actually some of the things I've read about some of the available
>PIC C compilers lead me to think XCSB would blow some of these out
>of the water as well. I'll have to do some real comparisons and
>publish the "good" ones ;-)
>
>The free version is selling like hot cakes, the non-free versions
>not so hot-cake-ish.

Ain't that always the way :))
Trouble is those free dollars are not worth anything :)))))

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

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