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!
we tried to define a hardware abstraction layer, but perhaps due to lack of experiene, we had to to change it for each new product (3 so far). Hopefully, we have finally gotten it correct now...
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.
@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!
@GStringham: "@Bob Loy: Making a change to a new development tool chain would require a reset and start again. Trying to have reuability across two different development chains is a challenge."
But isn't the 'promise' of good old vanilla C that it will transcend 'minor' changes like a new compiler, DS, etc?
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
@rlallier, Been there, too. OS is also changing. Sometimes it seems like a headache to have to learn all the new tools, etc, but I can see the advantages far outweigh them. ;-)
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.
@Bob Loy: Making a change to a new development tool chain would require a reset and start again. Trying to have reuability across two different development chains is a challenge.
@marsch: Drastic changes in the build process will required drastic changes in the process. You might have to have a break such that reusable code on one side won't work on the other side.
@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.
@RogerC55: No, I wouldn't call the server-heavy approach reuse. It's just one approach to solve the problem that reusing code on iPhone and Android is very difficult.
@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.
@Chris.Lambrecht Good point. We support quite a few products with a set of reusable libraries and OS. I'd say that the development time has improved significantly as our capability evolved.
In my old opinon the C+ isnot a safety for the embedded system. Now if the thing has been modified. If we can use C on embedded firmware such as Cortex-M3/
Would love to see some more specific examples of code reuse. Maybe a top 5 techniques type of explaination, with code examples. So far I have found the discussing very high level.
@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.
@Rob Spiegel thanks for writing the slide we're on. When typing I lose track. And writing it is much better than interrupting the lecturer as in earlier lectures.
@ marsch - "Can you go back through existing products to generate the requirements for future reusable code? I suppose that's still starting from something. ;-)"
The HAL software is reused as long as the hardware being used in the current platform hasn't changed significantly. However, at a certain point, a rewrite will be necessary.
We use a hardware abstraction layer and publish a vendor spec to vendors. If they want us to use their product, they need to provide an interface adhereing to our vender spec, that our HAL can use.
writing HAL code, many functions can be reused throguh different HW; usually, when developing a new external driver a modification to HAL code is needed
Depends on the contract with the customer, so if they are getting custom code they get all source code and we will not include any reuse components that we want to own the intellectual property on
It's good in almost every case. Only bad part is when the code gets cluttered with too many feature switches, but even that problem can be refactored away.
In some cases, companies block streaming audio. If that is happening with you, you may be able to play the archive. We archive the program immediately after the program ends.
Code reuse has been a HUGE timesaver in my organization. Supporting 15 or so satellite television set top boxes, all with common code bases wherever possible.
hello, anyone has used mikromedia for PIC32?, my question is out there someting similar with linux embbedded on that hardware facilities (including screen and touch for only 99 us dls) ? thanks!
One thing about the north is you can always put more on when it gets cold. But here in TX, you can only take so much off when it gets hot. I lived in WA until 6 months ago. It was much nicer there.
I remember going to JHS with all the Coast Guard kids back when Governor's Island in NY was still an active coast guard base as opposed to a summer attraction
@Kentj Ah, that would explain things. The Coast Guard still has a large presence here but quite a bit of the base here has been privatized as rental property and other uses.
Hello everybody. As I realized yesterday, to test and see if you get audio, view an archived session. If you have audio there, you'll have audio in todays session.
-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.
Andrew Morris designed a circuit that could detect a stroke victim's groan and convert the sound into a signal so caregivers would know when help was needed.
New disc magnet motors fit into the design trend of stepping up to closed loop performance while maintaining the cost advantage of stepper motor technology.
At the Design News webinar on June 27, learn all about aluminum extrusion: designing the right shape so it costs the least, is simplest to manufacture, and best fits the application's structural requirements.
On April 21, NASA launched a novel project, putting into orbit three satellites that employ an off-the-shelf commercial smartphone as the control system.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
0 
