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.

do you just roll up the sleeves and begin code ...or do you chart or model in a diagramatic way first ... a word on that would be useful

prefer block comments to line comments, but line comments that amplify or reiterate or clarify block comments are / can be useful too

 

 

benefits of re-use: speed of development, quality, confidence level and testing benefits

In my experience, directives seem to work best at compile time but I'm interested in using runtime directives for a certain project with multiple configurations - I look foward to the next lesson.

Iron
Debugging , testing is another good examples, production code don't need debugging parts.
Iron
I used C directives - not always as needed but they usefull, not only for support different models of product.
Iron

Great Day 3, thanks.

Iron

Otherwise it may come back to bite you.

Iron

I think even small code needs to be commented alot.

Iron

I've used FPGA's before.

Iron

I have not used CPP directives.

Iron

@Gary - no custom asic/fpga

Iron

@Gary - expert user of CPP directives

Iron

Great to have access to the recorded sessions!

Iron

Missed the live lecture again

Iron

Another great lecture 

Not as relavent from my perspective buut still

grat to talk about the finer points

I actually dont use C directives because I program in a higher level language

Thank you for lecture Gary.

Small code is OK to reuse if it is without comments

FPGA use most of the time

@gongji: Like CPP directives, there are good and bad ways to use /* */ and //. Using /* */ to comment out a chunk of code is bad. #if 0 and #endif should be used for that. The book, "Embedded C Coding Standard" by Michael Barr allows the use of both /* */ and //. It also says not to use it for commenting out code nor should there be nested comments.

Iron

Thank you Gary; excellent presentation

Iron

Lots of examples...    Nice lecture

Iron

I am surprised you use /* */ for comments. We have a rule to use only // for comments. Since you cannot nest /* */, we reserve it only for quick code changes during debugging when you may want to comment out a large portion of code temporarily. I guess you can also use #ifdef for that purpose...

Iron

we use custom ASICs/SoCs

Iron

like the idea of breaking down a product spec into single feature fior #define. That is what I will do too.

Iron

What kind of naming rule do you use for constants in order to avoid duplication; i.e., two engineers choosing the same constant name for different purpose?

Iron

novice. Basic is good, please cover the fundamentals. Thanks!

 

Iron

Useful links:

Gnu's C Preprocessor Manual: http://gcc.gnu.org/onlinedocs/cpp/

Good description of CPP Gotchas: http://www.cprogramming.com/tutorial/cpreprocessor.html

Iron

 

@andrewcrlucas: Interesting about X-Macros. I have never heard of it. But I "invented" that very technique and published it in the April, 2000, issue of Research Disclosure (researchdisclosure.com) under the title, "Structuring Source Code Data in One File to Be Used in Multiple Files." I used that technique in HP's LaserJet code. Now I see from an online article that apparently that technique was used back in 1968. I hate it when I invent something that's already been invented.

 

Iron

I've done quite a bit with the compile time switches, and one of the cons can be the multiple files. I'll be more interested in hearing about run-time switching.

Thanks, Gary!  See you tomorrow.

 

Iron

@sjaffe: Several have commented today on the benefits of run-time switching. I will cover that tomorrow. Yes, compile-time does mean multiple executables but it also reduces the size of code that has to be downloaded into the device. A low-end product wouldn't want to pay for all the memory required to store (and not use) the code necessary for the high-end version.

Iron

Hi Gary, You didn't mention that using compile time switches implies that you'll have multiple executable files that you'll need to track.  With run time switching, you can have just a single executable for multiple products.

Stan

Iron

@mRlu2012: I don't have much space here to write. But the "if (regStatus.active)" on slide 16 is the same as "if (*regStatus & BIT_ACTIVE)" on slide 17, just implemented differently. But the method on 16 can be dangerous. But the reason is too much to explain here. Send me an email if you want a more detailed explanation.

Iron

Another way I use #undef is if I want something turned for only part of the code, such as debug code in only one section of the overall code.

<some code including some #ifdef DEBUG code which won't be compiled in>

#define DEBUG

<some code including some #ifdef DEBUG code which will be compiled in>

#undef DEBUG

<more code including some #ifdef DEBUG code which won't be compiled in>

