HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
REGISTER   |   LOGIN   |   HELP
Comments
You must login to participate in this chat. Please login.

Thanks for showing the test harness support discussed.

Iron

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

 

Good presentation!

self adapting sounds like an entry level plug 'n play concept ... great idea

nice to see debug / test harness support

Another stimulating lecture.

Iron

I've written code for live and simulation.

Iron

A good book should always have you develop code to be reused.

Iron

Good point about how to use code in conjunction with HW.

Iron

@Gary - self-adapting looks like just pushing config files into h/w... (this is how I interpret the "may require h/w support" comment)

Iron

@Gary - a good SE class should talk about best practices including the code reuse (it's emphasised in object oriented)

Iron

Great to have access to the recorded sessions

Iron

Missed the live lecture again

Iron

thanks

looking forward to tomarrow

I havent written code for both a simulator and live 

but have set up a stress tester rig to test out my code

I have had to fix both hardware defects and also 

driver and firmware defects in the higher level software

for a good book on overall 

good programming I think it talks about code reuse

betteer late than never. thanks for the lecture Gary.

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.

Iron

Thanks Gary for sharing knowledge

Iron

Very informative lecture

Iron

@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.

Iron

@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.

Iron

@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.

Iron

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.

Never thought about checking for CPP spelling errors. Interesting point, but seems overkill to me.

Iron

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.

Iron

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...

Iron

The software fixes for the hardware problems is just practicality of costs. By the time software sees the hardware its usually too late .

I am a hardware engineer. Every chip I have worked on that has gone into production has firwmare workarounds for hardware "bug" fixes. It is the norm.

Iron

Don't you just love this industry where everybody reinvents the same wheel? #JobCreation #LOL

Iron

Thanks for another great session

@GStringham - Oh, I didn't even think of having to support multiple IDEs. That would be nasty indeed.

 

Iron

Thanks Gary for a great program. And thanks to all of you who attended this program. See you (so to speak) tomorrow.

Blogger

@jcbacas.. I'm in the same boat :)

Iron

@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.

Iron

@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.

Iron

Um @jcbacas you can always listen to the replay they make it immediately available after the session is over

@Gary: I like the way you handle variable argument lists in functions called by macros. One of the better approaches I have seen.

Iron

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.

 

Iron

Late again, but made it anyway

Iron

@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...

Iron

Thanks for sharing your knowledge, Gary.

Have a good day!

Iron

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.

Iron

@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.

Iron

@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.

Iron

@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...

Iron

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.

Iron

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.

Iron

@psvail: If you are using a compiler that does not like comments on the same line as #endif, then put the comment on its own line above.

Iron

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.

Iron

very informative lecture indeed

so thanks a bushel

Iron

That's funny about the accent, Gary.

Blogger

Mostly compile time switches. Also, some run time switches but to a lesser extent. Thanks, Gary.

Iron

I have used run time switches based on detectable hardware differences. Often for software work arounds for hardware issues.

I think I need to start using more compiler directives. Good examples last couple of days.

Iron

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.

Iron

Another good lecture, thanks!

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.

Iron

Compile Time Switches for Resource Bound devices, Run Time Switches when avaliable.

Iron

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." :-)

Iron

For thos who had difficulties with the audio, you can play the archived program in just a couple minutes.

Blogger

New function parameters with defaults help when expanding a function.  Old code will still build as is.

Iron

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?

Iron

I will be interested too in finding books about software reuse

Iron

Compile switches mostly

Iron

Compile & run, build not so much (but I probably should take more advantage of build).

Iron

Good to know thank you Gary

Iron

I am too much of a novice to have much useful feedback to these questions. Enjoyed the talk again though!

Iron

Gary thank you for today's lecture

Iron

@Gary: I have used all of these approaches and generally prefer them in reverse order of presentation, eg, try to eliminate the need first.

Iron

used em all ... although I do prefer to do as much of it in run-time as possible. It is more flexible and really has fewer pitfalls

Iron

Compile and Runtime switches.

Iron

I use compiler switches the most.

Iron

Have used -- and still use -- all 3 types.

Iron

@marsch

 

There might be other reasons, but where I work, that is what we use it for..

Iron

Mostly compile-time switches

Iron

I don't think I would say "is a NOP"

I think I might say "has no effect"

rlailler, you may try a differenct growser. Or, you can play the archive right after Gary is finished with his talk.

Blogger

audio still works fine, here

Iron

@MarkO - Thanks!  Guess I was looking for more than what's there.  ;-)

Iron

for self-adapting, just have an input pin look for hi or lo - tie the pin to Vdd or Vss through a 10K resistor

Iron

lost audio...refresh doesn't help

Iron

We're now on slide 19.

Blogger

@marsch


A Product with One Compiled Code Base, with Run Time options saved in NVRAM to enable or disable features.

Iron

We're now on slide 18.

Blogger

More code than will fit in flash.

Iron

 That makes sense Mr. E.

Blogger

Pitfals: Migrating projects from older Visual Studio 6.0 to higer VS 9.0+...

 

Iron

If there are enough different options #define in the code, it gets unreadable.

Iron

I don't write code with pitfalls ;)

Iron

it's easy to break your builds if you are not rigorous with testing every build type prior to a commit (e.g. debug vs release vs other build-switches)

Iron

@psvail: If your audio has had pauses, you may be lagging the lecture and that may be why it appears that Rob Spiegel is "off by one".

Iron

We're now on slide 17.

Blogger

Run Time Bugs, NVRAM Coruption.

Iron

We're now on slide 16.

Blogger

What are the advantages to using Run-time switching?

 

Iron

We're now on slide 15.

Blogger

We're now on slide 14.

Blogger

(but it's numbered 12)

Iron

We're now on slide 13.

Blogger

Slide 12 was an OpenOffice specific platform issue.

We're now on slide 12.

Blogger

We're now on slide 11.

Blogger

We're now on slide 10.

Blogger

We're now on slide nine.

Blogger

@BobLoy  And that has the benefit of not having to change comments if you use the /* */ format in the code you want to "comment out".

Iron

@tocard: might be a specific version of gcc.  I'm sure there are switches to have it ignored, too...

 

Iron

We're now on slide eight.

Blogger

I use:
#if 0
#endif /* if 0 */
pairs to remove code. Much more searchable than commenting out.

Iron

Hate those type of errors a real pain.

Iron

@Gary: we see it : FAETURE.

Iron

PC with simulated I/O and display and on embedded hardware.

Iron

Simulation 1st then real hw test

Have no simulators. Only real HW.

Iron

no simulator, but definitely a lot of test harnesses... also, release versus debug code for sure

Iron

Sometimes have to develop code that runs in both HW and simulator

Iron

I have not used a simulator.

Iron

Mr. E: I like that. Why didn't I think of that?

rarely have simulators

Iron

We're now on slide seven.

Blogger

@psvail  I've never gotten compiler warnings with comments after #endif.  Is that a C standard to generate a warning or just your compiler, do you know?

Iron

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.

Iron

@gwp2  Them's fightin' words!  LOL!

Iron

free and instantaneous, right?

Iron

We're now on slide six.

Blogger

@Tocard - And I thought we were the only software engineers that said that.  lol!!

Iron

Tocard sounds like your ready for management lol

Iron

Still worth it though...

 

Iron

Comments after #endif will generate compiler warnings.

 

Iron

Comments after endif are really a good idea. I usually put those in because often times I'm working with large, multi-page blocks of code.

Iron

...and why fix it in hardware anyway?  Software is FREE!  ;-)

Iron

We're now on slide five.

Blogger

I thought there were only software problems...:-)

