MotorWare and controlSuite Coding Style Difference

Louis,

You should probably read the Architecture and Coding documents here

C:\ti\motorware\motorware_1_01_00_11\docs

 

We choose to move to this object oriented API style of software for many reasons

• more accepted style for software engineers
• more portable
• easier to re-use across architectures and device variants
• easier to maintain and service across multiple software engineers
• MACRO syle of controlSUITE would have been impossible for the secure ROM technique
• MACRO styel of controlSUITE would not allow multiple instantiations of objects from a single source code set (e.g. we can use the same ROM code footprint and call multiple instances of any of the functions)
• When done correctly uses fewer cycles and less memory

We know it's a big change if you are well versed in controlSUITE style C2000 code of the past.  That's why we have made this change only for our new solutions like InstaSPIN-FOC and InstaSPIN-MOTION supported through MotorWare.  We have also started to introduce this style through the LaunchPad ecosystems where we offer the same object oriented of drivers and example projects.

 

Dear Chris,
I am using control suite and motorware both. I have well proven code of control suit for FOC (IM motor), other peripheral and also some interface parameter for FOC. Now can i merge only FAST block(it gives me accurate F,A,S,T parameter) of Motroware in my control suite style coding? I just pass require parameter to FAST block and it gives me F,A,S,T, parameter which i will use in my control suit code.
it will save my development time. Is it possible?
Thanks.

you can certainly mix the two styles of code. in fact, that's the direction we are going to improve the peripheral communication software for InstaSPIN...show how to use all the examples already in controlSUITE.

In MotorWare 15 we released proj_lab11 which removes the CTRL abstraction from the InstaSPIN projects and inlines all control code. I would start from this (assuming you don't need motor ID in your project) and add in the controlSUITE code for everything else.

Chris,

Can you elaborate a little more on "When done correctly uses fewer cycles and less memory"?

Thanks
~Sal

Hi Sal,

Have you seen the following docs (C:\TI\motorware\motorware_1_01_00_15\docs)?

• motorware_coding_standards.pdf
• motorware_software_architecture.pdf

These documents describe the overall architecture and design of MotorWare software.  Things like making inline functions static to eliminate the call/return ASM instructions.  The code was written with the compiler in mind to generate efficient ASM code.  

It is interesting to also reviewing documentation on compiler tips & tricks, do a search on this in the forum and you find things like the compiler wiki:  

Jeff

Sal,
proponents of MACRO code have always argued that abstracted object oriented APIs adding code size and took longer to execute. Their argument is that MACRO code is simpler, smaller footprint, and lowest CPU overhead. We have shown that it is not the case. That's all I meant.