hello, Error: L6200E: Symbol os_thread_def_blink_LED multiply defined (by led.o and main.o)..i have declared the variable led.h header file. and included the same header file in all the sub files
This is standard 'C' textbook stuff - nothing specific to Keil or ARM.
c-faq.com/.../decldef.html
Here are some more 'C' learning & reference resources: blog.antronics.co.uk/.../
"How to declare it as extern?"
lmgtfy.com/
i have tried with extern keyword. error was there as it was. but simply removing a #include c file all errors are resolved... anyway thank you all for your suggestions...
"i have tried with extern keyword. error was there as it was. but simply removing a #include c file all errors are resolved... anyway thank you all for your suggestions..."
You don't give us much information. All we know is that you tried something incorrectly. And we can't tell you want you did wrong since you never tried to explain exactly how you tried to change the code.
Have you tried a rather "advanced" experiment? Have you opened any of the compiler-supplied header files and checked how they use the "extern" keyword?
The ground rule is to have "extern" before variable declarations in header files.
And then select one (1) source file where you actually define the variable.
Note that declaring a variable (using "extern") is just telling the compiler "there exists a variable of this name and type".
While defining a variable is telling the compiler "create this variable here", in which case the compiler will supply special "instructions" to the linker.
And the linker will be unhappy if it processes multiple object files that all contains the information "create this variable here".
In the end, you can't really get anywhere without learning how to use the extern keyword. It's a very important keyword since larger programs just needs to be splitted into multiple source files or they will be impossible to maintain. So "getting around" isn't a good path. That's like getting around fixing the car by walking - the car will still be broken the next time.
You mean you had something like this
#include "something.c"
That is almost certainly a mistake!
It is rare that one would ever #include a .c file.
It's not rare. There is also nothing illegal or inherently wrong with doing it.
Just because you haven't come across it much (or at all) does not provide a true indication of its frequency of use.
You are likely not aware that a .c extension is not an explicit requirement for a source file. It's more a convention.
Almost everything we do when programming is based on conventions. Conventions expected to reduce maintainance costs, reduce the number of errors and make it easier for someone else to take over the code.
While the compiler doesn't really care about file extensions they are intended to inform someone that takes over the code about the structure of the project.
There are times when it may be an advantage to do unconventional things. But there is often a cost to it.
"It's not rare" I maintain that it is unusual.
"There is also nothing illegal or inherently wrong with doing it" Agreed (my emphasis).
"Just because you haven't come across it much (or at all)" Yes, I have come across it. In particular, there are some simplistic toolchains that don't have a (proper) linker so rely upon #including everything.
"does not provide a true indication of its frequency of use" Maybe.
"You are likely not aware that a .c extension is not an explicit requirement for a source file" I am thoroughly aware of that - also that .h is also just a convention. And, of course, the content of a so-called "header" file is just as much 'C' source text as any other.
"It's more a convention" Indeed - it is entirely convention.
But I maintain that in this case it is most likely a mistake.
Even older RTX revisions used this construct (including a .c file), but that certainly does not make it a proper technique...
Indeed not a language requirement - but some compilers do look at the extension; eg, to choose between C and C++
And some (many? most?) IDEs, and some other tools, do specifically recognise .c and .h extensions
I remember a project once where the authors had tried to be "clever" by distinguishing "private" headers with .h and "public" headers with, IIRC, .e. Of course this was all perfectly legal and valid as far as the 'C' Programming Language is concerned, and seemed like quite a neat idea on the face of it - but caused a number of headaches with all the other tools...
Indeed - it is entirely convention
Ha. And if I'd have said entirely, you'd no doubt have ssid more.
Seems like I replied to one of those people who triggers the (facepalm).