Hi Everyone !
Let me tell you more about my project, this is an circuit system that receives data from temperature sensor show it to 4digit 7-segment display, respond by buzzer . For heating up-down 6 push button key is used. Looking at the algorithm, I have use GPIO interrupt, SPI, timer etc choosing from cubemx. At it has several states, so we use state-machine,utilities and user driver those are very useful during operation. All system is helping on HAL driver, CMSIS, global c and h files and this comdef.h
I am using ARMCC and target option and including paths, all followed from example cubemx project, from install pack I have updated all.
I am getting following errors.
\states\main_state.h(22): error: #5: cannot open source input file "comdef.h": No such file or directory
Usually it comes with Visual C++, I am not sure why my project is not supporting this file in KEIL.
This code was build in Coo-cox environment, I have modified some of its part after changing its main MCU pin-out in cubemx.
2. What I have modified is, its tim.h. spi.h, gpio.h, files combine in one main.c file. Remove I2C h file. some time I did #include #define.
3. Make changes in mxconstant.h file, as we changes GPIO in cubemx,
4. I think, HAL files some how conflicts in for minor changes.
5. Somehow, state files cannot recognized by HAL drivers. Take a look here, http://www.keil.com/support/docs/1868.htm 6. Problem to include header reference, http://www.keil.com/forum/3775/
Kindly, tell me more possible reason thus I can work for that.
So have you revisited the system where the source code was originally written, and on that system located the specific file?
Have you verified the copyright information and any licensing it is covered under? That should tell you if you can just copy the file from that system.
Dear Sir,
<So have you revisited the system where the source code was originally written, and on that system located the specific file?>
My HAL driver,include, source files are completely untouched! Its same as it was before for sure. If you would use cubemx, you will able to understand there is some space fallen to write user code! With dependencies and other user code like state files, system compiles you know very well. As I mentioned earlier, keil makes HAL library automatically !
What I did is just make changes to my main.c! Its a different application in a custom board not a evaluation board from ST!
<Have you verified the copyright information and any licensing it is covered under?>
I dont understand why you are arising copyright ! My question was related to KEIL setting with HAL, and might be f goes to C/C++ related.
But that other system does have a file that your current system do not have.
The possible solutions then are: - copy the file (if allowed) - find a replacement for the file - rewrite the code to not need the file
So the open question is still: have you verified who wrote that file? Where did it originate from?
mdk-keil does not support comdef.h for compliler.
This is the last finding.
mdk-keil does not support comdef.h for compiler.
That makes no sense at all!
To prove the point, I just created a file called comdef.h and included it in a project. Not too surprisingly it worked correctly.
So, would you like to rephrase your statement and indicate what part of the content of your file comdef.h is causing a problem?
He has just arbitrarily expected that Keil should be shipped with a file with this name - and with the specific contents needed for the code he has copied from somewhere to correctly build.
In the end, Keil comes with the header files needed for the libraries shipped with the Keil compiler.
If any other library or code is used, then it's the end-users responsibility to make sure that the compiler gets access to any other header files that the library or project might need.
Since the Keil compiler isn't a compiler designed to produce Windows binaries, it should be expected that it isn't shipped with header files intended specifically for the Windows platform.
"In the end, Keil comes with the header files needed for the libraries shipped with the Keil compiler."
Could you kindly explain in detail?
"Since the Keil compiler isn't a compiler designed to produce Windows binaries, it should be expected that it isn't shipped with header files intended specifically for the Windows platform."
Do you mean there is some limitations using in Windows?
I mean a compiler designed for producing programs that should run on a Windows machine comes with libraries and header files suitable for the Windows platform.
A compiler designed for producing programs that should run on the Linux OS comes with libraries and header files suitable for the Linux platform.
The Keil MDK-ARM or C51 tools are intended to produce binaries for microcontrollers in embedded targets. So they come with libraries and header files intended for that purpose.
The job of moving program code for use on a new OS or on a new processor/processor architecture is called porting. And it's the job of the developer to understand the two environments and know how to rewrite the code to adapt the code requirements to the new target or how to write an "emulation layer" to reduce the differences between the two targets.
If you copy code written for M$ Developer Studio and part of a Windows program to Keil then you must spend the time to adapt the code for the new requirements. If you don't know how, then you either needs to learn how to, or conclude that you started with the wrong task.
In the end, it's normally the developer that is the limiting factor. Often by being colored by incorrect assumptions.
CooCox suggest to use ARM GCC. ARM GCC may be related to: github.com/.../comdef.h
/** * This file has no copyright assigned and is placed in the Public Domain. * This file is part of the mingw-w64 runtime package. * No warranty is given; refer to the file DISCLAIMER.PD within this package. */ #ifndef _INC_COMDEF #define _INC_COMDEF #include <_mingw.h> #ifndef RC_INVOKED #ifndef __cplusplus #error Native Compiler support only available in C++ compiler #endif #include <ole2.h> #include <olectl.h> #include <comutil.h> #ifndef WINAPI #if defined(_ARM_) #define WINAPI #else #define WINAPI __stdcall #endif #endif
no copyright assigned sounds like risky.
"This file has no copyright assigned and is placed in the Public Domain."
Public Domain is nice - no ownership claims and no restrictions. Way more free than something with a virulent GPL license on it.
Lots of code was put in the public domain before the world got hundreds of different open source licenses. Licenses doesn't just grant rights. They may also limit rights.
Just a footnote - the MinGW compiler is intended to create Windows binaries. So the comdef.h file is intended for programs using the COM model for interfacing.
Unless the OP did copy code from a Windows program, the missing comdef.h is most probably a file with a completely different purpose. Possibly a file describing UART functionality for some microcontroller or some microcontroller library. Something the OP should verify by looking at the comdef.h file available in the original build environment - and has been recommended to do since this thread was originally created.
I would have thought Public Domain means "Everyone uses it, but no one knows where and when it comes from". Now I think Public Domain means "The author intentionally puts it into Public Domain".
Public Domain is better than Apache, BSD or license?
Public Domain is better than Apache, BSD or MIT license? (missed)
Public Domain is good. The biggest problem is that many PD files have no original information showing that the person who put the code into the Public Domain had the rights to do so.
One problem with that, is that evil companies can pick up the code and glue on their own license and try to make it their own - and later try to blackmail other users. Then it's the other uses who needs to prove that the source code was available in the PD (and rightfully so) long before the claims of the company. And if the only original text is "This code is put into the public domain", then that task can be very hard.
Apache, BSD or MIT are very good. And with a maintained copyright and license file, you get traceability on the origins, making it harder for other people/companies to try to appropriate the ownership of the code.