I have the following error on my simulated program.
Error C267 Funcdef Requires ANSI-Style Prototype Summary *** Error C267 Funcdef Requires ANSI-Style Prototype
Description A function was invoked with parameters but the declaration specifies an empty parameter list. The prototype should be completed with the parameter types in order to give the compiler the opportunity to pass parameters in registers and have the calling me
Copyright (c) Keil - An ARM Company. All rights reserved.
That was the error description, can anybody tell me how to correct it?
This is the code: #include "Main.h" #include "Simple_EOS.H"
#include "PC_IO_T1.h"
/* ...........................................................................................................................*/ /* ........................................................................................................................... */
void main(void) { // Set baud rate to 9600: generic 8051 version PC_LINK_IO_Init_T1(9600);
// Set up sEOS (5ms tick) sEOS_Init_Timer2(5);
while(1) // Super Loop { sEOS_Go_To_Sleep(); //Enter idle mode to save power } }
This is an example of the Addison_Wesley_Embedded_C.pdf
#include "Simple_EOS.H"
what is in that one?
oops
Can you have live code after // I do not think so
This BLASTED tendency to write the whole program in one line makes me barf
what on earth is worng with
while(1) // Super Loop \ { sEOS_Go_To_Sleep(); //Enter idle mode to save power }
Erik
Hi Erik, thanks for helping,
Is this what you were asking for? This is from another exaple
SIMPLE_EOS.H (v1.00)
-see simple_EOS.C for datails
void sEOS_Init_Timer2(const tByte TICK_MS); void sEOS_Go_To_Sleep(void);
/* END OF FILE */
Do you an e-mail were i can send you the manual that i'm using? in that manual you can find the data adquisition example that i'm trying to run.
these are the warnigs and errors of the code
dac.c(11): warning C318: can't open file 'Main.h' dac.c(12): warning C318: can't open file 'Simple_EOS.H' dac.c(14): warning C318: can't open file 'PC_IO_T1.h' DAC.C(22): warning C206: 'PC_LINK_IO_Init_T1': missing function-prototype DAC.C(22): error C267: 'PC_LINK_IO_Init_T1': requires ANSI-style prototype
any comments?
the path to the solution is the path :)
meaning?
that the path to the files it can't find is not in your build or conversely the files are not in the paths defined in your build.
How do you expect a module to get information from an include file it can not find ?????
And how do i find these files?
They should be in the same folder as the C file.
Did it not occur to you that the three C318 warnings about un-openable headers, and the C206 warning about a missing function prototype might be related to the final C267 error?!
You should always begin with the first error/warning - fix that, and it will fix all the consequential problems! :-)
Joel Rodríguez asked, "And how do i find these files?"
The location of the files should be stated in the "Manual" that you said you're working from...
Neil Kurzman said, "They should be in the same folder as the C file"
Not necessarily.
There is no general requirement for header files to be in any specific location.
It is not uncommon for people to put all headers in a folder (structure) separate from the .c files...
The #include directive can include a relative or absolute path; The compiler Manual tells you the search rules it uses for locating headers where no path is specified.
http://www.keil.com/support/man/docs/c51/c51_pp_header_files.htm http://www.keil.com/support/man/docs/c51/c51_pp_include.htm
Very true. The original question was meaningless without the information that the header files were not found...
However, in this case I think someone responsible for the compiler should take a look at these messages. A failure to open a header file shouldn't be classified as a warning. It is definitely an error!
That some, out of ignorance, see the error and do not worry about the warnings (showing the cause of the error), is not the fault of the compiler/linker.
A failure to open a header file shouldn't be classified as a warning. It is definitely an error! I, have a quite complex build scheme (I buld 47 different things, with various commonality, from a somewhat complex file structure (if a=1 include file group a1 combined with (if b=2 gropup lnclude file group b2 combined with (...))). In such a construct, there often will, initially, due to 'cross pollination' be an include of something that is not used and may not be found. If I had to take care of such being an error during initial development of a new subset it would be a pain, the warnings are, of course, removed before release.
Since the compiler has no means of determining if a given missing header contains needed information (how could it, it can't find it) the only thing a compiler can do is tell it is missing. Thus I agree with it being a warning.
This, of course, bring this discussion a full cycle to my original statement "do not ignore warnings".
My opinion of errors/vs warnings: both should indicate a problem, if the compiler/linker can live with it it should be a warning, if the compiler/linker can not, it must be an error and I do believe that is the 'rule' for Keil tools.
"Since the compiler has no means of determining if a given missing header contains needed information (how could it, it can't find it) the only thing a compiler can do is tell it is missing. Thus I agree with it being a warning."
I thoroughly agree.