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.
With erupting concern over police brutality, law enforcement agencies are turning to body-worn cameras to collect evidence and protect police and suspects. But how do they work? And are they even really effective?
A half century ago, cars were still built by people, not robots. Even on some of the country’s longest assembly lines, human workers installed windows, doors, hoods, engines, windshields, and batteries, with no robotic aid.
DuPont's Hytrel elastomer long used in automotive applications has been used to improve the way marine mooring lines are connected to things like fish farms, oil & gas installations, buoys, and wave energy devices. The new bellow design of the Dynamic Tethers wave protection system acts like a shock absorber, reducing peak loads as much as 70%.
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.