Iron

The reason I #undef on slide 10 is to make sure they are clear for the subsequent #define. If it was already defined I would get a compiler error. Also by #undef'ing it first, then if I inadvertently forget to #define it to something, it will make sure the check on slide 12 will work properly and not "pass" the test because someone else had #defined it before.

Iron

#adef: Documentation is very important, whether it consists of comments in the code or long descriptive identifiers. Both are needed.

Iron

give me better idea for the new code, Thank you

Iron

Never knew there was a hex editor plugin for notepad+, very useful

Iron

Me too. No prob with the thread jack; class was out. See everyone tomorrow. Got to get back to the mines myself.

Iron

Anyway, guys, enjoyed the chat and sure didn't mean to hi-jack the thread to editors.  But need to get back to work.  See you tomorrow!

Iron

We do both AVR and ARM with IAR.  I'd think Code::Blocks could handle either just fine.  Might have to check it out.

Iron

Of course, Code::Blocks is not restricted to WINAVR for AVR. It is fully customnizable for toolchains and external tools like AVRDUDE.

Iron

@carmacks I didn't know that you could still even buy it! Wow. I do know that it stopped being a supported product after version 6.6, I think...

Iron

@drw36 Thanks, I'm checking that out now.

Iron

Hex Editor Neo has a reduced functionality freeware version and a generous evaluation version of their pro version.

Iron

Yeah, most people I know that were using CodeWright have moved to SlickEdit. I enjoy SlickEdit myself -- it is quite powerful. I do think you can still buy CodeWright, but I do not believe it is actively maintained.

Code::Blocks can ustilize WINAVR for that toolchain. www.codeblocks.org

Iron

I bought a copy of the Pro version of Hex Editor Neo to do the heavy hexadecimal lifting. Even editors like Codewright don't handle inserting values into a file and searching or "value filling" the right way. A dedicated editor is much better if you have to do surgery on large binary files.

Iron

I've not heard of that one; I'll have to check it out.

Iron

I've been using Code::Blocks for awhile and like it.

Iron

@rlallier  THat's probably why it's been so long since I've used it last. LOL!

Iron

@carmacks @rlallier  Yes, we use the Hex Editor plug-in a lot, too, and like it a lot.

And, yes, very feature rich.  There are just some visual anomalies I've noticed with some of the plug-ins, like a text compare one we use, that I'd like cleaned up.  Otherwise, it is a great editor for the price!

Iron

