We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
When I put #include <ctype.h> at the top of my source file, the compiler finds it. If I add #include <reg688.h>, I get error "can't open file 'reg688.h'". If change it to read #include <philips\reg688.h>, it still can't find the file. And if I put the full path in ( <c:\keil\c51\inc\philips\reg688.h> ) it STILL CAN'T FIND the file. What is this stupid compiler looking for?
Have you written your own header files in your project that includes reg668.h? I once had a similar problem because i made a mistake of including the std headers in my own header file.
You can also try putting #ifndef/#define/#endif statement in the reg668.h
No, I didn't write my own reg668.h file. I'm using the one supplied by Keil. What I did to get this to compile was to put the #include <reg668.h> in the main C file, then copy and paste those particular defines in reg668.h that my asm file is looking for into the asm file. Notice that I did a copy and paste. Meaning that those defines are now declared twice in the project, yet no compiler error. There is some interaction between the C file and the asm file that I'm not understanding. I should not have to do this, but so far it's only way I can get it to compile.
Note that the assembler code (the startup file) will not know anything about any declarations you use in the C code. And one C file will not know anything about any declarations you have in another C file or in the assembler startup file.
careful Per, before you know it you will be declared as a "genius" as well...
Ah, but if a genius is defined as slightly better than a stupid compiler, that may not take - or mean - much :)
Ya know, every time I "rebuild" the target I get a different result. Last night, I was able to compile and link without errors. Today, without knowingly changing anything, I can still compile all files without error, but now I get 83+ linker errors. So I switched from the BL51 linker to the LX51 linker. I then did a rebuild and got some UNDFINED SYSMBOL assembler errors in my asm file. This is not the STARTUP.A51 file. So I copied another declaration from reg668.h to the asm file, recompiled sucessfully, and I still have 83 linker errors, "REFERENCE MADE TO UNRESOLVED EXTERNAL SYMBOL."
FYI...this is not a new program. A consultant wrote this program for us a few years ago. I have been asked to modify the program for a new project. So I copied all the source files to a new directory and am trying to create a new uV3 project. I want to be able to recreate the original uV3 project and get it to rebuild the same executable before I start making any changes. It appears I'm not setting up the project in uV3 correctly. I'm not familiar with Keil products and the manual seems pretty useless. Any suggestions?
So I copied all the source files to a new directory and am trying to create a new uV3 project.
That is IMHO exactly the wrong way to achieve this goal:
rebuild the same executable
If you want an exact replica of the original executable, you should start out with an exact replica of the original project. Source files, project file, directory layout, compiler version --- everything. Don't start a new project, but instead use the existing one. Don't modify anything until you've managed to reproduce the original result.
Any suggestions?
You might be better off getting that consultant back.
I can recompile the original project and get the same executable file. But I don't want to change the original project or source files. So, I need to copy the source code to a new directory, create a new project file, and before I start modifying the code make sure I can build the original executable. This is not that difficult (or at least it shouldn't be), nor is it "the wrong way" to achieve my goal. We're talking about 8 source code files here. It's not like I'm trying to recreate building Windows.
And by the way, I did manage to recreate the original executable with my new project file. There was a code segment that the consultant created that had to be added manually to the project file that I was missing.
Don't worry about changing the project when you do the your job of extending the project.
You are expected to use source-code management, i.e. the changes you do will not destroy the original project. Instead, the source code manager will be able to restore either your version or the original version. And it will be able to show every difference between your new version and the original that the consultant left you with.
If you do not use source-code versioning, then it is time to stop all work and first think about how to work with source code. Any project that matters will require traceability, and that will require source-code management (and of course similar management of the requirements, test cases, bug tracker, ...)
But I don't want to change the original project or source files.
Then why are you doing it?
So, I need to copy the source code to a new directory, create a new project file,
Now, whatever gave you that strange idea? What does copying the project folder around have to do with creating a new project?
There was a code segment that the consultant created that had to be added manually to the project file that I was missing.
Aha. So the error was exactly where I told you to look, and that leads you to the conclusion that
nor is it "the wrong way" to achieve my goal
If the thought of ever buying a product based on such reasoning weren't so scary, that might even be funny.