Glad to have the archive versions, sometimes I need to take a break or sometimes am compelled to do a little cross checking online to enable or solidify my understanding
Thanks Gary, you've presented some really useful stratagies for adapting code to different hw or environments. This is going to help me and those who follow with future projects.
@gongji: Personally, I too think that the check spelling method is overkill. But the HP LaserJet lab made that a rule. And when you are dealing with hundreds of engineers modifying code for the printer, it is a good safety check to have. The reason it is good because if there were a spelling error, trying to find it would be very difficult. After all, how many people first noticed my FAETURE mispelling at first glance? Once I said there was a problem there, people could see it.
@gongji: Test harness #defines should be in a global header file since all files being tested need to be compiled the same way. Debug #defines should probably be in module-level files since people tend to debug just one or a few modules at a time. You don't want to be deludged with a huge amount of debug info that you don't need.
@gongji: Unfortunately, it is the norm that fw works around hw defects. But it doesn't have to be that way. I have tried to combate that with my many Hardware/Firmware Interface courses, articles, and even a book. You can find more on my website, www.garystringham.com.
The one thing that comes to mind when using compile vs. build vs. run time switches is testing all of the different paths and configurations. Hope that we delve into that tomorrow.
Where should these debug and test harness defines be placed? I assume it should also be in a global header file, along with product and hardware defines? I am trying to push for a single code for both simulation and product usage.
Totally with you on comments and documentation. I have seen code with many #ifdef 0's and #ifdef 1's. I guess they were used as quick/temporary bug fixes. But people are lazy. They rarely go back to add in more meaningful comments once the fix works. My blood starts to boil whenever I see such code...
@chris.j: No, I have not made changes to the slide deck. However, I have made notes of things I would want to change if I were to give this presentation again. Yes, there were several new things I talked about for which there are no slides, including stuff that came up from the online comments.
@Bob Loy: When you change the IDE, are you expected to now support old products on the new IDE? If so, then just make any necessary changes to accomodate the new IDE and then you can support old and new products on the new IDE. But if you want to support code on both old and new IDEs, then more effort would be required to make it reusable. This is where you could make more feature switches to handle IDE_this and IDE_that. But your main question I think is why is there a problem in the first place with porting code to a different IDE. That would require that all the IDE vendors get together and work out their differences and agree on the same everything, which is unlikely to happen.
Gary, thanks so much. Question: Have you changed any of the presentation slide decks since Monday? I downloaded them all at once but it seems like you've mentioned maybe squeezing a few more topics in here and there. Just want to make sure I have the latest.
@rlallier - I'm sort of a noob to embedded C, but yes, I can imagine where dealing with futzy hardware you may have to invent some kludges here and there...
Thanks Gary for the info today and last night. The first website last night has been extremely helpful. It has information in it I didn't expect like about __inline__ . I have many errors not accepting that as well.
@marsch: Advantages of run-time switching. Fewer executables to test and manage. Deploy just one binary that will work with multiple products. Allow the customer to upgrade by paying for a new feature, then downloading a new configuration file, then the feature is turned on.
@JCarlson: why not printf (a)?? Printf is a variable-argument function. You can have with one parameter, printf("hello"), and you can have it with four parameters, printf("combo %d, %d, %d", a, b, c), and so on. But CPP macros do not support variable argment lists. So,
#define PRT_DEBUG(a) printf a
makes it so that PRT_DEBUG(("hello")) and PRT_DEBUG(("combo %d, %d, %d", a, b, c)) has only one parameter, a, in both cases.
@Bob Loy Have you not run into situations where strict ANSI C implementation just doensn't address the problem? Almost every place I've worked has run into situations where there were kludges necessary that rendered the code not strictly ANSI-kosher...
Ran into a problem with comments on the preprocessor directive lines in code I was porting from an in-house language to a commercial C compiler. In-house language compiler didn't mind, but C compiler complained bitterly. Had to fix quite a few preprocessor directives to make it work.
I still have a question left unanswered from yesterday: Since C is meant to be portable, why should chainging to a different development environment mean that "you have to hit the reset button on code reuse"?
Seems like everything we've covered in this class so far, with the possible exception of build switches, should still work fine even under a different IDE.
Driver bug workaround switches don't go through the build system though - they are defined in a private header per product - so those would be compiler switches.
Large complicated code base here. A few make command-line switches (most importantly the model switch) causes our make system to set up about 100 secondary build switches. Each of these build switches also turn on the respective compiler switches.
We use a lot of CPP switches, but perhaps more of the run-time, although the thought with the run-time is to allow a customer to configure the product, not necessarily differentiate products. The overhead is usually too great for that.
The accent of the voice at the beginning does make it difficult to understand that she is saying Blog Talk Radio. Someone on a previous course thought she was saying, "Lost Hope Radio." :-)
Problem is probably local. The thing is, if I can reliably play YouTube videos with this set up, why is the audio streaming for these classes so problematical?
Another #if #endif matching trick: for those with editors that do brace matching, include an open brace in a comment on the #if (or #ifdef, or #ifndef), and include a close brace in the comment on the close brace, like so:
#ifdef JUNK //{
...
#endif //JUNK}
Now your brace matching will automatically toggle you between the #if and the corresponding #endif in the pair.
One of the first projects I had where I work was to triage hardware defects across 6 different ASICs from two venders. The code in slide 4 looks very much like what I ended up doing (with about 10 different workaround switches)
-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.
Yesterday I got called away for "a few minutes" about 1/2 hr before the session started and got back 3 hours later. I got a lot out of the archived session and Gary Stringham answers email wuestions fast.
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 
