@rickw95 - Faster electronics can bite both ways. Faster hw may result in unutilized hw bandwidth because the sw is coded assuming slow electronics. Faster CPU will cause faster sw which might break when running on same-speed hw. (We had that problem once.) The best way is to make sure hw provides interrupts and/or done bits for all events and task completions, and then have sw use those bits to know when to move on to the next step.

@AlanJayWeiner - Keeping or dropping something that "might" be used in the future. Once something is in and unchanging, maintenance efforts are typically low. Taking it out will cause turmoil and needs to be tested. Putting it back in later will cause more turmoil and will need to be tested. Weight that against the likelihood that it will be used later.

@LevitonDave - Code compile switches can be complicated but it can be done it a way to simplify things. Because I had to support many printer models and ASICs, I developed simplified techniques and have presented classes at conferences on that subject.

@luizcosta - You sure ask some good, thought-provoking questions. One of the best ways for versioning the hw/sw interface is for hw to have a version regsiter. This allows sw to verify its knowledge of that version. This is especially necessary for FPGAs that change frequently. Also, each block should have its own version register. That's the highlights, if you want more details, send me an email.

I've not done Android development but I do have an Android phone so I've been following a few apps and have seen where some apps have problems with some phone models. I do agree it does sound messy to try to get an app to work across all past, current, and future models. And it's not just across hw models but also across Android OS versions.

Re: Feature creap and bloat if adding unnecessary stuff: In sw, you can wait to add it in until needed. If the hw part is there but sw is not, it is generally not a problem. In hw, if you don't add in the feature because it is not needed for this product, you will be forced to make a new ($$$$) chip to add that feature in later. If you add that feature in now, then, even though you can't thoroughly test it with this product, it is there and could be used on the next product without making a new chip. As will all things, good engineering judgement is needed when determining what to put in and what to leave out.

@flaredOne - "Feature creep" is generally referred to adding in new features. I'm more focused on implementing all exisitng features, not just a subset. And when adding new features, that it doesn't break existing components working with existing features.

side comment - I'm looking for a desoldering station for thru-holes (vacuum pump type - rather than hot-air for SMDs, although I could use that too). If anyone has one I can get "real cheap" please let me know. alan@ajw.com

Alex - please let me know if posting that is ok, and I apologize if it's not.

@Chuck Matthews - Adding unneeded functionality vs. Agile. Agile is fine with sw. You have the agility to add it easily. Agile does not work with ASICs and SoCs that take more than 3 months to make and cost more than $1,000,000. On the sw side, it is okay to not add until needed but if a feature is already in, don't take it out because it is not needed in the next product. Taking it out causes code turmoil and more problems when you have to add it back in for the product after that.

@luiscost - The fundamental communication between hw and sw is simply sw writes to a hw register when it needs to tell hw something, and hw generates an interrupt when it needs to tell sw something. In most cases, a sw driver totally owns its respective hw registers. No coordination needed. The only complication is that when hw generates an interrupt, it takes some decoding to determine which driver the interrupt is for. Then that driver services it as necessary. IPC is necessary because both processes can't be running at the same time. So IPC is needed to hold messages (and data) until the other process is allowed to run. That's not an issue between hw and sw.

@micholba - polling vs interrupt. My take on that is that if there is a question, hw should implement it as an interrupt and that allows sw to choose later on whether to poll or to wait for interrupt. It may be that that particular chip is needed two different models where polling is better in one and interrupt is better in the other.

a good matrix for compatibility winds up scrolling off into unexpected dimensions really quickly. Like a system response equation with tenth-power factors (i.e., ten often-unique individual values for some variable).

Using Windows CE for the software menu display interface, sometimes there was not enough memory for including all of the desired features and there was times when they had to decide on which ones to include in the next revision.

I had a problem when changing from one generation of Microcontrollers to the next. It has a Hardware Module to generate a PWM to control a Power Inverter. This hardware should have been the same in both Generation of chips. That was the statement of the Manufacturer.

In the Frequency Inverter in a Range from 1.5kW to 15kW the change ot the new processor worked fine.

In the next bigger one (22kW) every time you switched on Power the current and temperatdireure Measurement fails. It has been directly destroyed.

After a few weeks we found that if you configure the new µContoller like the old one, the default sates of the PWM outputs are inverted.

This causes to switch all IGBTs in the power inverter on to the same time.

In the smaller Units the hardware to drive the IGBTs prevents this, in the bigger one you could do it.

Anyone really INTO interface design, check out the LEAP device reference at the bottom of this chat stack. And I won't mention it again.