@Tocard Unfortunately, Codewright is abandonware now... :(

Iron

@rlallier  Thanks.  Being just as much a "Windows" programmer as an embedded programmer, I've come to rely heavily on the niceties of the IDE editor -- especially as I get lazier and lazier!

Haven't used Codewright in awhile; maybe it's time to check it out again.  Probably need to look into SlickEdit, UltraEdit and the like again, too.  I'm sure all of those tools have advanced considerably.

Iron

I love Notepad+ as a "quickie" editor. I keep a copy on my personal laptop as well. For freeware, it is amazingly feature-rich. Nevertheless, SlickEdit and Codewright have the larger feature sets.

Iron

@Tocard One thing I love about Notepad+ is its Hex Editor plugin. It has the most readable output of any editor I have ever used, including stand alone hex programs. I don't know if it will do really in depth pattern matching or table files, but I don't use the latter function anyway. But yes, I definitely love Intellisense and Code Complete. Nothing quite like it.

@Tocard Oh, that's a nice trick. I use SlickEdit now. Just recently migrated after being a Codewright holdout. Still getting familiar with the features. Some of the people in some of the other groups use Codewarrior. I tried it, but some of its features seemed a bit less powerful than Codewright's. That may just be prejudice talking. I've used Codewright for years and only did a brief eval of CodeWarrior.

Iron

@carmacks  Agreed.  We use Notepad+ here at work as an external editor.  It's not great, but it's not bad for being free.  I use it a lot when IAR is failing me. 

I just wish that Eclipse had simpler project management and everything else had "Intellisense" at least as good as Eclipse or Visual Studio.  That's what I miss the most in other editors.

Iron

External editors are your friend -- I always find them to be vastly superior to any IDE bundled with a chip or compiler. I have played around with CodeWright, SlickEdit, Netbeans, Eclipse, Notepad+ ... Can't recommend going that route enough.

@rlallier  I had also used Codewrite in the past and remember the code folding.  From my limited playing with the Eclipse-based CodeWarrior editor, it handled nesting really well.  I set it up to make the non-compiled code very light-gray -- almost invisible on the white background.  It made it super-easy to ignore the non-compiled code, but still allowed me to see it if I wanted.  And I had some nested 2-levels deep (tried never to go beyond that) and it worked just fine.  Don't know about 4, though!

Iron

@Tocard I used to use Codewright, which had a feature that would collapse blocks of excluded code automatically based upon parsing the files' defines. The problem with that is that sometimes, it is actually helpful to see what code is NOT getting compiled as well... Color coding conditional blocks sounds like an improvement on that. The problem we had was that the conditional blocks became nested, sometimes up to four levels deep! I wonder how a color-coding editor would handle nested blocks?

Iron

Bye all and thanks for another good session

@rlallier About having to untangle #defines.  There are several editors, I believe Eclipse and NetBeans are 2, that both have a feature built-in that can color code lines that either do or do not get compiled in based on the #defines. 

We use IAR here, so I don't get that benefit.  But if I had really tangled code, I'd probably recreate the project in one just to help out, since I don't have your nice text utility.

Iron

@rlallier I totally agree.  Rewriting and retesting is usually the utopia.  It's rare that I can do it, either, but I can dream, can't I?

Iron

time to go, see all tomorrow.

Iron

@EdB_Vt: Good point. The arrays size can be dynamically determined using something like this:

int array_size = sizeof(LaserDetails)/sizeof(LaserDetails[0]);

Iron

I wish more of our legacy developers had had the benefits of this lecture. We got really burned using product defines and feature defines intermingled. It leads to horrific nesting of conditional compiles that are hard to disentangle and hard to maintain. We developed a small text utility that processes a source file and uses the EBCDIC extended graphics characters to "draw" lines in the listing file showing the blocks of conditional compiles and their nesting.

Iron

I try to avoid using #undef as much as possible... Too great of chance for unintended side effects. If I *have* to do it, then only at the beginning of a file, and making absolutely sure I won't be stepping on anything else.

@rlallier

Exactly...  Lucklly I only have had 3 Code releases, ( not done by me ) so I can reasonaibly fix them all correctly...  But not today..

 

Iron

tniles: I like all your comments and questions. You bring up excellent points. Regarding the "flexible electronics," you mentioned that one buys the electronics once then later buys apps. In that example, the hw is not flexible; you don't buy hw "apps." It's sw that is flexible. But then looking from the side of the app producer, they have to write their app to work on the many different versions of hw out there. In this case, then yes, run-time switching is needed. 

Iron

Gary: On the endiannes, I lost you from slide 16 to 17, going from the struct to the bit masking... could you elaborate on that?

Iron

@GStringham I know what you mean. I was so happy when my company went to two monitors as standard equipment for all software people. Very handy.

Iron

@Tocard The problem with "fixing it correctly" long after the mistake is made is that you end up having to re-build and re-test the things that use the code you fixed. That's not to mention, re-releasing new versions of the software. If you don't end up re-building and re-releasing, then you might end up confusing later code changers who are unaware of the previous changes and have to spend time consulting version control diffs to find out "what else is new" in the code besides the things upon which they themselves have worked. It's a trade-off.

Iron

@Tocard and @pbrodeur


The "proper" thing to do, is to rewrite it correctly..  But doing this as an Emergency Fix, lets me fix the Less Common version, with out breaking the More common version..

The #undef is like a "Get ot of Jail Free" card, because once you #define something, it is that way for the duration of the compile...  Unless you have the #undef...

Iron

While 80-column line lengths may seem old fashion, it does make it easier to print code segments, to have two code windows side by side, to use diff tools without having to scroll back and forth horizontally, to view the code in a debugger, and other reasons.

Iron

@MarkO For a quick fix as you described, I probably would have done the same thing.  However, it sounds like a Band-Aid, as opposed to a "robust" solution long-term.  Not trying to argue; just trying to understand this particular bit of the C language.  But it sounds like, if time weren't an issue, that rewriting the #defines to make them "correct" for the high and low used products would be better -- if time permitted.

But I think Gary had a good point.  I am a big proponent of nested #includes myself, too.  This could be a really good reason for #undef.

Iron

8.3 -- DEC TOPS-10 -- maybe.

Back to defines. :-)

