Programming question

[Ax_6]

Hello everybody!

I wanted to make a little library for PICs in mplab x and I was wondering how can I make definitions (#define) able to be recognized by the library.
For instance if I write in the main file

Code: [Select]

#define _XTAL_FREQ 'number'then the file pic.h know its value and makes its counts. Starting from that, I've tried to do as follow
In the main.c file I wrote:

Code: [Select]

#define MYVALUE 'number'And in the file mylibrary.h I wrote:

Code: [Select]

#define NICEVALUE MYVALUE*2 (just an example)As soon as I use NICEVALUE in mylibrary.c the compiler says that it does not recognize MYVALUE.. so, what am I missing?

Thanks!

[IanB]

You are missing how the pre-processor works. Read up on the C pre-processor.

Also read up on header (.h) files and how they are used.

[kfitch42]

When dealing with the C preprocessor (i.e. all that #... stuff) order matters.

e.g.

Code: [Select]

/* main.c */
#define MYVALUE 1234
#include <mylibrary.h>
In this case mylibrary.h would know MYVALUE, but in the following case it wouldn't

Code: [Select]

/* main.c */
#include <mylibrary.h>
#define MYVALUE 1234

By VERY careful though! in the first case mylibrary.h knows the value of MYVALUE when compiling main.c. BUT, mylibrary.h would not know the value of MYVALUE when compiling mylibrary.c (or any other file). This is why, as a rule of thumb*, #define's only live in header files. E.g.

Code: [Select]

/* myvalue.h */
#define MYVALUE 1234


Code: [Select]

/* mylibrary.h */
#include <myvalue.h>
#define NICEVALUE (MYVALUE*2)

And then both main.c and mylibrary.c can include mylibrary.h, and get the same value for MYVALUE.


P.S.
* as a rule of thumb you should always think before applying rules of thumb.

[Ax_6]

Got it! Thank you really much.
At this point what would be the best way (if there is any) to set some constant values for the library from the main.c without allocating any space in the RAM?
For example I say in my main "constant value X is 23" and then mylibrary.c knows and uses it.

[kfitch42]

I would suggest having an initialization function in the library. e.g.

Code: [Select]

/*main.c*/
...
mylibrary_initialize(23);
...


Code: [Select]

/*mylibrary.c*/
static int mylib_X;
void mylibrary_initialize(int X) {
  mylib_X = X;
  /* ... configure some registers ...  */
}
Generally the only reason to resort to the preprocessor is if you can't achieve good enough performance due to the extra memory reference for reading X ... something that is very unusual/unlikely.

[AlfBaz]

Got it! Thank you really much.
At this point what would be the best way (if there is any) to set some constant values for the library from the main.c without allocating any space in the RAM?
For example I say in my main "constant value X is 23" and then mylibrary.c knows and uses it.

I don't think so. Defines are used by the pre-processor. It goes and substitutes all of the defined placeholders with whatever you have defines it as, then it passes it to the compiler.
You could define your value x as an "extern" variable which you can declare and initialise in main. the linker will take care of the rest

Edit: You could declare your value X as an "extern" variable within your lib, the instantiate and assign the appropriate value in main

[Ax_6]

I would suggest having an initialization function in the library. e.g.

Code: [Select]

/*main.c*/
...
mylibrary_initialize(23);
...


Code: [Select]

/*mylibrary.c*/
static int mylib_X;
void mylibrary_initialize(int X) {
  mylib_X = X;
  /* ... configure some registers ...  */
}
Generally the only reason to resort to the preprocessor is if you can't achieve good enough performance due to the extra memory reference for reading X ... something that is very unusual/unlikely.

Yeah, that was the solution I knew and tried to avoid for the reason that the compiler is allocating 4 byte for X that finally is just useless.
The solution of AlfBaz is interesting after all, declaring an extern const value seems to be a possible way. Thank you all!

[IanB]

Remember that pre-processor macros like #define don't necessarily save space.

Suppose you do this:

/* program.h */
#define MYCONST 0x4433FF1E

This defines a numeric constant that is 4 bytes long (it requires 4 bytes of storage).

Now suppose you reference this constant in 10 different places in your main program. That constant will appear 10 times, and thus take up 40 bytes of storage in total, since each copy is separately and individually allocated. Using a pre-processor macro like this is not necessarily more (or less) efficient than other techniques.

[kfitch42]

Yeah, that was the solution I knew and tried to avoid for the reason that the compiler is allocating 4 byte for X that finally is just useless.
The solution of AlfBaz is interesting after all, declaring an extern const value seems to be a possible way. Thank you all!

The extern doesn't save space. Using the preprocessor would probably be the only way to avoid using those 4 bytes of RAM. The way the C spec is written an extern const still needs to take up space in RAM. In fact the C spec explicitly allows for modifying a const value at runtime 

So the initialization function is a slightly cleaner approach (IMNSHO). And, it actually gives the library control of how constant the constant is. The only downside is the increased code size (for the initialization function and a call to it), but it seems you already prefer larger code to larger RAM usage.

I think the most DRY (Don't Repeat Yourself) approach that avoids allocating 4 'useless' bytes of RAM would be to have the user of mylibrary to create myvalue.h like I mentioned before.

[kfitch42]

Remember that pre-processor macros like #define don't necessarily save space.

Suppose you do this:

/* program.h */
#define MYCONST 0x4433FF1E

This defines a numeric constant that is 4 bytes long (it requires 4 bytes of storage).

Now suppose you reference this constant in 10 different places in your main program. That constant will appear 10 times, and thus take up 40 bytes of storage in total, since each copy is separately and individually allocated. Using a pre-processor macro like this is not necessarily more (or less) efficient that other techniques.

The key here (when thinking about microcontrollers) is which storage is it taking up. Code space or RAM space? For many micros code space is much less constrained than RAM space.

So the form of reference matters:

Code: [Select]

const int myconst = MYCONST; /* <= Probably 4 bytes of RAM space for myconst */
bar = foo * myconst; /* But this multiply *might* take fewer instructions than the next example */


Code: [Select]

bar = foo * MYCONST; /* MYCONST may exist only as immediate values in a few (more?) instructions */

Of course the proof of the pudding is in the eating ... so if that RAM (or code) space is precious in your application you would have to try each of these and see what the compiler produces.

[Ax_6]

Remember that pre-processor macros like #define don't necessarily save space.

Suppose you do this:

/* program.h */
#define MYCONST 0x4433FF1E

This defines a numeric constant that is 4 bytes long (it requires 4 bytes of storage).

Now suppose you reference this constant in 10 different places in your main program. That constant will appear 10 times, and thus take up 40 bytes of storage in total, since each copy is separately and individually allocated. Using a pre-processor macro like this is not necessarily more (or less) efficient than other techniques.

That's true, but as kfitch42 said in this case I don't care how much space the code will take, I'm interested only in the RAM.

Yeah, that was the solution I knew and tried to avoid for the reason that the compiler is allocating 4 byte for X that finally is just useless.
The solution of AlfBaz is interesting after all, declaring an extern const value seems to be a possible way. Thank you all!

The extern doesn't save space. Using the preprocessor would probably be the only way to avoid using those 4 bytes of RAM. The way the C spec is written an extern const still needs to take up space in RAM. In fact the C spec explicitly allows for modifying a const value at runtime 

So the initialization function is a slightly cleaner approach (IMNSHO). And, it actually gives the library control of how constant the constant is. The only downside is the increased code size (for the initialization function and a call to it), but it seems you already prefer larger code to larger RAM usage.

I think the most DRY (Don't Repeat Yourself) approach that avoids allocating 4 'useless' bytes of RAM would be to have the user of mylibrary to create myvalue.h like I mentioned before.

You are right, my bad. I won't save RAM space anyway. And yes I agree, a function is a bit easier to understand.

So... yeah thanks again for the help I'm going to try those different solutions and see which one take less RAM space and It's easier to modify. May the init will be the best...
If you have other ideas keep posting them! This topic is becoming really interesting =D

[andersm]

In fact the C spec explicitly allows for modifying a const value at runtime

The standard does not mandate it. The C99 spec explicitly states that non-volatile const objects may be placed in read-only storage, and that storage does not even have to be allocated if the object's address is never used.

[kfitch42]

The standard does not mandate it. The C99 spec explicitly states that non-volatile const objects may be placed in read-only storage, and that storage does not even have to be allocated if the object's address is never used.

Generally, the compiler doesn't know if the object's address will ever be used for global scope objects (i.e. not 'static') since it doesn't know how the object will be used in other compilation units. Maybe some fancy compiler/linker could figure it out and unallocate the space, but I have never seen that happen(not that I have looked very hard).

Hmmm, it seems my memory of the spec is not as good as I thought it was. I made a little program to try it out, and the results weren't quite what I expected. Firstly it seems the only way in C to cast away const'ness is to take an address (C++ has const_cast for this purpose). Secondly it seems modern compilers do put const values in read-only memory (at least with gcc on 64-bit linux).

Code: [Select]

/* consttest.c */
const int x = 1;

void deviousFunc(int y) {
  *((int*)&x) = y;
}


Code: [Select]

/* constmain.c */
#include <stdio.h>
void deviousFunc(int y);
extern const int x;

int main(int argc, char** argv) {
  printf("X at start %d\n",x);
  deviousFunc(2);
  printf("X at start %d\n",x);
  return 0;
}


Code: [Select]

$ gcc constmain.c consttest.c -Wall -o consttest
$ ./consttest
X at start 1
Segmentation fault (core dumped)

Digging in the seg fault occured at the assignment in deviousfunc.

[andersm]

The C99 standard says (§6.7.3) "If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined." and the C++03 standard says (§7.1.5.1) "Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior." so modifying a const object may in fact not be allowed at all.

[kfitch42]

Looks like that language is even in the C89 spec. So my memory is WAY off.

Shame on gcc for not warning on the obvious naughtyness in my program.

When all else fails ... blame the tools

[Rufus]

Shame on gcc for not warning on the obvious naughtyness in my program.

You use a cast to tell the compiler you know what you are doing then expect the compiler to tell you you don't?

[IanB]

Compilers will help you if you declare your intent. For example:

Code: [Select]

const int MyGlobalValue = 10;

int main()
{
  int *ptr = &MyGlobalValue;
}


Code: [Select]

1>------ Build started: Project: ConstExperiment, Configuration: Debug Win32 ------
1>  main.cpp
1>c:\visual studio 2010\projects\constexperiment\main.cpp(5): error C2440: 'initializing' : cannot convert from 'const int *' to 'int *'
1>          Conversion loses qualifiers