Common feature of all products: "We have no common features" | Cypress Semiconductor
Common feature of all products: "We have no common features"
Just wrapping up a whirlwind trip through Asia (Seoul, Shanghai, Tokyo): airport-hotel-office-hotel-office-airport was the pattern, only broken in Tokyo because the first "office" day was Friday. During this time I was talking to developers about the advantages of a common framework for their PSoC designs, where the tedious, low-value aspects of projects are put into the common framework, and each project's value-added features are plugged into or hung onto the framework. Everyone grasped immediately the value of this approach (time saving, continuous quality improvement) but almost universally agreed on one thing: we need to be able to change everything, including the common framework. Why? Every customer, every marketer wants everything their way.
Is this really true? Before I answer, I'll give you a clue. Using absolute words like "always", "every", and "never" almost always leads to a false statement; all you need is one exception. So I do not believe the demands of customers or marketers precludes developing and using a common framework for PSoC projects. What I do believe is that every developer prefers to do things their own way. They will endorse code reuse when the reused code is their own and resist reuse of another's code. And for good reason if code is not designed for reuse. But a common framework by definition is designed for reuse. Another thing every developer prefers: not spending time to debug his/her own stupid coding mistakes, which is the most important reason to use a common (existing) framework.
Frameworks come in many shapes and sizes: C language is a framework as is the Google Web Toolkit. As you can see, a framework can be extremely general or very special purpose. All frameworks aim to reduce the development time and increase the quality of your code by providing reusable, qualified software components. This is the very nature of PSoC development: User Modules and APIs, boot and configuration code generation. Every PSoC developer is making good use of this framework without knowing it. The next step is to create a more application-specific framework, where you define the "Frozen Spots" that you don't make changes to and the "Hot Spots" where you do (see http://en.wikipedia.org/wiki/Software_framework for a general article on software frameworks).
A framework is not meant to limit features, but to provides the structure upon which you add the features and build up your project. Will a customer know you are using a software framework? Possibly, since you may choose to standardize on some aspects of the interface (for instance a communications register map). But a good framework needs to be designed to allow for exceptions, and therefore even the interface may be changed while the framework is employed. In object-oriented terminology, this is called overloading. We can borrow the term but with the languages and compilers used with PSoC there is no built-in support for overloading. BTW, the best object-oriented project I ever worked on was 20 years ago and used PL/M as the implementation language, which simply proves that being object-oriented is a state-of-mind (see http://en.wikipedia.org/wiki/PL/M if you really want to know a little more about PL/M).
What's the next step? Consider your applications, is there a common structure that could lend itself to a framework? (Note: answer is always yes, but the question is to what degree). I'll discuss how to build-up a framework in a future post.