Iron

@Gary: have had to work around hardware defects in software on a number of occasions.

Iron

yes, I have fixed many hardware problems with work arounds.

 

Iron

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)

Iron

Since i'm primarily the hardware guy its alway software defects............

Iron

both: HW and code work around

Yes, lots of SW workarounds.

Iron

I didn't have to work around HW flaws, but coworkers have.

Iron

Fixed many hardware problems with software work arounds.

Iron

Seems like its all the time!

Iron

sure - hardware workaround

Iron

I have CAUSED a hardware defect that required a workaround  :)

Been there, done that!

Iron

We're now on slide four.

Blogger

Have not looked for books or sessions on software reuse.

Iron

http://www.codecademy.com/tracks/4f4bdd96848740000300026a

 

We're now on slide three.

Blogger

"Blog talk radio"  Of course!  Thanks, now I can sleep at night.

Iron

If you don't have Blog Talk Radio, refresh your browser.

Iron

Hi form Midland TX

 

Iron

@sjaffe It sounds like "Laptop Radio" but it's from the "Blogtalk Radio" site.

Iron

We're now on slide two.

Blogger

No Problem on Page 12 of PPT.

Iron

Hello from Massachusetts

Iron

@bitbanger55: Page 12 is misformatted for me, too. However, I am using OpenOffice Impress for viewing. Not exactly the same as PowerPoint.