Iron

@Tocard

Just Last Night, I had to make a Quick Fix to code that needs to ship today.  Two different Compile Confiurations to the same Sorce Code, was broken Two years ago, by forcing Both versions to have the same basic settings, by using #define.  The less used version, was broken by replacing an Input Configuration with the Now common basic settings.

To fix the Less Used version, without rewriting the More Used version and retesting all code, I used the #undef to remove the changes, but only from the Less Used Version, and did not change any of the More Used versions code.

 

Iron

@DaveWR, and it seems that knowing how to program with CP/M looked very familiar with DOS! DOS 1.0 didn't even have CLS yet, just like CP/M

Iron

CPM got it's format for filenames from one of the timeshare systems

@tniles: The reason to use #undef is to make sure those values were not somehow defined earlier. This is useful since a particular .h file could be #included multiple times in one file. #include file1.h which #includes fileA.h, then #include file2.h which also #includes fileA.h.

Iron

@rlallier: true about the 132 columns, yet if printed using 10 point Courier New font on an 8.5 x 11" sheet of paper in portrait mode with even modest margins, it will get clipped or wrapped. If you migrate to landscape mode, you get fewer lines per page, yet most of those line are shorter than 80 anyway. It really comes down to personal preference.

Iron

8.3 Nmaes -- first I remember is CP/M -- so maybe they came out of the DEC world -- it was a long time ago... It seems a lot of CP/M command structure came out of the DEC world / philosophy.

Iron

@tniles: Yes, some people use #define to define a list of numbers when they should be using enum{}. If the enum{} is product-specific and therefore needs to adjust, then do something like

#ifdef PROD_GOOFY

#define STUFF_ENUM {apple, bear, moon}

#endif

enum STUFF_ENUM;

Iron

@MarkO: If would rather like to see a compile time error on my colliding define and change the name, rather than blindly do #undef.

I still don't see the need to systematically undef, but again I am an ASIC/FPGA designer who rarely writes C...

Iron

I find with most Windows editors, and with landscape mode listing printing, 132 columns works. Shorter line lengths lead to confusing wrapping or else truncation.

Iron

8.3 names, those were the days.

 

Iron

when you work with something for a long time (like 80 col lines), it tends to become automatic.

Iron

It will always be a shorter path to code functionality than to explain why the code is doing what it is doing. Relying on the code to document itself is pernicious. If you get into the habit of believing that your code documents itself you don't keep in mind how not everyone will understand, months from now, why exactly your code is doing what it plainly says it is doing. Comments explain why, even when functionality itself does not require the explanation.

Iron

Are vendors still trying to sell the self documenting code with their source control tools, they do work but only if you put so much work/effort into it that it would be easier to document the code in a different fashion

@tniles: I knew I would be pushing some hot buttons with how I use CPP directives, including macros. But as you said, they do have their place. And as I have emphasized several times, there are good ways and bad ways to use CPP or any other tool. For example, don't try to use a hammer to put in a screw.

Iron

@pdxesto Precisely. I think the concept tends to induce laziness in engineers. Using descriptive names and good coding practice is important, but the idea of "commentless, self-documenting code" should have died with COBOL.

Iron

@Mr. E Thank you for that.  That makes a lot of sense.

@MarkO Do you have an example of when you would encounter a situation where you wanted to redefine a #define in the same version of a program?

Iron

Self-documenting code very often doesn't.

Iron

@kdavidson: You asked why not use SCAN_TIMEOUT_S when I had just talked about SCAN_SCALAR_US. Good question. SCAN_SCALAR_US will be needed by other people when reusing code for another product but they won't necessarily have to see or deal with SCAN_TIMEOUT. It wouldn't hurt to call it SCAN_TIMEOUT_S but it wouldn't have the exposure that SCAN_SCALAR has in a reusable context.

