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 use a Cypress Fx2. It's no problem to write a value to dcf.sekunde but if i set dcf.minute to 0 or such a other value, the controller will stops/crash.
I'm not sure if the struct definition is correct or if i must reserver a address block for it. i hope someone can help me.
Thanks
Sorry for my bad English.
FX2_DCF-Clock.h
typedef xdata struct signal { unsigned char sekunde; unsigned char minute; unsigned char stunde; unsigned char tag; unsigned char wochentag; unsigned char monat; unsigned char jahr; unsigned char synkro; unsigned int fehler_zaehler; }tdcf; extern tdcf dcf;
.
FX2_DCF-Clock.c
txdata tdcf dcf;
if(dcf.sekunde>59) { dcf.synkro=KEINSYNK; dcf.sekunde=0;
crash/stop
dcf.minute=0; dcf.stunde=0; }
"I'm not sure if the struct definition is correct ..."
Since types do not occupy memory, it's not very meaningful for them to have a memory space specifier. It's more meaningful for allocated data objects to have the memory space specifier.
typedef struct signal { unsigned char sekunde; unsigned char minute; unsigned char stunde; unsigned char tag; unsigned char wochentag; unsigned char monat; unsigned char jahr; unsigned char synkro; unsigned int fehler_zaehler; }tdcf; extern tdcf xdata dcf;
tdcf xdata dcf;
Your typedef does two things; defines 'struct signal' and defines a new type (alias) for 'struct signal' named 'tdcf'. The structure tag ('signal') and the typedef name 'tdcf' are separate things. Combining the way you have done is legitimate.
Thx's for your information. Now it is a little bit clearer. To remove the Problem I switch to internal ram by removing "xdata".
How can I define on which address the struct will be created ??
for normal variables:
xdata unsigned char xOverflowCounter2 _at_ 0xE038;
"How can I define on which address the struct will be created ?"
Why would that be necessary for an internal RAM data object?
"for normal variables"
A struct _is_ a normal variable.
"Why would that be necessary for an internal RAM data object?"
Not for the internal Ram but in the extern Ram it will be easier to read and write via usb vom a pc, if you now the address.
Locking a lot of things down to absolute addresses can quickly become problematic.
Sometimes it can be good to produce a "list-of-lists". One single data structure that contains the address and size of other structures.
Another thing to think about is that the structure may change depending on version. Knowing where it is doesn't imply that you know enough about its contents to really know how to read/write it.
Priority one must be a method to let the PC know what firmware version you have in your device.
It is quite common with:
typedef struct tag_1 { } tag_2;
tag_1 is the name it has within the "struct" namespace, i.e.:
struct node { struct node* next; int value; }; struct node *head; // ok node *tail; // invalid - "struct" keyword needed.
tag_2 is the type-defined name of the struct, i.e. intended for:
typedef struct { unsigned char age; char* name; } person_t; person_t charlie; person_t benny;