What is the introduction?  Sounds like "LONG PULL RADIO"?

Iron

Morning, North Pole Alaska

Iron

Greatings from Waterford, WI

 

Iron

page 12 looks fine on my slide deck...

Iron

Page 12 of my PPT rendering was mis-formatted. Anyone else have that problem?

Hello from IL. Good discussion post-class yesterday on external editors (nice to see some SlickEdit, CodeWright, and Notepad+ Fans).

Hello from Southeast Michigan.

Iron

Greetings from Austin!

Iron

Good Morning to all from CA

Iron

Welcome to the program. Gary will be on soon.

Blogger

Hello from Alameda, CA

Iron

@kdavidson No, but my father is Will Cheetham and my brother is W.E. Cheetham.

Iron

Hi from Waterloo, ON, Canada

Greetings from Portland, OR

sunny and 3C (37F) in Ottawa ON

Iron

It's sunny and 45F in Boise.

Iron

Should be a good session today

Hello Everyone. Sort do I. I am ready for today as well.

ready for another! :)

Iron

Hello. Looking forward to today's presentation.

Iron

Howdy from Fort Worth,TX !

Iron

@JCheetham Hey, are you from the law firm that sponsors NPR's Car Talk? Dewey, Cheetham, and Howe? :o) Sorry, it's quiet here.

Iron

Hello, everyone,

I am here in Vanvouver.

Iron

We had ice on the lakes this morning in Hayward Wisconsin :|

Iron

Hello from Scottsdale, AZ

Iron

Hello from Albuquerque, New Mexico.

Blogger

-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.

Blogger

 

-Please join our Digi-Key Continuing Education Center LinkedIn Group at http://linkd.in/yoNGeY

Blogger

-Be sure to click 'Today's Slide Deck' under Special Educational Materials above right to download the PowerPoint for today's session.

Blogger

@JCheetham: 5:44!? Sounds like you need coffee too!

Iron

It is 70F and partly cloudy in Hilo HI at 5:44 AM.

Iron

"questions" not "wuestions".

Iron

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.

Iron

Good morning all from sunny @ 57F Richmond, TX

Iron

My fingers are not coordinated. Need more COFFEE.

Good Morning from Partly Cloudy San Jose, CA

Expecting RAIN Tonight. It's 48°F now w/ a High of 67°F.

Iron

od Morning from Partly Cloudy San Jose, CA

Iron

Good Morning from Partly Cludy San Jose, CA.

Expecting RAIN Tonight. It's 48°F now w/ a High of 67°F.

Iron

Cool and dull overcast day here in Colorado ... need more coffee

Iron

Good Morning from Syracuse, NY .Learned something new yesterday, looking forward to today's message.

Morning, yes.  Good, maybe.  Let me get some coffee first...

Iron

:) Morning 

Thank you for supporting these courses

Iron


Partner Zone
Latest Analysis
Practicing engineers have not heeded Yoda's words.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Rockwell Automation recently unveiled a new safety relay that can be configured and integrated through existing software to program safety logic in devices.
These are the toys that inspired budding engineers to try out sublime designs, create miniature structures, and experiment with bizarre contraptions using sets that could be torn down and reconstructed over and over.
Connected sensor-enabled applications will improve the consumer experience -- and generate new revenue streams.
More:Blogs|News
Design News Webinar Series
3/27/2014 11:00 a.m. California / 2:00 p.m. New York / 7:00 p.m. London
2/27/2014 11:00 a.m. California / 2:00 p.m. New York / 7:00 p.m. London
12/18/2013 Available On Demand
11/20/2013 Available On Demand
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Apr 21 - 25, Creating & Testing Your First RTOS Application Using MQX
SEMESTERS: 1  |  2  |  3  |  4  |  5


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.
Next Class: April 29 - Day 1
Sponsored by maxon precision motors
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service