What is a good methodology for object oriented peripheral code in C?

Keep It Simple is the best of methodologies for embedded C.

Another is to make it Somebody Else's Problem (hire a contractor, let him sweat instead of you).

-- pa

OOD sounds like a bit of overkill for a motor controller.

OOD is needed only if You have multiple motor instances in one project. In C it can be implemented by defining a structure for object and passing a pointer to it in API functions. If it's only one motor instance in a project, then make one .h file with API definition (set of functions) and multiple .c files for different API implementations. To switch between .c files with a #define, put #ifdef/#endif pair on top/bottom of .c files so that unneeded files are effectively empty.

Unclear what you want to do and where OO makes things more modular.

More details are needed.

Are the higher level source code the same and plumbing below either to GPIO or SPI?

OOP in C is doable, but for small projects, not likely worth the complexity. However, you can gain many of the advantages of OOP through well structured code, using opaque data types, and using C’s built-in techniques for separating private/public interfaces. Don’t worry about inheritance, use composition instead. Those steps alone keep C plain and simple for none-OOP readers, but give OOP-experienced folks a lot of the “structure�? they like to see.

As for polymorphism, there are fancy ways, but in your case, I’m inclined to think #ifdef is suitable. I use it a lot for the same purpose you’re looking at (building with various optional hardware drivers).

I have a master mProject.h file which declares project level constants. That file #includes mLocal.h which is specifically for the purpose of triggering versions of builds.

(I prefix our code with a “namespace�? of “m�? so I can easily identify “ours�? vs. “theirs.�?)

Two techniques come to mind:

In mProject.h, before mLocal.h is included, you have

// Define a build options to choose from, and a build variable 
 
#define mMOTOR_CTLR_GPIO (1U)
#define mMOTOR_CTLR_SPI (2U)
 
#define mBUILD_WITH_MTR_CTLR_TYPE mMOTOR_CTLR_GPIO // this is the default build

In mLocal.h you have

// Affirm or override the mProject build variable in your own personalized mLocal file
 
#undef mBUILD_WITH_MTR_CTLR_TYPE
#define mBUILD_WITH_MTR_CTLR_TYPE mMOTOR_CTLR_SPI // this overrides mProject.h

Next, in your application code files, where you might have

#include “mCtlr_motorGpio.h�?

You would now have

// The file to include is determined based on your build option variable
#if (mBUILD_WITH_MTR_CTLR_TYPE == mMOTOR_CTLR_SPI)
#include “mCtlr_motorSpi.h�?
#else
#include “mCtlr_motorGpio.h�?
#endif

Obviously you could skip mLocal.h and use just mProject.h. However, the advantages of mLocal.h are 

• mProject.h is always defined as the baseline default and doesn’t get butchered by whoever needed a special version and didn’t undo the changes. (mLocal.h needs to exist, but it doesn’t need any content.)
• mLocal.h is NOT checked into source code control so that each developer can have their own version to manage local builds during development.

If your source code is intuitive, easy to understand and reuse by someone else, easy to extract sub functionality and plumb it to another project, then it would be good.

For example, which variable needs an app note?

int32 Temp;

or

int32 STTS751_TempDegC_x100;

?