Iron

Great talk about the use of the pre-processor.  It is an amazing tool, and though not specific to code-reuse is an invaluable tool for automatically generating code.  If you havn't heard about the use of x-macros look over the following link to a stack overflow question I answered a while back.  http://stackoverflow.com/questions/6635851/real-world-use-of-x-macros

@riallier I reloaded the page and chat restarted

 

Iron

@Tocard: occasionally it is helpful to define a macro that aids in table construction or some other repetitive coding, then #undef that macro at the end of the table or code section to make it obvious to a maintainer that this macro is not intended for general use elsewhere.

Iron

@bitbanger55: the url is there now (the first time I tried the post didn't make it through)

Iron

@Tocard


If you try to redefine a #define, you will get a Compile Time error..  Use the #undef FOO_BAR before #define FOO_BAR 1

Iron

"self-documenting code" uh huh... I'm working with some of that this week -- pretty frustrating -- for the most part I have no idea what it was intended to d. I know what it does. These are two different issues.

Iron

http://www.intel.com/design/intarch/papers/endian.htm

Iron

On lags: refreshing page helps with the problem.

Iron

Did the chat session get stuck or is nobody talking right now?

Iron

Yes, I'd also like to know the rationale for #undef.

Iron

I guess my live chat hung up

 

Iron

Gary, please explain why you use the #undef, for example on slide 15.

Iron

comment: While I agree with the need for comments in some cases, I think self-documenting code (e.g. good, descriptive names) helps because most people do not update comments as code body changes

 

Iron

Thanks.  See you tomorrow.

@Mr. E  I have been seeing a max. of a 30 sec. lag after my posts with nothing missing.  I have not seen any mutl-minute lags.

Iron

Thank you for today's presentation

Iron

Thank you.  The lecture was VERY informative.

Iron

Thanks Gary and Rob. It's nice lecture.

 

Iron

@tniles : do you have the URL to the Intel whitepaper?

My last two posts have not yet showed up... anybody else seeing multi-minute lag between Post and seeing their posts in the Live Chat?

Iron

We're now on slide 17.

Blogger

it's a lot easier to implement byte-swapping at compile time for little versus big endian (intel has a good whitepaper on this)

Iron

Using re-usable code is frustrating because of no comments, incorrect comments or unreadable comments (undeciperable). Oh wait! You said that! :-)

Iron

My experience has been that I cannot reuse code written by someone else because of inadequate comments....as you said.

Iron

Some frustration diffucult to underatand and some elation when the implementation is difficult.

Iron

it always need to be reformatted and changed to fit your needs.

Iron

expect good comments which

would help 

Iron

Never got to this level of cpp detail. But good stuff - good to learn this.

Iron

Easy to reuse if documented well.  Some code even refers to external algorithm sources.

Iron

Have run into that pain as well...

Some engineers don't comment well. What's even worse are "magic numbers" without defined literals.

Iron

i had the same problem - refresh your page

I do hate when it gets stuck but F5 unsticks and you get updated messages and audio back

I'm not see my comments

Iron

Slide 14 needs careful coding to insure don't access array past end.

Iron

I discovered 8.3 with CP/M and later DOS 1.0

Iron

We're now on slide 15.

Blogger

both custom asics and off-the-shelf micros

Iron

We're now on slide 14.

Blogger

Refreshing the browser will bring up the posts.

Blogger

@rlallier, separate files is something I've also been using.

@Mr. E, I often end up going back to reformat the long lines so that the file fits better on the screen.

Iron

posts not updating, audio stuck... grrr...

Iron

Actually 8.3 file names comes from one of the old time share system days I believe

We're now on slide 13.

Blogger

let's remember, too, that we're now in the age of flexible electronics. We ship the hardware, and during run time allow users to purchase new features. Clearly, compile-time feature switches fall short here. Something to think about, imho.

Iron

had to refresh browser to get recent posts

Iron

Hi all, sorry to be late

Iron

LongNamesAlsoAreEasierToFindInTheListing

Iron

As of late, most of the designs I have been involved in have used at least one "custom" part (e.g. ASIC, FPGA, CPLD, etc.).

