My team and I are working on a project programming about 40 different units that all use the same serial communication protocol. I'm currently using uVision3, but we have purchased uVision4, and it should be installed soon. I have written a header (.h) file to list function headers, global variables and constants, and #define statements. The header file then includes an implementation (.c) file for the function implementations.
The files are located in a general "include" folder on the network so that we can all access them. In each project file (one for each unit) we list the network folder in the C51 include directories, and everything compiles, links, and runs wonderfully.
The problem I'm having is that it appears that breakpoints in the implementation file don't work. What I found interesting is that if I place a breakpoint on the corresponding line in the main source file, the program will break in the implementation file at that line. Similarly, if I break execution and step into functions that are in the implementation file, the trace indicator (yellow arrow) will go to the correct line, but stay in the main source file rather than moving to the implementation file.
Is there a way to get uVision to trace into the implementation file?
Example:
Main.c
#include <header.h> void main(void) { ... foo(); ... }
header.h
#ifndef _HEADER_H #define _HEADER_H void foo(void); #include "header.c" #endif
header.c
#ifndef _HEADER_C #define _HEADER_C void foo(void) { ... } #endif
Thanks.
The header file then includes an implementation (.c) file for the function implementations.
Don't do that! *.c files are supposed to #include headers, not the other way round.
The problems you're having with attributing code to source files are just the top of the iceberg of problems you bought yourself with that crazy program structure.
Just don't (mis)treat them as headers.
I'm looking for a solution, not a pointer to a problem. I think I'm borrowing this concept from C++. It gets a little blurry for me sometimes.
How would you suggest I set up the project so that we can all access the same source file and reuse code?
.. by running a .bat file that copies all source into a 'build' subdirectory and compiles/links from there. The IDE, which 'believe' you are having a nice, somple, 'project' in one place, fall short when you do multiple builds with different mixes of files.
Erik
Will that also solve being able to trace through that reusable code?
Add the helper code as a normal c file to the project. Nothing different from Keil sample projects constisting of multiple c files.
You may place it in a directory /lib and let the directory /lib be checked out from one source code repository while your normal source directory is the project-specific directory.
But whatever you do, don't include c files from header files. And don't place function implementations in header files. C is not C++. In C++, you can create inline functions in a header file. And implement tiny methods directly in the header file - normally code that can/should inline at the place where it is used.
But whatever you do - never pretend that a *.c file is an include file. It just isn't.
Okay. I think I have my project restructured properly. It is quite different than C++. Coming from a software dev environment, I've had to make some adjustments. Thanks.
It is quite different than C++.
Not on this count it isn't. Not even C++ header files #include their source files.
View all questions in Keil forum