| Details |
Message |
|
Read-Only
Author Juan Mustelier
Posted 5-Jan-2012 16:18 GMT
Toolset ARM
|
 Unable To Locate & Open "CAN_Cfg.h"
Juan Mustelier
I am new at Keil & I just inherited a project which was left
behind & unfinished – meaning there is missing or
unimplemented functionality. In an effort to get the code to compile
I started getting rid of the warnings, which were for the most part
empty function stubs w/o a proper declaration, unused functions &
variables - don't worry I tagged these w/ comments so that I can go
back to them later. Now I have the following error #5. I get a
lot of these. My device is an LPC2468… (MCB2300)
there is a "RTX_CAN.h" file in my
"C:\Keil\ARM\RV31\INC"
there is a "CAN_Cfg.h" file in my
"C:\Keil\ARM\Boards\Keil\MCB2300\RL\CAN\CAN_Ex1"
there is a "CAN_Cfg.h" file in my "C:\ProdDev\VDR_4X"
Running uVision V4.22.22.0
--------- RTX_Can.h ---------
#include <RTL.h> /* RTX kernel functions & defines
*/
#include "CAN_Cfg.h" /* CAN Configuration */
even if I change this, it can't find the file,...
#include <CAN_Cfg.h> /* CAN Configuration */
--------- Build Output ---------
assembling SWI_Table.s...
creating preprocessor file for vdr_can.c...
C:\Keil\ARM\RV31\INC\RTX_Can.h(13): error: #5: cannot open
source input file "CAN_Cfg.h": No such file or directory
compiling vdr_can.c...
C:\Keil\ARM\RV31\INC\RTX_Can.h(13): error: #5: cannot open
source input file "CAN_Cfg.h": No such file or directory
creating preprocessor file for RTX_CAN.c...
--------- ---------
|
|
|
Read-Only
Author Hans-Bernhard Broeker
Posted 5-Jan-2012 19:45 GMT
Toolset ARM
|
 RE: Unable To Locate & Open "CAN_Cfg.h"
Hans-Bernhard Broeker
So did you do anything to inform the compiler where you stuck that
header file? You didn't expect it to magically know where every
single file on your computer is, did you?
|
|
|
Read-Only
Author Juan Mustelier
Posted 5-Jan-2012 20:22 GMT
Toolset ARM
|
 RE: Unable To Locate & Open "CAN_Cfg.h"
Juan Mustelier
Well, this (inherited) project did magically seem to have
contained enough information for uVision4 to know where most of the
other include files were, except of course, the one in question. So
that is a bit puzzling. But, I can certainly be more specific...
Thank you.
|
|
|
Read-Only
Author Juan Mustelier
Posted 5-Jan-2012 20:39 GMT
Toolset ARM
|
 RE: Unable To Locate & Open "CAN_Cfg.h"
Juan Mustelier
So, the solution was,...
Project -> Clean Target -> Project -> Options For Target
(Alt-F7) -> C/C++
Include Paths: path1;path2;path3 [Ok]
ReBuild All Target Files
Where the paths (1,2,& 3) were the ones I had specified in my
original post.
|
|
|
Read-Only
Author Hans-Bernhard Broeker
Posted 5-Jan-2012 23:01 GMT
Toolset ARM
|
 RE: Unable To Locate & Open "CAN_Cfg.h"
Hans-Bernhard Broeker
here the paths (1,2,& 3) were the ones I had specified in
my original post.
That was quite probably not the right way to do it. Path 2 from
your OP is a sample project for a specific Keil demo board. Unless
you're actually using exactly that demo board, you shouldn't be
referring to headers meant for that particular hardware.
|
|
|
Read-Only
Author Juan Mustelier
Posted 6-Jan-2012 13:15 GMT
Toolset ARM
|
 RE: Unable To Locate & Open "CAN_Cfg.h"
Juan Mustelier
(I agree &) Yes, I removed the middle “path2”
(device specific) & it compiled just fine. I could have sworn
that didn’t work before (when running on uVision4 v4.13),
that’s why it was so frustrating getting this resolved, which
prompted me to post on the forum (in the 1st place - thinking there
was some other issue). And so, that's why I used the "shot gun"
approach & used all 3, that time around. I just recently upgraded
to v4.22. But regardless, it is good to see that things work as they
should.
|
|
|
Read-Only
Author Hans-Bernhard Broeker
Posted 5-Jan-2012 23:11 GMT
Toolset ARM
|
 RE: Unable To Locate & Open "CAN_Cfg.h"
Hans-Bernhard Broeker
magically seem to have contained enough information
Rest assured that magic has nothing to do with it. Information
like that is put into the project definition by manual labour, not
divine intervention. And manual labour is prone to errors, some of
which the original author may not even have noticed.
E.g. sometimes that information consists of references to files,
which are relative paths based on where the project itself is stored
("..\..\main\includes"). Sometimes they're absolute path names
instead ("c:\ottos_projects\project5\main\includes"). In both cases
the references can become broken by moving the project around on the
harddrive, if they're not done properly. As a rule of thumb paths to
files outside the project's own directory tree should be absolute (or
based on an environment setting), while paths to those inside should
be relative.
|
|