Iron

We're now on slide 12.

Blogger

Off the shelf chips on a custom board

 

Iron

several FPGAs in our product

Iron

Both custom ASICs and off the shelf.

Iron

Mostly off the shelf, but on occasion, custom ASIC's.

 

no FPGA/ASIC, just using off-shelf uC with custom code to replace hardware functions.

Iron

Off the shelf parts on this project

Iron

Off the shelf micro without any FPGAs.

Iron

Mostly off-the-shelf.  I have designed one FPGA.

Iron

Went from a FPGA to a off the shelf hardware part

Iron

We're now on slide 12.

Blogger

Off the shelf hardware.

Iron

IIRC, MISRA recomends shorter Line Lengths.

 

Iron

Is anyone else having the audio pause for up to a minute or more at a time? Had no problems yesterday or Monday.

Iron

OTS hardware.  No asics nor FPGAs.

Iron

mostly off-the-shelf parts

Iron

Off the shelf Parts only

Iron

Off-the-shelf MCUs here.

 

Iron

Off the shelf Hardware parts.

Iron

Off the shelf hardware parts.

Iron

@pdxesto I gave up on the 80 column width a long time ago.  The continuation marker ('\') has been used for this in some cases.

Iron

funny how some styles get stuck, like 8.3 file names.

Iron

long names are your friend - they make your code self-documenting reduces the need for redudant and comments that are never updated when the code changes.

 

Iron

@pdxesto: 80 columns turns out to be a good natural limit that transcends its roots in Hollerith punched cards. I have inherited code with lines that are hundreds of columns wide, and end up having to scroll or wrap to see what the line is doing.

Iron

What about separate include files for specific products, then use the defines to include the relevant file?

Iron

only by virtue of working with many who hold to the 80-column mindset :-)

...

however, when you walk into a code base where 80 has been enforced for years, it makes sense (when in Rome)

Iron

not really thinking about 80 column anymore, but started out not liking to type long names.

Iron

We're now on slide 11.

Blogger

Longer names: how many of you out there are still into the 80 column mind-set? :-)

Iron

Longer names makes it easier

I am hard-pressed to find a good reason to use a #undef (disclaimer: I do not use them)

Iron

@Mr.E I agree that being too explicit sometimes make the names very long but that sometimes a user preference in order to reduced possible confusion.  I have also made "short" #define names but make explicit comments for that line instead.

Iron

@Don H: sounds like a IAR compiler issue (i.e. not choosing the proper types)

Iron

We're now on slide 10.

Blogger

const creates objects with types, #define simply does text substitution, so the resulting type can be different in different contexts, sometimes to your chagrin.

Iron

GAH. Have seen the problem on slide 8 all too personally. Yes. Very hard to maintain. Wait until you get entangled in nested #ifs... ugly

Iron

starting to drop posts again

Iron

We're now on slide nine.

Blogger

enums are very useful :)

Iron

We're now on slide eight.

Blogger

@bjskill: I find that using familiar conventions such as US for MICROSECONDS keeps names from becoming too long.

Iron

I use the #define, but I had serious problems with an IAR compiler and had to almost everything from #define in main.h to const in main.c.  The problem was the #define data types were set by the compiler whereas the const data types were set by me.

Iron

We're now on slide seven.

Blogger

a lot of times people think they need a #def, but what they really should use is an enum{}

Iron

hard coded constants don't tell much about what or why the value

Iron

Using CPP do the computationalso makes code self-documenting 

Iron

You probably meant SCAN_TIMEOUT_US.

Iron

Wouldn't it better to spell it out explicitly?  (e.g. SCAN_RATE_SECONDS, SCAN_RATE_MICROSECONDS, etc.)?

Iron

please don't champion the use of macros... :/ they have their uses, but then everyone wants to go write one and pretty soon you get a bunch of bloated spaghetti code

Iron

I got around my audio problem by streaming the audio through my iPhone :)

 

Iron

Average - saves lots of comments when used properly.

Iron

#def's are best for pin assignments, too

Iron

Expert user. Ran into the problem of using directives for large differences. Should have gone with product specific include files. Really makes a mess to use too many switches. Had to write a tool to help parse the code sections and disentangle the nesting.

