Hi,
I'm wondering if I am doing something wrong here. I am trying to store an array for a large 256 byte look-up table.
I have a pretty small 8051 MCU of 8 KB flash memory (IROM), 256 bytes internal RAM (IRAM) and 256 bytes on-chip external RAM (XRAM).
Prior to adding this look-up table, my current build from Keil reports:
"Program Size: data=54.1 xdata=0 code=1984"
I take that to mean I am using 54 bytes of IRAM, 0 bytes of XRAM, and 1984 bytes of IROM?
Here is the variable declaration I am using:
code unsigned char CRC8LookupTable[256];
When I define the CRC8LookupTable and populate values, I get the Segment Too Large error.
If you use "code" doesn't that store the values in ROM, which I should have plenty of space for?
Is there something else I need to add to that variable declaration?
Thanks -Tim
I don't see how that is in any way bizarre?
That is the standard way that you would declare & define a variable in 'C'.
The Keil-specific 'code' qualifier is applied in exactly the same way as the standard 'volatile' and 'const' qualifiers.
c-faq.com/.../decldef.html
@Andrew
Qualifiers. Good word to learn, didn't know that. I told you I am not a C wizard.
Okay -- so, for volatile & extern and other qualifiers. You don't re-use them when you define the variables in the source, right?
I only use the qualifier for volatile in the declaration, right? (add in an extern if you want too!)
volatile unsigned char SomeData;
Now we go to the source, no more qualifier required since it is in the declaration in the header.
unsigned char SomeData = 1;
Great we got variable we can use safely with interrupts. But volatile qualifier required in the definition? How is that not bizarre, how qualifiers are used differently between these cases?
I'm sure their is a reason for the compilation process, but I'm talking about end user experience here of someone typing in text.
Then you have the example of CODE as a qualifier. It has to be used as a qualifier in both the declaration and definition unlike volatile?
For my knowledge, does Keil C51 treat the XDATA qualifier the same way?
I'm sure one day I'll need to tap into XDATA. I was looking at the memory model stuff and everything else while diving into this yesterday.
No. Quite the opposite: you do "re-use" them!
The declaration must match the definition in both type and qualifiers
If you're sharing the declaration with other modules (and why else would you put it in a header file?) you add 'extern'
some.h
extern volatile unsigned char SomeData ;
some.c
volatile unsigned char SomeData = 1;
Only a definition can contain an initialisation.
Are you sure on volatile? I'm looking at some code from another programmer who built some PIC routines, and I see they use volatile on both the definition and declaration.
Are you sure that the compiler cares? If you add volatile to the definition or not when you initialize the variable, the compiler doesn't utter a warning / error either way. I'm sure there is some way (memory map or something) to see if the variable is being optimized or not.
But for extern, you clearly need it in the declaration....
I actually appreciate the help Andrew! This like a master class in qualifiers...!
I have no skin in the game -- if the compiler wants volatile in both declaration and definition. It can have them!
TECHNICALLY YOU DONT NEED THE EXTERN IN THE DECLARATION IN A HEADER (IN C) BUT IT IS COMMON TO SEE IT THERE.
STOP SHOUTING!
The 'extern' is only optional for function declarations (ie, prototypes):
www.youtube.com/watch
HA? You guys know this one?
Good stuff here today.
NO. VARIABLES TOO. CHECK YOUR DOCUMENTS MORE THOROUGHLY. OR TRY IT YOURSELF.
DID U CHECK? NOW I AM FINISHED PARTYING AND I CAN REPLY MORE. IF U MISS THE EXTERN IT IS A TENTATIVE DECLARATION. IN C YOU CAN HAVE MANY OF THEM. GO CHECK IT OUT AND LEARN SOMETHING.
Dude -- I have never even heard of tentative declarations, this might be getting closer to finally nailing this down:
en.cppreference.com/.../extern
I'll have to read through this. Sheesh, they need to make an order of operations diagram for this kind of thing with the compiler. Seriously.
Thumbs up!
I'll have to read through this. Sheesh, they need to make an order of operations diagram for this kind of thing with the compiler. Seriously. It's crap like this you get when people are more interested in showing how smart they think they are that in writing maintainable code.
@Eric
This is entirely my point! The way CODE as a specifier/qualifier is treated is probably/maybe not consistent with the Bible of C. Who cares... not me.
So when I call the syntax for CODE bizarre, maybe you shouldn't be so dismissive cause that C Language has got a whole-lotta side-loops and exceptions all over the place. Lot of hands have touched it over the years.
Honestly, as someone without a stake in the Bible of C -- I have been using tentative declarations (I didn't even know what they were called!) and they've been working. But that CODE qualifier doesn't work like that. Fine... that's why I asked.
In my mind, why would you want to double type declarations between headers and source code? Now if you change a qualifier, you have to update it in two places. Plus the extra time double typing everything?
I really don't care if you consider that wise or stupid either. No need for a debate. It's like a debate over how many spaces are in indent -- who cares...?
ALSO -- there is a very clearly typed implementation for the next guy to figure out from the post. Karma on me, to pay something back to the forum.
End goal: the MCU is moving bits, and the code is modular and reusable and compiles on whatever target I need.
Guess what -- we don't write everything in my business in C either, it's just one of many computer languages we use! All of them have warts, wrinkles, and oddities.
You mean a tentative definition.
A tentative definition is a declaration that may or may not act as a definition.
YOU'VE NOW FINALLY READ ABOUT THEM MR NEIL? SEE EXTERN IS ***NOT*** NEEDED. WELL DONE.
You are correct, I mistyped all that. Tenative definitions -- that are in my header declarations (there is a mouthful).
What a language C is. I have a brother who was a decent web programmer, and now is a very good securities lawyer. Frigging exact same thing, very technical language with exacting logic. Except securities contracts are written in English vs. C.
I miss the good old days of PHP & Python -- now that is an easy language compared to C.
I appreciate the help. Seriously.
I TREAT C AS A TOOL. I THINK I KNOW ENOUGH TO GET THE JOB DONE BUT SURE OF COURSE SOME PEOPLE WILL ARGUE I DON'T KNOW ENOUGH.
IT IS GOOD TO KEEP GOOD MANUALS TO HAND TO CHECK THINGS RARELY USED OR EASILY FORGOTTEN.
ALWAYS GOOD TO LEARN FROM OTHERS AND ACKNOWLEDGE ***GOOD*** ADVICE.
C IS NO MORE DIFFICULT THAN MANY OTHER LANGUAGES. JUST LIKE OTHERS, PRACTICE IS IMPORTANT.