Part Number: MOTORWARE
Tool/software: Code Composer Studio
My department is in the process of attempting to move over to the InstaSpin platform from other manufacturers and are having trouble deciding how we would like to structure our "core" project so that it closely mirrors MotorWare but is relatively 'self-contained'.
On other platforms, we have had our own libraries for drivers, modules, and other software that have been 100% internally controlled. We can save source code and library files into a Git repository and easily revision, diff, check-in and check-out branches. This makes source control very simple and the method translates to multiple projects with the same code base.
Up to this point, it looks like we are going to have two types of projects:
- 'characterization' project which will be used to identify and characterize motors, based on lab02b
- 'project template', with each project having its own 'custom' files for using different A/Ds, adding custom software, etc.
Using lab02b for characterization is really no big deal. It is sort of made for that anyway and any customization made within the defined lab02b workflow will work. Each project will have its own 'main.c', 'user.h', 'hal.c', and 'hal.h' along with a couple of other files. This project load will likely be based on lab03, but cannot be created using the lab-defined workflow without breaking source control methods.
After all that, my question: What is the TI recommended method for using MotorWare-derived projects while also taking advantage of source control methodologies and allowing each project to stand on its own by having all that it needs within the same file set? I have looked around quite a bit on the forums and I have found that most questions are InstaSpin-related rather than source-control related and simply haven't been able to find any guidance in this area.