This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unable To Locate & Open "CAN_Cfg.h"

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...

--------- ---------

Parents
  • 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.

Reply
  • 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.

Children
No data