@FrodoH - I believe a POSIX pthreads implementation must support mutexes to be POSIX compliant, but do all embedded system vendors implement? Unsure. (Your mileage may vary...) Do your homework to be sure the selected vendor's product supports your requirements.
i have always wanted some plug in to the IDE or even an external piece of application that draws all the dependencies into different types of graphs, but there seem to be little thats free to use out there, do any of you use such a tool?
micgil2293: Drivers are part of the code that is not reusable if the hardware changes. However, the driver API's should be set up so that if the hardware changes, only the driver code has to be updated; the application code can remain relatively unchanged.
A big problem using global variables is a lack of control over assignment of values that are outside limits. If an out of bounds value is detected, it can be difficult to identify the culprit. Also multiple variables for one purpose can be written by multiple sections, with the result that the resulting operation is not correct for any.
George Mallard: Global variables are bad because they can make reading another person's code difficult and can make debugging hard; it can be hard to track down every location where a global variable is changed. They also tend to lead to spaghetti code.
I like to understand every line of code but its not really necessary. The more your know about the program the easier it can be to debug, but in order to use the code properly it isnt necessary to know exactly what every line does.
@George Mallard, my experience is that you might inadvertently access a variable that was set in another module or a library. Also, it is hard to debug if you have to search many modules to figure out where a var got set.
Agree with others - the goal of reusable code is admirable, but may be difficult to achieve, particularly as hardware advances outpace product development/product lifecycles. (ie. - Marketing: What's the newest "thingy" available? We want that in our product. Engineering: We'd have to start all over to use it!)
On large projects it would be impossible to understand every line of code. You just need to understand the API's of the modules you interact with and only learn the details of other code if wierd behaviour occurs.
You don't need to understand EVERY line of code; that would take "forever" to be able to do anything. You don't need to understand internal combustion to drive a car or change the oil. You don't need to understand EVERY transistor in an I.C. to use it in a circuit.
You need to understand the major components and how they interface. To work within a component, more detailed understanding is required.
@Jacob Exactly what percent of code would you expect to be reusable? In my experience (outside of software that spans a specific product family which is actually a single code base) very little code is reusable due to changes in hardware and feature set requirements.
Feature creep - absolutely. And it is not just a technical problem but a "managing your manager" problem. Management wants you to be agile but unless you manage them they will abuse that agility to ruin your life with feature creep and indecision.
You have to be sure that your chosen platform can support feature creep without making you scrap the board or operating system. Be sure your vendor can upgrade the chip without invalidating your development to date.
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 or Chrome as your browser. Many people experience issues with IE. 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.
The streaming audio player will appear on this web page when the show starts at 2 PM Eastern time 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. If that doesn't work, try using Firefox or Google Chrome as your browser. Some users experience audio interruptions with IE. If that doesn't work, the class will be archived immediately following our live taping.
@Dennis Kong: File is ok. I ALWAYS have to download twice for some reason, overwriting the second time. Check the size. When I do it, the first time is always very small, and the second time much larger (1402KB today).
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
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.