• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 1382 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/MOTORWARE: Using HAL module - doubts regarding the approach of modyfing common files

Jakub Klein
Intellectual 630 points

Part Number: MOTORWARE

Tool/software: Code Composer Studio

Hello,

I am new to TI MCUs and starting to develop a project which will utilize MotorWare modules. TI is encouraging to use their HAL module instead of direct calls to the hardware, so I'd like to comply. From what I understood, this means that any usage of peripheral devices implies changing HAL source files from "C:/ti/Motorware/XX/sw" directory. There are however some issues I find with this approach:

- Will the future update of MotorWare software not overwrite my changes in those files?

- What if I want to create another project that will use the same modules? It will have to utilize the same files, adapted to a different project!

- Say that I want to open the project on another computer. Instead of just copying the project files, I will have to copy the whole "sw" directory as well - what a complication. And what if I can't overwrite already existing files (ex. that are used by someone else)?

A question to more experienced developers - am I right with my concerns and how do you walk around this?

I've been thinking about copying the files that shall be changed to my project's location, but the #include dependencies may make it troublesome. I could possibly copy the whole "sw" directory, but it gives me plenty of files I might not even use. Is there no smarter solution?

  • 0
    TI__Genius 17175 points
    Jakub,

    Anytime you install a new version of Motorware, a new directory is created; therefore, any changes you make to the modules/drivers directories should be left unchanged.

    You could theoretically make a copy of the modules/drivers source files, rename, and include in the CCS project as the new name. Otherwise, yes, all Motorware projects share a common set of modules/drivers.

    The distributed labs for Motorware rely on the directory structure to stay intact for the relatively linked source/header files. You can choose to remove the linkage and place the source files anywhere and link to them, or choose to copy them into the same CCS project directory and distribute that way. If you want to work within the framework we've set, then yes, you will most likely need to copy the /sw/ directory and either version control or redistribute that directory. You are able to choose Copy into Project Workspace from CCS include options though, which will make a local copy in the project directory - we choose not to do this in the distributed version to avoid source bloat, but is a perfectly viable option if you want to have a localized version, or an independent project directory than you can zip and share.

    Sean
  • 0 in reply to Sean Bigley
    Intellectual 630 points

    Thank you for an answer.

    Copying the source files instead of linking them will solve only half of the problem, as there are still header files that might be changed for project purposes - and I'm afraid that moving them will create lots of "unresolved includes" problems as the files structure is quite complex.

    I guess I'll just stay with copying the whole "sw" directory for any new project and keep it in neighboring location. It weighs 170 mB so any "zip-and-send" actions will be hindered, but at least I will be sure that anything I use is kept in one place. Using relative links I should be able to transport the code seamlessly between various computers.

    Unless I would leave HAL layer "as it is" and develop my program on top of it - implement any changes with use of HAL functions but not changing them directly. Do you think the code will be much less efficient with such approach?

  • 0 in reply to Jakub Klein
    TI__Genius 17175 points

    An idea for paring down the /sw/ directory would be to remove any board+device pairings that aren't needed in the /sw/solutions/ sub-directories - just a thought.


    As for your question at the end of your last post - if I'm understanding correctly, it should not be an issue to create code using the existing HAL API. You shouldn't experience unnecessary loss of efficiency by using the API we've provided. Am I addressing your concern correctly?


    Sean