Twelve-bar blues, embedded style | Cypress Semiconductor
Twelve-bar blues, embedded style
The most popular chord progression in popular music (http://en.wikipedia.org/wiki/Twelve-bar_blues), 12-bar blues defines a pattern that is easy to learn, very flexible in it's application, and, with just a little ear-training, easily recognizable.
The basic form of 12-bar blues uses only 3 chords: I (the tonic), IV (the subdominant) and V (the dominant). In the key of C that means the three chords are C(I), F(IV) and G(V). The 12-bars in their basic progression have the chords in this order (each bar has 4 beats):
C | C | C | C |
F | F | C | C |
G | F | C | C |
Easy? You can repeat this all night, and that's what happens many places around the world on any given Saturday night.
So what does this have to do with embedded design and PSoC in general? Both employ strong, repetitive patterns; when you understand the pattern you can follow and alter it and thrive; when you fail to learn and understand it, you and your design can be knocked off your feet by a strong wind.
So what's the pattern for general embedded design? Input-Control-Output (I-C-O). An embedded system will have input(s) to read, output(s) to set and control logic that ties the input status to the (new) output state. All this can be done serially, often the case in a slow-changing system, or it can be pipelined and parallel, or each of the three parts can be asynchronous to the others.
Understand this pattern, and when you are thrown into a legacy design, you have a basis to begin exploring: What are the inputs and outputs? Find them and the code associated with them, look at what's left and it should be the control. Like the blues, the basic pattern has variations and repetitions, so don't just treat it like a hammer and wait for nails to throw themselves at you. That's why everyone doesn't do this stuff, right?
What about PSoC? It's repetitive pattern is at a lower-level and helps you build the inputs and output portions of your design. In PSoC, the components and user modules follow a consistent pattern of APIs (at least the basic ones) so you can get the lower-level things right more easily (always call "Start", for example) and leave more time to worry about the big problems.
But here is where embracing the I-C-O pattern is important - there is so much you can do with the bits and blocks of the PSoC, you can easily weave a spider's web of input and outputs where your control gets stuck and you can't find the end of one input string or the beginning of another. Keep a clear eye on how your ADC, PGA, DAC, PWM, DMA, USB, I2C, etc user modules fit into the inputs and the outputs (document it). If you let them "take care of themselves" you can get a nasty web of chain reactions and side effects. And once you're in a web, struggling can be futile, physically or with your scope and debugger - you've got to get out and take a look, find your way back to the pattern. And maybe do some serious cutting and chopping to even see what's there.
OK, for extra credit, what's the PSoC blue's scale?