We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm working with the RealView Compiler and have a strange problem with the usart.
I've installed one typedef struct in a headerfile - when I try to install a array of this struct in the c-file (as global struct variable) - I'm not able to get some printf() messages over the usart (no data abort or anything else (the program seems to work) - only no messages over the usart..
When I install the array of this struct in a function within this c-file (not global) - everything works ok...
Could there be a problem with less stack size?
tobi
I asked you to specify all required facts about your system and your problem, or we will not be able to answer any questions.
You haven't even told us what processor you run. It seems to be an Atmel ARM chip but you are spending a huge amount of time trying to avoid facts. Why are you so against facts? Because you specifically don't want any help?
now I found the problem - it was the struct but I don't know why...
I use the AT91SAM7S256 processor - (sorry for missing this message) - I think that the problem is undependent of the prozessor.. I work with Realview MDK.
#define size 20
typedef struct my_struct { unsigned char Data[size]; }MY_STRUCT;
If I write Data[20] - everything is working fine - but if I use the #define, the usart and anything else which use a clock doesn't work...
It seems that the #define is not configurated when I enter the c-file with the global variable of the struct
MY_STRUCT struct_array_global[number];
number is a define too...
In a local function I only init a ptr to the head of this global array.
Maybe everybody of you coud explain me why the version with the #define size don't work...
best regards tobi
There are many places where you may make mistakes when using #define, and we don't have access to the full code.
But you should avoid using #define with lower-case symbol names. It is common practice to always use upper-case letters for a #define, just to very clearly inform other users that they may need to look closer at the definition to be able to understand the code.
The name 'size' for a #define would also make any declaration for a parameter or local variable with the name 'size' to fail or give very unpredictable results. The code:
int copy_struct(void* p,unsigned size) { }
would be parsed by the compiler as the broken code sequence:
int copy_struct(void* p,unsigned 20) { }
You should also avoid the use of generic names for your defines - they are not defined in any name space, so generic names gives a large chance of collisions.
In your header file, you may write something like:
#define SIZE_OF_X 20 #define NUMBER_OF_X_ENTRIES 10 typedef struct { unsigned char data[SIZE_OF_X]; } mystruct_t; extern mystruct_t myarray[];
In your source file, you may write something like:
#include "myheader.h" mystruct_t myarray[NUMBER_OF_X_ENTRIES];
thanks for the useful information..
Is is possible that the struct is too large for the data segment? What are the steps to install the struct in the external sram?
extern mystruct_t myarray[];
Is this line of code necessary that the code is working? I only have the typedef struct definition in the headerfile.
Most programs consists of more than a single C file.
extern mystruct_t myarray[] in the header file allows other C files (that includes the header file) to know about the existence of a global variable myarry.
If your myarray variable is not expected to be known to other source files, then you should probably hide it. No information about it in the header file, and writing:
static mystruct_t myarray[NUMBER_OF_X_ENTRIES];
in the single source file where the variable should be used. This will hide the variable from the linker. To the linker, it will just be an anonymous block of memory (together with all other static variables in the same source file) without any name.
I'd have thought that you'd get an error or at least a warning if that were the case.
The questions you're asking suggest that you're very much a newbie to 'C' programming - yes? In this case, it is much more likely to be due to errors in your 'C' than any hardware problems...
at the moment I have one headerfile where all other headerfiles where included - so in every c-file I only include this headerfile...
If I use in one of this heatherfiles to define my struct -> then I have to use extern to define a variable, haven't I? So that could be the reason for my strange errors?
header.h #include header1.h #include header2.h
header1.h typedef struct {...}STRUCT_VAR; extern STRUCT_VAR struct_array[];
header1.c #include <header.h> STRUCT_VAR struct_array[NBR_STRUCT];
BTW, is this a common way? Or is it better to have in every c-file all #include <header.h> which are needed in the specific c-file?
yes you are totally right.... but could you explain me how I have to organize all c-files, using nearly the same headerfiles?
e.g. there's a lib-headerfile from Keil, which I used in every c-file to get access to registers with inline functions...
Is it a better way to include this headerfile in every c-file or is it much better to have one headerfile which includes all other headerfiles?
If the compiler is fast in comparison to the project size, and you want to be lazy, you might add most of your includes into a "global" header file and include from all other source files.
If the compiler supports precompiled headers, then it is normally an advantage to make user of a global master header file.
Anything that shouldn't be generaly visible may then be put into the single source file that uses them, or a specific header file that is only included for the set of source files that are allowed to know this extra information.