I hate to use buzz words BUT - device/platform independence, abstraction, partitioning, scalability are key.
Current implementation must not inhibit future innovation (no cookie cutter approach - no saying, "we can't make a color printer because all our drivers would have to change, we might even have to use [a] new processor(s)"
Bells and whistles are different than features and functions.
By partitioning a design and taking the above 'buzz words' into account as a design philosophy, Pre-Planned Product Improvements (P^3I) are not inhibited, but rather encouraged.
In order to push code reuse in my group, can you give more specifics on the benefits of reuse? The only one I heard so far is porting your code to a new product in one hour. Time to market is a compelling reason, so that is good. How does reuse produce better products as you stated on the last slide?
Overall, another great presentation. Thanks a lot Gary!
@Rob Spiegel, is there a better place than here to provide feedback on the website access to these webinars? I just want to suggest that the email reminder link could at least take me to a login page instead of a registration page, if it can't just log me on altogether.
@Bob Loy, I would hope that as long as the same language is used, the same functionality can be expected of the code no matter what the platform - "dialects" excepted!
But I assume they will at some point: Graduation triggers all manner of good things: We send you a certificate (real, not virtual) signed by the Dean of DKCEC. We will recognize you in our Roll of Honor on the Design News site, as well as on our Facebook and Twitter pages.
So click here now to register in advance for your preferred lectures. Don't delay; space is limited!
Check their facebook page for if you graduated Semester 1
I would hope there would still be an abstraction layer once I get beyond the device "drivers". Haven't gotten that far on my current project yet, but I'm sure hoping to reuse a large chunk of legacy code on the new hardware.
@rlallier: At HP, we had the same build process for all printers and it included appropriate cross-compilers as necessary for the CPUs we were using. (Someone else asked which compiler we used at HP. I don't know. Some other team dealt with that.) If you have to deal with multiple build tool chains, that would be another switch which I will get into tomorrow.
@marsch You should try living with the opposite problem. We got married to a very primitive set of in-house tools that worked really well for us, across a lot of product lines and allowed us to support a common OS for several different products build on several different hardware platforms. The problem was, we needed to evolve and our in-house tools weren't all that well developed for evolution themselves. We ended up re-writing the OS for a new set of platforms using off-the-shelf tools...development environment and build chain. The problem is...we still have to maintain our legacy systems because the products themselves are still in use and warranted. Nobody wants to work with the old legacy tools because they are more primitive.
@GStringham I would suppose that a real difficulty is getting your build process and code base entanged or married to a particular development environment. When you change hardware platforms then interfacing your code with a new build-chain and different set of tools could become problematical. Is there a systematic way of attacking that problem?
@Don H: For Hardware X, Y, and Z, I was thinking more of different ASICs, chips, hw components, not limited to just MPUs. But brand difference may be a factor such that X and Y were MCUs of one brand and Z was of a different brand.
@jfincher @rlallier I get a huge improvement out of reuse. What I find the challenge is to know where to draw the boundaries in the code. I haven't run into a firmware developer that doesn't claim to have reusable libraries. But the real indication that the reusable code is doing what it is meant to do, is when one can develop firmware faster and more reliably in the future.
-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.
The first Tacoma Narrows Bridge was a Washington State suspension bridge that opened in 1940 and spanned the Tacoma Narrows strait of Puget Sound between Tacoma and the Kitsap Peninsula. It opened to traffic on July 1, 1940, and dramatically collapsed into Puget Sound on November 7, just four months after it opened.
Noting that we now live in an era of “confusion and ill-conceived stuff,” Ammunition design studio founder Robert Brunner, speaking at Gigaom Roadmap, said that by adding connectivity to everything and its mother, we aren't necessarily doing ourselves any favors, with many ‘things’ just fine in their unconnected state.
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.