@Gary, that ESL sounded like a good approximation of the language necessary for hardware and software to be ABLE to discuss a design before the design process even gets started. Something to look into.

@AlanJayWeiner, I remember one of those circuits -- put in a "missing pulse detector" (a 555 timer circuit) designed to detect when RS232 communications stopped from a device which regularly emitted an "I'm here" msg -- and the detector had a relay closure output used to "kick" the power supply on that monitored device enough to cause it to reboot... Lose!

I remember a story from many years ago - design was to control traffic lights. About once a week, it would lock up. They never found the problem, but added circutry to *detect* when the lockup occurred. That circuit then rebooted the board. Always found that an interesting solution, even if not a desirable one.

CUSTOMER ENGINEER. verify system operation, reporting back to research engineering as to errors noted in the field an possible causes and solutions. also install an test engineering changes in the field.

As you build up your toolkit, you start finding ALL these things you would LIKE to embed in ASICs, etc. But until then, you really can't design every possible "plug THIS hole" to add in. Just leave extra pins when possible!

I'm a Sr. Software apps engineer - helping customers integrate hardware and software we create for embeded systems. I've seen in some hardware have a ton of options, making one have to dig through the manual to get a basic setup.

lastest problem is with Android project - APIs don't work completely or predictibly (e.g., layout a UI in relative positioning; control X is sized in % of a container or other control, and positioned relative to other controls/containers) - works in some orientations, and/or on some devices (phones, tablets, etc) but not on all.

@AlanJayWeiner - I can only hope how soon Comcast will exercise good management intelligence and move on to a new box with new programming. They'd better do it soon due to competition. HW+FW management are all needed to make a company successful.

Worked on an application package which would successfully handle 96 channels of real-time processes -- we used a semaphore mechanism which was artfully derived from the IBM micro-channel hardware synchronization process. Worked amazingly well.

@Ran - I thoroughly agree about Comcast DVR; despise it. We switched to RCN, which uses Tivo. Have to say the Tivo interface is vastly superior. Very consistent and almost completely intuitive. (must be; my wife can even use it... :)

@Gary – Although I was not involved in the design (I wish I had been), the Comcast DVR presently in use in our area (Motorola DCM-3400-M) is very, very unbalanced and is software heavy.It is extremely slow (and it's also very full of firmware bugs).To make certain the problems were not a hardware failure, the box has been changed out approximately 5 times, but the problems remain.Every time Comcast performs a hardware update, they correct a problem or two, but in the process they break something else.They are either not hiring competent programmers or they don't know how to find a competent company to which to outsource.

slight side comment - I remember a case where a signal needed to be inverted before transmitted (to panel light, if I remember correctly); it was easier to do that in software rather than rev the hardware

(psst -- this is NOT spam, or a commercial announcement: any developers looking for new innovative "game changing" interface development opportunities, scroll down to the very bottom of the chat-stack -- look for reference to signing up for a developer SDK for LEAP interface device. I have absolutely no connection with LEAP, just enthusiasm for what appears to be "next gen" potential.)

The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.

You guys are a bad influence. Right now, though, you're competing with the tutorial video for the Google "MOOG synthesizer" doodle on their search page today. There's a contest (prize $300) for "best composition" using the synthesizer... re http://www.moogfoundation.org/

Alex explained that "qualified attendees" are anyone logged in here, basically -- if you're interested enough to attend, you "qualify". So I'm suspecting that they're going to take the list of people who registered AND logged in, and do some form of essentially-random drawing from that list. In a perfect world, they might "weight" any one person's "entry" on the basis of "participation", not just lurking, but that's just me (and a very normal human self-interest) speaking...

Giving this a shot (following the "embed YouTube" directions below, except there ARE no checkboxes for "use old embed code" under the code box -- I see "HD link" and "Long link"). This should be the "Introducing the Leap" video from http://www.youtube.com/user/leapmotion?feature=watch

So "Design for test" would be a robust subset of what you're communicating to us.

Encountered any "game changers" in the design field recently?? Had any chance to look at the Leap Motion product, get any feel for how design tools might be about to make an evolutionary jump? While I ponder their claim to 0.01mm detection/resolution (watch for their "writing within a one centimeter square" in their YouTube video), I am struck by how their "cloud of link-interconnected websites" correlates so visually with our "cloud of design-specific particulars needing to be considered during the design process" -- and how gestural access into that cloud would appear to simplify USING that data.

If you go to the LEAP website, you can get your name on the list as a potential developer, which would give you a free spatial "recognizer space" device AND access to their SDK. Just don't crowd ME out, please!

Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.