What’s in the ifi_startup.c, ifi_picdefs.h, ifi_default.h?
You don’t need to understand the contents of every file in the project in order to program your Robot Controller. Just concentrate on main.c and user_routines.c to get started.
Can I remove the ifi_utilities.c and printf_lib.c files?
**Yes. They are only there in case you need them. If you are not using any of the functions from these files, you can safely remove them from your project, as long as you also remove any references to them in your other files. You must also remove their corresponding .h files.
Removing printf_lib.c from your project will significantly reduce the size of your program (by about 4k bytes).**
There are too many files in my Code’s MPLAB® project! Can I combine some of them?
**Sure, you could do that, but you would be negating some of the benefits that programming in C gives you. To quote Paladino of Team 147 from his chiefdelphi.com forum posting:
I think it is very important for us to understand how powerful the ability to program the RC in C is. The C language provides us with a way to break the code down into small bite sized chunks that can be easily distributed among many developers as well as make understanding the code much easier.
Header files (.h) should be considered like contracts or interface agreements with other programmers. I can break my code down into small segments and have Bob go off and develop the main loop while Jill creates a library of functions for accessing sensors. Jill and Bob will get together and decide on the outline of functions that will be made available and Jill will create a header file containing the agreed upon declarations of these functions. Bob can take this header file and go off and use the function prototypes to work out the logic of his main loop. Bob can even test compile his code all without ever having the actual implementation of the sensor library. Meanwhile Jill can create the implementation of the sensor library functions in her C file (.c). To make things even better Jill might provide Bob with an implementation of the sensor library with all of the functions stubbed out to only print a debug message or just return without doing anything so that Bob can compile and run this main loop to test logic etc. Then as Jill finishes the implementation details of the sensor library she can provide Bob with beta versions of the sensor library to test.
Splitting the code up can also make it much easier to debug a problem. If you logically break the code down into functional areas then you know exactly where to look in the code to find the problem as opposed to looking through one big file full of code.
I hope you can begin to see how much better this splitting up of the code into small chunks can make design/development/debug go.
I can also see a situation where someone might develop a library much like the ifi provided ifi_library.lib to provide (stick with me here) communications between 2 robots during autonomous mode via a sensor. That someone might not want to give away the source code but could provide the library and a header file to alliance partners to include in their code. Someone might also write a complete generic autonomous mode library and provide it to anyone who might want it. Makes for all kinds of interesting possibilities!**
Compilation error “name exceeds file format maximum of 62.
The Microchip compiler has a 64 character limit for path/file names. Try to shorten your folder and file names, or move the files closer to the root directory.