Iron

I'm probably a novice user when using CPP directives.  I have primarily used them for the traditional use of #define as well as making the removal of large sections of code.

Iron

yes, good to note, but there is other experience to be gained first for those not familiar already with run-time versus compile time coding

Iron

We're now on slide six.

Blogger

Good Morning from Sunny Sun Jose, CA.

It's 45°F now and a High of 71°F.

We are expecting Rain Tomorrow.

Iron

Intermediate to CPP Preprocessor commands.

Iron

CPP directives: average (?)

Iron

Average user of CPP directives

Iron

Improved code quality and stability

Reuse helps with an audit trail.

Iron

I guess the best benefit is to reuse code when switching to other platform (other MCU family)

Iron

1) Projects are finished faster.

2) When several active projects are using the same code, someone else will fix bugs in my project before I find them.

Iron

eliminate reinventing the wheel = $$ saved

 

Iron

We're now on slide five.

Blogger

@Rob Spiegel: My company allows gotomeeting, plus also classes that have presentation on web and phone audio. Thanks, Vince from coolish Sunnyvale.

Iron

For many of those whose companies block streaming audio can still play the archive. The archive will be available immediately after the audio portion of this program.

Blogger

It enables you to have a set of algorithyms whose implementation is documented and tested -- cuts development time.

Iron

Faster turn around.

 

Iron

quicker completion of projects

Iron

One of the benefits I've seen is that the code becomes more familiar, and therefore easier to understand and work with.

Iron

Code commonality,  Tested code that works.  Do not have to re invent,  can save time.

 

Iron

1. Save development time

2. Cut down on new code deliveries

3. Save on code testing time

Iron

Benefits: easy to maintain and shortens development time.

Iron

code reuse helps a lot in terms of development speed and efficiency

Iron

No policy to reuse - sorry!

Iron

One reason for re-use: Feature movement from one member of the product family to another.

Iron

The biggest benefit has been a decrease in development time for similar projects.

When it is well-written code, it of course makes future dev faster.

 

Iron

Maintainability and shorter time to market

 

We're now on slide three.

Blogger

If your company has guest wireless, they may let you audio stream through that.

Iron

Or use it as an excuse to work from home

We're now on slide two.

Blogger

Well, it looks like my company still hasn't unblocked the audio.  I will listen to the recorded audio. :-(

Iron

If you're having trouble with audio, try refreshing you browser. Or, try using Chrome or Firefox.

Blogger

Hello from Massachusetts

Iron

Did anybody check out the slides for today? Some of the "sins" documented...heh The people at my company have seen a lot of these during our history...but we are learning!

"Experience keeps a dear school, but a fool will learn in no other." -- Benjamin Franklin

Mea culpa!

Iron

Illinois checking in again. Howdy.

@marlowg except that they ask questions during the session and you miss out participating

 

Iron

Awrite! Looking at the slides, Lots of good detail today...

Iron

Hey from Hayward Wisconsin

Iron

@marlowg Same here, but I log into a guest wi-fi with unblocked streaming and use another laptop and get the audio that way.

Iron

Certificates will be available to participants at the end of the semester.

Blogger

Hello from Portland, Oregon. My company blocks the live streaming audio, but I can listen to the replay so all is good :)

 

Iron

Hello from Columbus OH

Iron

void good_day() {

    // good day, everyone, from edmonton, ab!

}

Iron

@bobymacs: I was just wondering how to "game" the system to enhance the odds. Is it signing up, logging in, chatting, etc.. as the gating criteria. I seldom win anything but they offer the enticement for some reason.

hello all from Edmonton, AB

Iron

This has been a great week for this class. We have had a large number of participants.

Blogger

Hello from Waterloo, ON, Canada

@bitbanger55: I don't know how and I thought to ask the same question :), but if I win it I would love to donate it to someone 

Iron

ready for a good presentation

 

Iron

I see the crowd is in good spirits today.

Iron

Good afternoon, everyone

Iron

the farmer dreaded the day his daughter would go beau hunting

Iron

How to win the Sbux gift card ? Anyone know ?

