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.
Coming from a software dev environment, I've had to make some adjustments. 1) as far as I know Keil is software development tools. 2) for C51 you better forget function pointers, malloc and a few more things
1) as far as I know Keil is software development tools.
Yes, I understand that. I meant PC-based (Windows/OSX) software. I'm having to backtrack to stuff I learned over 10 years ago.
2) for C51 you better forget function pointers, malloc and a few more things
I'm actually using both of those. They seem to work just fine.
I meant PC-based (Windows/OSX) software. so you are used to 'unlimited' resources
2) for C51 you better forget function pointers, malloc and a few more things I'm actually using both of those. They seem to work just fine. sure, but soon you will request that the processor be replaced by a faster one which, of course, is not a problem if what you are working on is not going to be produced in any quantity. Same goes for the large model which is the lazy mans way out. 'lazy' again is OK if the production qty is where engineering cost is more significant than unit cost.
Be careful with the word "lazy" Erik, it already got you into serious trouble here at least once :-) :-)