It's the first post so... | Cypress Semiconductor
It's the first post so...
I guess introductions are in order. I am Jon Pearson, and my PSoC experience harkens all the way back to a device the majority of the thousands of PSoC users probably don't even know existed (CY8C26xxx). While it's hard to "see" a chip tape out from a marketing office, that's what happened two weeks after I began in September 2000. Two months earlier my wife's "patience" with my midlife full-time drop back into university life ended and I was at a job fair talking to a start-up that was going to create a user-definable microcontroller. I thought the idea was up my alley after 13 years slinging you-name-it code into yet another controller for God-knows-which client (contracting, a story for another time). I was looking for a marketing/definition role and PSoC was just coming together. Perfect timing. I drifted toward my strengths and over the rest of the "noughties" (no kidding, that's what we're supposed to call the years 2000-2009, I googled it) I became more and more involved in the design tools side of PSoC, letting other folks define the bits and bytes of the silicon. And as "touch" is now a huge part of Cypress and PSoC, I weaseled my way into that field, and now I'm involved with touchscreens, working to shape how customers can use our tools better to make designs in PSoC faster and easier.
The point of this blog, I hope, will be to share and compare design methods and fads, and keep abreast of how we can make things work best, keep marketing and engineering management both happy with better and faster stuff delivered on-time. Because methods can help keep the madness at bay. I will steal voraciously from anything good I see and post it (with attributions of course). I expect I can share a good story or two along the way to help drive the points home.
First one comes to mind upon reading a recent Jack Ganssle posting on Embedded.com called Software for dependable systems, a discussion of a new book of the same title. I like Jack's writing, because he's been around, seen a lot, and isn't easily swayed. This article reminded me of a call I had to go work for an implantable medical device company (about 15 years ago). They were interested in my avionics experience, especially the part that dealt with verification. Turns out the FDA had finally realized there was a computer program in the pacemakers and didn't know how to "qualify" it. The company wanted to generate a ton of verification paperwork fast (including products delivered many years back), and they knew that the FAA and DoD followed methods that were good at that. The more they explained the job the happier I was that I didn't get it.
This article from Jack appealed to me because I see this struggle all the time with PSoC customers with smaller projects. When more than 1 guy is involved, and there isn't a plan to deal with this (or a method to follow) things starts to spiral out of control as the schedule deadline looms. Coming from avionics background, I know the "methods" applied (such as DO-178 and MilStd1553) and when used well they can increase quality. But many times that increase in quality comes with such a high price that unless the government is footing the bill, it won't happen. Huge barrier to adoption.
Any method, no matter how good, is only useful when those applying it know what's in it for them, how it will help. And, in a nod to the "Agile" folks, Jack points out that the book authors agree those applying the methods actually need to be capable of doing so. The article even has a brief discussion of how C is dangerous and a suggestion for something called SPARK, an Ada derivative (more in the book I'm sure). Having used Ada and C/C++ and a couple other language varieties in between for embedded programming, I think Jack (channeling the book authors) makes good points. But for most of us, the list of programming language choices for our projects can be counted on our thumbs, and don't include anything very exotic.
Take a look, especially if your software "quality" experience is less formal, and you may get a few ideas.
See ya soon!