Size matters - System success depends on initial design

• Software Development
• Hardware Development

Too many times during the initial phases of system design, opposing interests start fighting for valuable resources, sometimes without even knowing that they are.  Case in point, a development project is starting up with a very simple product.  For the user interface, Engineering wants to use a very simple character based LCD display and a couple of membrane switches, while Marketing wants a graphic display with a touch screen.  The cost difference between these two items is only beginning of the true cost issues.  In our company, if a graphic display is going to be used, the implication is that a graphic library package is going to be used and this means that the CPU and memory costs are soon going to start climbing.  Further more, since our company has such a fine line between embedded programmers and system programmers (read Windows) and the new product has a GUI, it could also mean that some sort of real time operating systems or worst yet, an embedded flavor of Windows might be used to support the graphics.  Here comes another hit to the bottom line as we roll in some licencing costs and CPU and memory costs are going to increase again.

Our simple product has not left the first round of design and we already have a huge range of potential cost targets.  In the first column we have a very simple design that can be handled almost entirely with an 8051 derivative and some basic support chips.  In the second column we have an ARM9 processor with external SDRAM and FLASH memory.  The cost and complexity differences are quite large, and up to this point the actual requirements of the product have not even been addressed.

The product in question here is a very simple device; it is a work-flow instrument that assists in sample preparation in the life-sciences field. The product requirements for this product include: a motor drive to open/close a tray (like a CD), a few sensors (temperature), a couple of interlock switches and a couple of high current drivers.  Nothing in this feature set pose any heavy requirements to the CPU.  For this product there is no requirement for any high-speed sampling or any heavy-duty processing, so again nothing on this side to support the requirement of the extra cost associate with the user interface.

So how do you justify the cost differences between the two different designs?  This is always difficult for me.  I am a tried and true, build it yourself kind of guy when it comes to embedded products.  I am planted firmly in the KISS (Keep It Simple, Stupid) camp.  I understand that the Marketing group believes that a sleek and sexy interface will sell products, but this product is not intended to be either sleek or sexy (it is a little ugly box that serves a purpose).   I on the other hand believe that you sell products based on the cost to functionality equation, i.e. people buy products that do what they need done without emptying their checkbook.

So how does size matter?  Well depending on what path the design takes, either character or graphic LCD, the supporting systems (CPU, memory, FLASH, etc.) will need to be sized according the design.  Clearly identifying the needs (in this case the user interface) up front, will allow the rest of the systems to be sized to handle the task.  Knowing all the requirements up front, and taking these into account as the design proceeds, will lead us to the best possible product in the end.  Things that should be closely monitored are the paths for growth.  If the product is designed with enough memory to allow for 8 different BMP display images, and later marketing decides to add 4 more, will there be a growth path to allow for it?  Is there a pin-compatible CPU with twice as much memory?  Or is there a pin-compatible SDRAM module with twice as much memory?  These are all issues that the initial design should address, as these sorts of changes are always lurking around most products.

How will all this work out?  It is anyone's guess.  I will keep my fingers crossed for the clean and simple, but be prepared to address the more complex design if that is the path we end up on.

Until later,

Gene

Sign in