Advertisement

Analog Angle Blog

If Integration Is the Solution, What Was the Problem? Part 2

Last time, in If Integration Is the Solution, What Was the Problem? Part 1, we looked at the ICs of the integrated-solution approach (often called the “hardware”, but I prefer to reserve that term for the mechanical components).

But that's only part of the story; there's also the software. Let's face it, without software (or firmware), all you've got is some nearly-moribund silicon, but not much more. Somehow, you have to breathe life into it.

The good news is that if you are using a known, predefined chip or chipset, you can also expect to have various levels of software available that will make those ICs play together; they may even implement some of the application. But you have to ask:

  • Where does it reside: in system processor memory, or the application's IC(s)?
  • Do you write the bulk of the low-level code, using some tools from the IC vendor? Or does the vendor provide an almost ready-to-go package for you, to which you “merely” add the higher level-functions such as user interface?
  • To what extent can you “get in there” and modify the software if you need to, or is it embedded as firmware in the IC(s)? Do you just get to set operating points and parameter values, but not much else — and are you OK with that?
  • Who is there to support you and your project when you have questions, whether on the circuit side or the software/firmware/application code side?
  • Did you want to write the application code yourself, because you can do a better job, or because you want to feel valuable on the job?
  • Who is providing this application code, and how good is it? Did knowledgeable provide it? Is it from a qualified third party, or maybe someone who was “volunteered” and is not really versed in the application? And how was it verified? While many applications seem straightforward at first, all experienced engineers know that the challenge is in the details; for example, feature extraction from cardiac waveforms is not easy, regardless of how good your analog front end (AFE) chip set may be.

Part of the rationale for using an integrated chip or chips set and applications code is simple: Who has time to re-invent the wheel when 80 percent of the project's basics is similar to what someone else is doing, in many cases? It may be fun to learn by doing, but you can't take the time to discover everything on your own. You have to leverage the experience of others.

But it's always important to look and investigate carefully what you're getting, and not assume that the other guy has all the answers — especially when you are not sure of the questions you'll be facing from management and customers.

Related posts:

11 comments on “If Integration Is the Solution, What Was the Problem? Part 2

  1. TheMeasurementBlues
    May 6, 2013

    Bill wrote”Who has time to re-invent the wheel when 80 percent of the project's basics”

    But rmemeber, the reamining 20% will take 99.8% of the time, given that you can spend nearly none of your time on the code that already works

  2. Bill_Jaffa
    May 6, 2013

    You are absolutely right–but if you also try to re-invent that wheel, the project will take 150-200% of the scheduled time, rather than “just” 100-150% of the time.

  3. TheMeasurementBlues
    May 6, 2013

    Bill proves once again that everything takes twice as long and costs twice as much as you expect.

  4. Bill_Jaffa
    May 6, 2013

    I have several product/project rules, all learned and reinforced the hard way:

    –beware the law of unintended consequences.

    –be careful what you wish for, you might get it.

    –you can have it done cheap, right, or right away, but only two of those three–so decide which one you can live without!

     

  5. eafpres
    May 6, 2013

    My father was fond of reminding me “If you are doing something the way it has always been done, you are probably doing it wrong”.

    I also like (quoting from the film “Contact” with Jodie Foster, as said by John Hurt) “the first rule of government spending: why have one when you can have two for twice the price”

     

  6. eafpres
    May 6, 2013

    @Bill–thinking about your comments on software and firmware, I'm struck by the reality that by the time you are loading firmware or software, your IC is part of something much bigger–integrated at the board or SiP level or something.  This made me think of some earlier comments about M2M (Machine to Machine communication) and the reality thatost of the inputs are analog, then go through ADC, then the digital microprocessor does its thing, and the data go off into the network.  Most of those solutions are now “modules”; I wrote about the higher levels of functional integration occuring at the M2M module level over on The Connecting Edge (sibling site to this one).

    A significant issue with then integrating these modules into higher level, useful “systems” is how much code for various applications is already written and either loaded onto the module (firmware) or is available through the vendor.  This can be a differentiating factor.  If you do not ask the right questions of the vendor, your total project cost and time can be much higher.

  7. Brad Albing
    May 6, 2013

    Oh – this:

  8. Davidled
    May 6, 2013

    As other aspect, all process for software could be required such as revision control, code usage, spec review every weekly meeting. Through process, all team may have a common ground. In the development stage, function of code is review together in timely manner. Any correction will be updated through the right channel. Therefore, as long as two parties follow up the process, time and cost will be not as high as expected.  For example, process may be V type model.

  9. Vishal Prajapati
    May 7, 2013

    I had seen “Efficient” instead of “Right”. This is very interesting and thoughtful triangle indeed. Very true for almost all systems.

  10. Brad Albing
    May 7, 2013

    The bain of engineers everywhere – the revision control/review meetings. We all know that there must be proper documentation with the associated change orders and revision control. But it's a giant pain in the butt.

  11. Brad Albing
    May 14, 2013

    I knew that rule as “Everything takes twice as long as it takes.” This version of the rule has an iterative aspect to it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.