but the header files may.. go across bounds.. that is sometimes like on my nav unit (hardware) hanging on two the ardunio which then hang off the the IOP or I/O proccessor which can handle multiple ardunio(s) and talks to the NavBus via ethernet.. at the other end of that pipe is the simcpu and that talks to the other IOP(s) broadcast a frame every 1/100 sec..

@aalbashar, We do a hybrid of both and put header and C file in the same folder unless the header has an interface (i.e. extern) to the outside world beyond the scope of its matching .c file. For example, if we write a SPI driver, things that the SPI or other hardware need are in the "local" .h file. (The SPI driver may be multiple files, for example.) But if there are functions that you can call from your application, those are separated out into .h file in a different folder. That way you could compile the driver into a library and just have this one folder to find .h files for your application.

Don't know if that's a great way to do it, but it's what we've started doing and so far, so good.

I'm with @garysxt, I'd love to figure out how to really pull off unit tests in an embedded environment. It seems like everything is so close to the metal that your test environemtn has to basically be a simultor for your whole HW stack

Question: What do you think is the most important aspect of software construction?

Having "inherited" 10 year old code in a maintenance project (off a CVS server, no designer still in the company) and having to add functions into it, I have to say documentation / explanations. Sure, there were comments, but it's like guessing you're doing a spaghetti sauce from the ingredients !

@Jacob (& all) : do you CVS all your design documents with the code ? Put all in a .zip file (i.e. .doc, .xls, state diagrams, .ppt, .pdf) ? Do you (can you) take time to explain how to read the doc to understand your architecting ?

EmbedXControls I try to use a standard API or HAL. Most MCU peripherals have common features that would be used from one application to the next so I have a HAL I use which allows me to abstract out how the hardware works in the design stage. Then when I construct I dig into the details. There are always a few gotchas that require updates to the architecture and design. Remember that it is a two way path. Architecture feeds design but design does push back on the architecture.

Jacob, One problem I found in Embedded Software Projects is One cannot fully do the design of software unless the full understaning of Hardware interfacing is fully understood and 3rd party libraries and driver interfacing is understood.

Do you recommend a way to easily First Design Embedded Software before reading all the 100's of Hardware Data Sheets and Library Manuals ? Or there is not easy way out of it ?

DJack, I've looked at TDD and read James Grennings book on it. I'm excited about it but I've found it difficult to implement in my design cycle. It is a very unique way to design things and I struggle with certain aspects myself on it. I haven't totally bought into it yet but I see where it could be useful.

I don't have any tools that I use for Tip #2. This is an area that I'm working on learning more about and that I personally have ignored. I bring it up even as a tip for myself that I need to design with security in mind.

EmbedXControls - do you know you are moving to an RTOS and which one prior to bare metal coding? If so I have created a RTOS abstraction layer in the past adn coded to that which alloed the RTOS to be added later if needed.

EmbedXControl s, if you write modular code then whether you are using a bare metal round robin loop you should be able to still transfer that modular code to an RTOS based system without much more effort

@Jacob: Have you seen or do you know if those whose use an agile development technique use flowcharting? I've seen scrums of two weeks for a major SW drop and there doesnt seem to be time for flowcharting.

We use modular concepts. This has shown to increase productivity, and reduce bugs. Reuse has not been a big issue as when a new project happens we use the opportunity to learn from our mistakes and revap the whole structure. The biggest problem with being modular is lose of speed. Currently we are not pushing the hardware limits so it is not an issue.

Q.Do you use modular software design techniques? If so what are some of the benefits you've seen? Disadvantages?A.yes i do.i work with different sensors and interfaces so using modular software techniques allow me to organize my code and to add more devices to my platform and reusing old code.disadvantages: more planning, more code.

So, what about peer code reviews, static analysis, and/or test driven development? These three practices are some of the best practices during the coding phase that have excellent payback later in the lifecycle.

We're curently using various abstraction layers. The main benfit is a common point for various formulas and calculations etc. Thi disadvantage that I've observed is things tend to morph as you go through layers. That means it can be unclear what a function actually does!

Yes modular. Disadvantages can be code and schedule bloat if done inappropriately (see the object-oriented toaster story for an extreme example). Many many advantages, ease of use, keeps you from going crazy if you have more than a few functions etc., and many many other

Just making the transition to modular programming as I get a bit more experience under my belt and learn more. Love the reusability aspect. To get started in embedded programming, though, I was a typical "single lump file" programmer.

we use modular software design techniques. advantage is that some components can be reused. we used to have completely different architecture from product to product. recently we have gone to an evolutionary release process.

@jtarbotton: there's lint of various sorts, which I haven't tried, and also Understand by Scitools which I've used their demo - very powerful and very handy, much more than metrics, it will generate all kinds of graphs and diagrams of relations between files, where variables are used, etc. etc.

I don't keep track of the process other than to turn out a functioning product. The first nonfunctioning stub version of the code contains modules for all the features. The modules are worked on one at a time using test data until the project is complete. So completing the modules would be the closest to progress tracking that I use.

I personally disagree with using the nuber of lines of code as a metric. A single line to do a lot, but make it unreadable or difficult ot understand. For those that use the number of lines how do you avoid this problem?

I personally utilize cyclomatic complexity - particularly if I am reusing code from on older codebase. I have found functions with numbers as large as 70. I like to use that metric for code reviews as well.

If I can make a logistical suggestion - I appreciate the "connect to Outlook" feature with the downloadable calendar thing. But can you set that up with a default reminder, say 15 min before? I almost missed today!

Hi all -Audio is live! If you don't see the audio bar at the top of the screen, please refresh your browser. It may take a couple tries. When you see the audio bar, hit the play button. If you experience audio interruptions and are using IE, try using FF. Also, make sure your flash player is updated with the current version. Some companies block live audio streams, so if that is the case for your company, the class will be archived on this page immediately following the class and you can listen then. People don't experience any issues with the audio for the archived version.

You are eligible to earn IEEE Professional Development Hours by attending these courses and participating in the chat function. Additionally, we are no longer using the points system, offering "graduation", or giving grades. The IEEE hours are taking the place of that. There are some important things for you to know about earning the hours. The most important ones are that you need to attend these courses live, you need to attend a minimum of two of them per semester, you need to fill out a course evaluation form within 2 weeks of the end of the class, you need to attend 4 out of the 5 classes per course, and you need to participate in the chat function every day you attend. Please click on the link at the top of this page that says "How do I earn IEEE professional development hours" to read all of these important details and more.

Please join our Digi-Key Continuing Education Center LinkedIn Group at http://linkd.in/yoNGeY and be sure to follow @designnews and @DigiKeyCEC on Twitter for the latest class information. We encourage you to tweet about today's class using #DigiKeyCEC.

The streaming audio player will appear at the top of this web page when the show starts at 2 PM Eastern time today. When you see it, click on the play button to start the audio. Note however, that some companies block live audio streams. If when the show starts, the audio bar doesn't appear or you don't hear any audio, try refreshing your browser. If that doesn't work, try using Firefox or Google Chrome as your browser. Some users experience audio interruptions with IE. Also, make sure your flash player is updated with the current version. If that doesn't work, the class will be archived immediately following our live taping. You shouldn't experience any problems with the audio when listening on-demand.

Industrial workplaces are governed by OSHA rules, but this isn’t to say that rules are always followed. While injuries happen on production floors for a variety of reasons, of the top 10 OSHA rules that are most often ignored in industrial settings, two directly involve machine design: lockout/tagout procedures (LO/TO) and machine guarding.

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.