Hello from Huntsville, Al

Iron

@Kentj: Did you hear that people laughed at the guy who tied bows on Christmas presents so he quit? He couldn't take the ribbon.

Iron

@Kentj: Instead of bow hunting, you could sing a song on stage and then afterwards, while they're applauding, take a bow.

Iron

Morning! from Richmond, BC

Iron

@Kentj: Hey, I went bow hunting once too. I went bow hunting in the local clothing store and found all sorts of bow ties to select from.

Iron

Yes it's a problem to get questions answered immediately if you can't listen live. However, you can send me an email anytime you want with questions. Look on slide 1 for my email address.

Iron

Good afternoon from Milwaukee

Iron

Hello from sunny San Diego!

Hellow everybody,

I am here. How to write the reusable cod is my attention.

Iron

Greetings again from Illinois, all.

I went bow hunting in a mountain by Albuquerque once.  I shot a bow and killed it.  we were eating bow for weeks.

Iron

Hello from Rockwell Automation in Mayfield Hts. Ohio!

The problem with viewing an archived file is you don't get your questions answered.

Iron

Welcome from Albuquerque, New Mexico.

Blogger

Hey Paul S., I'll check into using a phone connection. Many participants who work at companies that block streaming can play the program when it's archived (just a few minutes after the program is over).

Blogger

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

Blogger

@JCheetham that's usually a buffer problem.  Can you try a different browser?  Or a different computer later today and view the archived file?  I ended up switching computers and it works great now.

Iron

-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

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

Blogger

Hello from Eastern MA. Nice, in the 40's.

Iron

I had audio problems that last two days.  The audio randomly pauses and I need to click on the play button to restart it.

Iron

It's a cool 55 here in Richmond, TX.

Iron

Hi from Sunny cool Boston!

Iron

Good (period of time of day) everyone!  I'm getting about as much out of this weeks lectures as I did the first ones last semester.  And that's a lot!

Iron

Good Morning from Sunny Sun Jose, CA.

It's 45°F now and a High of 71°F.

We are expecting Rain Tomorrow.

Iron

Anyone have spare coffee in the coffee maker?

Iron

Another day, another download.

Ooooh everyone is checking in early today.

Iron

Please consider having the audio for these sessions available by phone. It's too difficult to get our IT to unblock the audio streaming site.

Iron

Looking forward to attending today's class

Iron


Partner Zone
Latest Analysis
It's been two years since the Mac Mini's last appearance on iFixit's teardown table, but a newly revised version joins Apple's lineup this week.
More often than not, with the purchase of a sports car comes the sacrifice of any sort of utility. In other words, you can forget about a large trunk, extra seats for the kids, and more importantly driving in snowy (or inclement) weather. But what if there was a vehicle that offered the best of both worlds; great handling and practicality?
Kevin Gautier of Formlabs describes the making of a carbon fiber mold for an intake manifold, using a $3,300 3D printer, during Medical Design & Manufacturing Midwest.
Science fiction author Isaac Asimov may have the best rules for effective brainstorming and creativity. His never-before-published essay, "On Creativity," recently made it to the Web pages of MIT Technology Review.
Much has been made over the potentially dangerous flammability of lithium-ion batteries after major companies like Boeing, Sony, and Tesla have grappled with well-publicized battery fires. Researchers at Stanford University may have come up with a solution to this problem with a smart sensor for lithium-ion batteries that provides a warning if the battery is about to overheat or catch fire.
More:Blogs|News
Design News Webinar Series
10/7/2014 8:00 a.m. California / 11:00 a.m. New York
9/25/2014 11:00 a.m. California / 2:00 p.m. New York
9/10/2014 11:00 a.m. California / 2:00 p.m. New York
7/23/2014 11:00 a.m. California / 2:00 p.m. New York
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Oct 20 - 24, How to Design & Build an Embedded Web Server: An Embedded TCP/IP Tutorial
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6


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: 10/28-10/30 11:00 AM
Sponsored by Stratasys
Next Class: 10/28-10/30 2:00 PM
Sponsored by Gates Corporation
Next Class: 11/11-11/13 2:00 PM
Sponsored by Littelfuse
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service