krwada

image
President

I am a embedded systems consultant in Silicon Valley California.

krwada

's contributions
Articles
Comments
    • Many thanks for sharing your articles Aubrey! You give an excellent overview of temperature measurement at Planet Analog. And yes; Figure 2 does reduce the amount of resistance shift that the ADC can capture. I posted this figure because this is the most common circuit configuration I have seen in my travels. Almost everyone uses this circuit. Just because everyone does something a certain way ... does not always mean that it is the optimal way to do it.

    • All great comments here. And yes David... I do very much enjoy reading your contributions here at Embedded.com. And, I will be following up this article with another how-to with a bit more in-depth detail about thermistors. There will also be articles, in the future, with using I2C sensors and other such devices... and all of this using cheap resource constrained u-controllers too.. I will also talk about look-up tables, interpolation tables ... there are a lot of things we do and use in this industry that needs to be posted, discussed and talked about. Thanks; Ken

    • I agree ... doing this in C++ is superior in every way. However; I am attempting to reach the widest possible audience with these articles. Therefore, the use of C instead of C++. And yes, using templates is indeed the better way to go! Maybe, in a set of future articles I will discuss how to do these constructs using C++. Doing this will show how C++ and templates can really solve these problems in a more efficient and less risks of bugs fashion.

    • You can download the ARM Cortex M3 technical reference manual here: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337e/DDI0337E_cortex_m3_r1p1_trm.pdf

    • Hello Toinhatminh; Yes, you are correct on both counts. As to the reload; page 8-10 of the ARM Cortex M3 Technical Reference Manual states that the SYSTICK reload is a 24-bit field in a 32-bit register. The upper 8-bits are reserved. In general, it is good practice, or required to write zeros(0) to the reserved bits. This is the reason for using a 24-bit mask. This ensures that the reserved bits are always set to zero.

    • I have many clients who do both as you suggest. The combined solution works extremely well. I also have clients who do not want to add an extra penny if they can help it ... for this, you need some kind of software filter.

    • It really depends on the processor that you use. On some processors, if you use the int type and the integer native is 16-bits, and the processor happens to be an 8-bit machine, then the index update is not atomic at all. The best way to figure this out is to use the diss-assembly switch on your compiler to see if you need this. As with all things embedded, one cannot assume anything. Also, one cannot generalize ... like I just did. Pre-emption is a seriously tricky business ... especially with drivers and with queues. Most of the fixes I have implemented on device drivers usually in the arena of pre-emption and protection. This is where most of the problems occur. It is also extremely difficult to debug problems like this. When I am debugging some drivers that were not written by me, this is usually the very first place I look. Also, I must admit, I have made a few mistakes here in the past too. Heck ... I know I can start another topic on pre-emption and protection ... and I can guarantee that there will be a ton of criticisms and comments on this too!

    • All good comments here. Indeed, the code example I presented has a read-modify-write variable. It is important to protect fields such as this by making the modify process atomic in nature. I did not show how to do this in this example because the implementation of making this atomic is, in general, very dependent on the operating system / hardware used. In general, the modification does need to be protected. This is typically done by some form of suspending the matching interrupt service routine. Also, the indexes need to be protected too.

    • Hello Lundin; Yes, I think I did misunderstand what you meant. So, in your proposal, the struct definition would be hidden. How would the function call in C be implemented ... without an object that is? Would all the instances be carried in the C source file?

    • Sorry about the long delay getting back to you. When you say static analysis tools ... Do you mean lint? ... or are you referring to something like Coverity?

    • Again ... I forgot to add: You need to instance an XPTIMER object, then use it on the function with a cast. For example: XPTIMER my_xptimer01; void main (void) { . some code ... . . XPTIMER_update ((GPTIMER *)&my_xptimer01); }

    • I stated pointer to a parent. I meant to say is a pointer to the broker that 'owns' or manages the instance of a timer object.

    • Dang! I did not know that embedded.com will list the comments in latest 1st. I should have reversed my replies. I will do so next time. You will need to read my replies in reverse order. Sorry!

    • This is the beauty of unsigned arithmetic. When you do unsigned arithmetic, the carry bit is virtual. You can treat the carry bit as much as one would do using a half-adder. Here is an example using 8-bit unsigned arithmetic CURRENT_COUNT = 0xFE CAPTURE_COUNT = 0xFE ... some time later ... CURRENT_COUNT = 0x02 Now for some unsigned arithmetic: CURRENT_COUNT - CAPTURE_COUNT = 0x02 - 0xFE = 0x04 Now, if we had the carry bit it really is: CURRENT_COUNT - CAPTURE_COUNT = 0x102 - 0xFE = 0x04 In short, you do not need to worry about rollover. Now, if you do a double rollover, then you will have problems. As to atomic? Yes, the capturing of the system counter needs to be atomic in nature. Or at least, if you are using an 8-bit machine, and the counter is 32-bits, you need to make sure that the count value is correct at the time of capture. This is not so if you are using a 32-bit machine, where updates to 32-bits are generally atomic. The way to solve this problem may be as follows: 1. Disabling / re-enabling interrupts during capture ... (not so good) 2. Using a SWI (software interrupt) service to fetch the counter ... (better, but not all processors support this) 3. Capture and compare the system counter variable and use if the variable is table e.g. extern volatile unsigned long sysTickCounter; unsigned long my_captureTicks; do { my_captureTicks = sysTickCounter; } while (my_captureTicks != sysTickCounter); provided that the conditional test executes faster than sysTickCounter, then this capture / test should work.

    • "One could perhaps make the callback function pointer as an optional parameter: if it is NULL, the code will rely on polling, if it is set, it will be interrupt driven." Yes, I do this all the time. This is very similar to the "default argument" that one finds in C++. This is a very useful idea. As to nit-picking ... You are quite correct. The ISO behavior is undefined. I did the include path containing "h\includeFile.h" primarily to indicate to me that the file is to be found in the common header repository, that is local to a specific project. Again, laziness on my part. I keep forgetting where all the headers are, and invariably wind up looking in all the wrong places!

    • The danger of opaqueness in C is that there is no strict typesafe mechanisms in C as in C++. C is a bit more 'wild and wooly' when compared with the more formal C++ ... in my opinion, this gives C a more low-level feel to coding than C++. That is NOT to say that you cannot design tight C++ applications. Properly designed and written C++ constructs can and do consume few resources. C++, in my opinion, is a bit more rigorous, and safer to use in this respect.

    • As an extra note on opaqueness. Yes, I have used opaqueness on several of my C projects. Usually this is how I do it; (this appears to have met some acceptance, and not generated too many complaints). 1. Define a core enapsulation that has everything public and accesible. (this is NOT opaque) 2. Extend the core to another enapsulation by nesting the core inside the extended object, (class derivation) For example: //// parent class typedef struct GPTIMER { unsigned long lastCount; /* Last saved count for this timer */ unsigned long timeOut; /* Number of tics to timeout */ unsigned char timedOut; /* time-out status */ } GPTIMER; //// child class typedef struct XPTIMER { GPTIMER parent; /* define the parent here and make it the 1st record! */ int hold; /* when set, puts timer in hold mode */ unsigned long holdcount; /* hold dwell count to hold off this extended timer */ int alarmBit; /* some flag that is used to signal an alarm */ } XPTIMER; ///// now, on to the implementation of XPTIMER int XPTIMER_checkAlarmBit (GPTIMER *_this); /* check whether the alarm bit is set */ void XPTIMER_clearAlarmBit (GPTIMER *_this); /* clear the alarm bit */ void XPTIMER_setHoldCount (GPTIMER *_this, const unsigned long count); void XPTIMER_holdEnable (GPTIMER *_this, const int enable); void XPTIMER_update (GPTIMER *_this); /* update to refresh the alarm state */ As you can see here, the XPTIMER extensions are opaque to the user. The implementor of the XPTIMER encapsulation has hidden the details to the user / developer. Either it works properly, or it does not ... all without the risk of anyone 'fooling' around with the class extensions.

    • "... "opaque type" (formally: "incomplete type"), where the contents of the struct are truly unknown to the caller, and thus inaccessible." Yes, in my original implementation of the GPTIMER encapsulation, I declared the 1st pointer in all my functions as (void *). This did alot to hide the details of implementation to the engineers using this ... However, this being 'C", the 1st question I got asked was "Why do you hide the details when I have to instance a GPTIMER anyway?". The main reason why I abandoned the opaque-ness however was again, due to my sheer laziness as an implementer. I really like having the cursor slide-over popup window and the object search field completion box popup help me when I am attempting to modify the core implementation. Again, it is my laziness that won out, and got me to abandon opaqueness ... plus, I got a lot of complaints from my clients about the opaqueness. Plus, I am a big proponent of 'type safeness'. I got this habit of being typesafe everywhere when I jumped onto the C++ bandwagon many years ago. Being typesafe is a good thing ... but then again, that is just my opinion. I have debugged too many things where the (void *) pointer was seriously being misused.

    • "A more realistic risk is that the caller misunderstands the implementation, since the struct implementation is available, and therefore performs direct access to the struct members." This is one of the things that Stroustrup considered when he created C++. C, inevitably has this 'feature'. This is deeply embedded in 'C' the language. You cannot avoid this. Did you know? Stroustrup originally designed C++ to be implemented on embedded systems? In his view, all computing systems are embedded in nature ... which, in my opinion, they are.

    • I love LINUX and what it can do ... I hate its documentation ... which is pretty much nonexistent. Even the HOWTO on the Internet for Linux is well ... weak. "Especially if the code is designed so that one software timer equals one hardware timer. For example one could declare a static memory pool of 10 timers, and keep track of how many that are used through a simple integer counter." The simplistic, bonehead skeleton that I presented can be readily extended to accommodate your idea. In fact, one could very easily create an extension to the core encapsulation that allows for a single hardware to software timer binding. Also, someone can readily declare a static memory pool of a fixed number of timers and manage them using a broker. In this case, I would add a pointer to a parent inside the GPTIMER struct, (of course you would need to do a forward declaration here ... to all you purists, this tends to be a no-no!!) This way, each instance of the GPTIMER object can have access to its specific parent, (in this case a POINTER to a parent), for any extra special "hacking" ... er ... processing.

    • (A note: I tried to reply all in one comment, but the website bars me from posting anything with more than 2000 words!) "From a "get-it-done" perspective, this code is just fine" That is a great compliment! All of my clients expect this of me ... especially if the one who signs off on my invoice is a suit. "... but from an OO perspective it is naive" You are being diplmatic here. The term I would have preferred is bonehead. Most of the stuff I come up with is minimalist in design. I suppose this has to do with my penchant for laziness. I try and come up with the minimal amount of work to get the maximum result ... and still be extensible to boot. I try to come up with ideas that will save me time now, and save me time later. "Which means that source code documentation in comments, describing how the timer should be used, is absolutely necessary" In my domain, source code documentation ... actually ... meaningful source code documentation is mandatory. All of my clients expect this of me. This is because many engineers will, and usually build on top of the stuff I create. Actually, meaningful source code documentation should be obligatory.

    • Intel just announced today, 17-January-2013 that they expect to spend $2b over what was expected. According to the press release, this appears as if a foundry ramp is imminent. http://www.marketwatch.com/story/intel-results-beat-street-but-outlook-weak-2013-01-17?dist=tbeforebell Well ... It is imminent! We shall see whether or not I am blowing hot air, or whether this really happens later this year.

    • Oops! in my haste, I forgot to add the volatile keyword on that darned global variable. It should be: volatile unsigned long my_system_tick; Sorry!

    • I would say that my top pick out of this list is the Linear Technology wireless mesh RADIO module. I get a lot of inquiries from folks who want to do any one of the following: 1. Enable Internet on their projects 2. Enable wireless on their projects 3. Enable both Internet AND wireless on their projects When I look into this, I find that usually the access problem is solved as part of a system solution. I really like the Linear Technology solution because: 1. It is LTC after all, and LTC really has a great track record of quality products at a very good price point. 2. The LTC solution is based on Chris Pister's DUST technology. As far as power consumption, DUST is pretty darned good. That is not to say that Texas Instruments should not be looked at. Zigbee is very good, and the TI solutions are also very good. Here is a picture of the Linear Technology low power MESH module http://cds.linear.com/images/product/4618_pack_1.jpg

    • I would like to hear from Andrew Frame. Andrew is the CPU product manager at ARM Holdings LTD. http://forums.arm.com/index.php?/user/104898-andrew-frame/ Either Andrew, or the current product manager of Android at Google.

    • How about using that same timer ISR to pet a watchdog ... while blinking that LED? Haw! I have seen it happen! All seems to be well, whilst the code is in a deep coma.

    • At the price points you talk about; it may be possible to have multiple units available for the embedded developers to use. Then, to have more expensive desktop units shared for more demanding applications. I need to look into the Cleverscope. Thanks!

    • A Bitscope and Cleverscope MSO? I have never heard of these. Being that these devices are USB based would probably make them pretty economical?

    • The MSO is indeed a fantastic tool. Too many times, management requires us to make a choice between a DSO and an MSO. Too many times; management is under this strange impression that these two tools are identical. Go figure!

    • Why are we talking about ADA? Perhaps we could talk about embedded COBOL no? Don't mind me ... I am being a cranky cynic here. Yes, ADA is a decent language. The usage is not very widespread however. Heck, I even know a few rabid FORTH developers out there. I was a Crystal FORTH addict at one time. That was awhile ago however. Heh!

    • I much prefer .... "Do epic scatological doo doo!" Hey ... that sound bite matches my old avatar photo ... too bad that I now post pics of my real self ... Oh well!

    • "If you think this is confusing, wait until you get a chance to work on 16-bit targets with a segmented address space..." Intel 16-bit segment thread drift .... Yaay!

    • It may be better to just unwind some of those expressions. It is much better to get a predictable and reliable result than to have 'elegant' code. The end user really does not give two hoots about how the code looks on the inside. What they do care about is whether or not that black box does what it is supposed to do ... or not do what is unexpected!

    • I like the data sheets the way they currently are. If more is needed, then we already have the repository of app-notes, users manuals and all the other collateral that is needed for a successful design. You said: "We’re desperate for vendor-supplied code (which, all too often, looks great at first but is crap in a real application)." I say ... That looks a lot like the "crap-to-market" that we are constantly struggling with nowadays right? Heh!

    • Implementing polymorphism has advantages. Sometimes; you have no options other than to implement polymorphism in C because there is no C++ cross compiler available for your processor. In my opinion ... the lack of availability of a C++ compiler appears to be a pretty decent argument for why NOT to implement this in C++, and to implement this in C.

    • There are lots of opinions here. I write polymorphic C all the time. This is the way I can port drivers across multiple platforms and hardware configurations. I even have some constructs that implement a very crude RTTI model. It all works, and most importantly, saves me a ton of time when I want to reuse something from some other project. It makes new projects with slightly different hardware much less error-prone and easier to code. ... but this is just my opinion!

    • So ... if embedded software is so good, and is of such high quality... 1. Why does my TV set-top box crash after just leaving it on for a week or so? 2. Why do I have to remove the battery from my cell phone after a month or so; so that I can reboot it? 3. Why is it that one of the 1st things I have to do to trouble-shoot just about any thing is to cycle power ... which is just another way to reboot the firmware? There are a ton of devices where the instruction manual says the 1st thing to do in case of malfunction is to remove and re-install the battery. We all know that what you are really doing is simply rebooting the firmware on that device no?

    • Andyzg: "i would prefer to receive well documented and well tested, proven binaries" Those days are indeed very long gone. There was a time when stuff like this was done however ... no more!

    • At the end of the day ... most folks only care about the following: How do I get accuracy, stability and reasonable response using a type-2 controller, (control loop with feedback and integrator)? I have seen tons of ways that people have gotten there. Some are good ... some are really not so good.

    • Since most documentation is non-existent or just purely crappy ... Plus, the fact that most embedded engineers take to the RTFC, (Read The Frikkin' Code). It seems that there is no recourse other than to have the source code at hand to really understand how to use the stuff. Indeed, reading undocumented, or (worse) ill-documented source code is wasteful and a royal pain. However, someone has to do it if you want a decent result nowadays! What is even worse is to be handed a set of binaries that are compiled on a tool that is different than the one you are currently using. This ... plus the hassle of downgrading to the correct compiler version ... ONLY to find that the code, (in binary form), still does not work!!!

    • So ... I know that polymorphic classes have a vptr embedded in them. I also know about the vtable too. I always wondered where the vtable is located. I suppose it really depends on the compiler vendor no? As to abstract classes, my opinion is that there are no really hard and fast rules here. Abstract classes, in their own right, are extremely powerful constructs. They also have this ability to be misused to a point where a lot of bad thing can happen in the system!

    • Let the market decide. I can suggest a few cases for thought. 1. I buy a multimeter, I expect it to be cheap, and to last a decade or so. I also expect to get absolutely zero support for it. 2. An FAE convinces me to purchase some test gear for $20k-$30k, including service contract. I expect this to last about as long as my relationship to the FAE, (maybe around 5 years or so) 3. I convince my team to use some really expensive test gear, or some large set of test gear. We cannot purchase the stuff outright. Therefore we rent the gear. If it don't work, we return the rental immediately and go rent something else

    • From what I can see here, there are two distinct camps at play. And I am not defining them in the 8/16 vs 32. The camps I see at play are the: DIY/student/hobbyist and the professional/commercial/profit camps. There also may be a fair amount of overlap between the two camps. I see the DIY/student/hobbyist benefiting with cheap low-end tools and 8-bit MCU's. The cost of tools and architecture complexity does not appear to be too much of a barrier to the professional camp. Therefore, I see price/performance and feature set dominating in the professional camp ... therefore the preeminence of the 32-bit MCU here. As to the 8/16-bit vs 32-bit pie fight? I refuse to get involved in that one because it totally misses the mark in my opinion. This is just my $0.02 anyhow.

    • Hoo boy ... The C vs. C++ falme! You really know how to stir things up Dan! (mispelling is intentional here)

    • Hey Jack; What about while(1)? I bet if you took a survey, you will find the vast majority of the embedded systems use the ubiquitous while(1) style of coding ... along with interrupt intensive device drivers. The big break in thinking comes when the managers believe they need a file system. Then we get to Linux, ThreadX, Nucleus .... etc. I believe, a long time ago, The EETIMES magazine made a prediction that vxWorks would eventually dominate the world ... only to be later taken over by Linux. In fact, Wind River is now an Intel corporation, and they mostly sell Linux based platforms. Some of my friends still use vxWorks still ... even though it is a very small minority right now.

    • How many graduate students does it take to screw in an algorithm? It depends on how many postdocs are present ... or maybe it is just a shade over 200???

    • I would not worry too much Jack. The very first application, and adopters of the fully autonomous vehicle systems will be in the commercial / industrial space. There will come a time, very soon, where the drivers of such vehicles will become merely operators of the vehicles and a safety backup in case something messes up.

    • It has been a long ride Jack. I believe the on-line www.embedded.com will be around for awhile. At least; I hope so.

    • I have had a few hobbies. One of them was the high power rocketry hobby. You can learn more about this fine hobby at the Tripoli website. www.tripoli.org I did a lot of stuff shooting 12-14 foot missiles out in the Black Rock Desert, or the Bonneville Salt Flats. This hobby can get pretty expensive. I even built a ton of stuff. Spread spectrum data comm links, radios, automated ignition controllers etc. Now, I just reload ammunition and shoot my guns. the shooting sports is just as dangerous as firing a missile I suppose. Shooting a rifle is a lot cheaper than lighting up a 50lb missile! However, just as in any hobby; Your hobby can certainly be a black sinkhole for money no? I have heard that the SAILING HOBBY is a perfectly fine black sink hole for money eh Jack???

    • Again ... another great article Dan. Even though it is not mandatory; I generally like declaring the virtual keyword for all of my derived classes. This allows anyone, who is looking at the code, to quickly see that the function is a virtual type. Also, I would have declared the 'shape' class to be abstract in nature. This would have been done by assigning your 'area' and 'perimeter' functions to zero(0). There are pluses and minus to this approach. Some developers do not like to be forced into defining a function in a derived class. In general, if I do not wish to have the function defined, then I will define it as some dummy function to fulfill the abstract base class derivation requirement.

    • What about the TTL, CMOS, OPAMP and 555 cookbooks? Those were great little books. I still have mine!

    • Hey Jack! How many resumes have you submitted in the last few years? Heh!

    • Yes, I know. I 'stole' a lot of ideas from the Linux source code for my own projects. With proper instantiation and function pointer usage, you can create 'C' objects that are much more powerful than anything you can do ... even more powerful than RTTI typing in C++

    • With virtual functions, and proper instantiation you do not need any isKindOf() operator to discriminate which parameters or functions to use. This is one of the most powerful underpinnings of the C++ language.

    • The hi-tech electronics industry gets us in both ways. As we get older, our ability to see fine detail gets weaker. As time moves on, the components that we need to see get smaller. There is no recompense... Oh well!

    • Inline or static inline is a great construct. The net result is very fast code that is checked during the build phase. Unfortunately, only C++ compilers have this construct. I am not aware of any C compilers with this feature.

    • This is a great article. Unfortunately, the majority of firmware engineers rely on the MACRO substitution technique. They tell me that function and class encapsulation is too slow. Too slow??? In this modern age of multi-mega-mips processors and gobs of memory, it is much better to use function and object encapsulation. It is much safer and less error-prone than the MACRO substitutions.

    • Hey Jack! Is this a rant? There is a very good reason why Apple does versus Android does. Apple only needs to concern with a SINGLE hardware platform. Whereas, the Android is very much like the PC. There are tons of hardware configurations and it is changing based on a community ... not just one company's vision. This, and there are other many reasons why Android, overall, dominates the handset and tablet space.

    • The Lifeboat 'C' compiler was the Lattice 'C' compiler. It was Microsoft's first 'C' compiler for MS-DOS based systems. The other compiler was the Whitesmiths 'C' compiler. This was used to compile and run CPM applications. This is a distant and ancient memory. Where did all that time go???

    • Then along comes the Zilog Z8, Intel 8048 & 8051, Motorola 6809. These architectures helped to define the modern era of micro-controllers. We called them 'kitchen-sink' microprocessors in the mid 1980's. I remember senior management in all the companies squirming to try NOT to embed these chips into their products. Now, I cannot imagine a world without them. There was no FLASH back then. Code was 'burned' onto the ubiquitous 25C256 and persistent data was managed via EEPROM. Also, I remember a ton of projects using the IBM-PC clones. You could go to the local electronic superstore, purchase a PC motherboard for around $500 and get a prototype up and running with MS-DOS 3.1 in about a week! Heck I remember using Microsoft's very first 'C' compiler. It was published by a company by the name of Lifeboat. It was the Lifeboat 'C' compiler. Back at that time, Microsoft only had a BASIC interpreter. I also used a ton of Borland products back then too. Borland, at that time, had only a PASCAL compiler. Keil was Franklin, IAR was Archimedes ... I suppose it is funny being one of those early pioneers in the embedded world. All that time, all I wanted to do was make stuff go!

    • Many years ago ... maybe it is not so many; this very publication predicted the pre-eminence of Wind River's VX WORKS operating system taking over the world! I see folks doing it again with another OS. While in fact, from what I can see, it is the stubborn entrenchment of while(1){} that has carried the day! Let us hear it for: while(1){}

    • So, who is the target audience of those Heathkits today? Will it be all of old geezers that grew up on them? They were a lot of fun to assemble. Another poster here talked about small computers not being able to talk octal. I remember programming a ton of DEC machines. All the DEC machines talked octal. But alas, the world is HEX today no?

    • I remember "cutting my teeth" on the original IBM-PC. Actually, I became a business consultant offering training on this new technology. I did this while a graduate student at UC Berkeley. Up to that time, I was working on all the DEC PDP variants and Digital Research CPM, (Godbout and Kaypro S-100 machines) and later the MPM abomination. Networking, at that time, consisted of the "very advanced" X.25 protocol and other variants ... mostly some form of protocol which used EIA-232 as the PHY layer. Also, I remember the only real way to get online was using the Wildcat BBS which used the Mustang server software. Back in those days, the Internet used ONLY the four-decimal nnn.nnn.nnn.nnn addressing system. Also, one had to log on to the FTP server using the PUBLIC subdirectory as the USER anonymous. I played a lot of CHESS and GO on those BBS's back in those days!

    • The short answer is you can't. I suppose it is these emotional intangibles that separate the great managers from just decent managers. I have heard of the 'divorce rate' metric. Usually, companies that use metrics like this also like to enforce a forced RIFF twice a year. The belief here is to instill the Fear component to motivate the work force. In all, most of this does not matter much to me. Money, is money ... and spends just as well if one earns it from a nice person ... or earns it from a not-so-nice person.

    • It is far easier to get a good result if your developers are excited and believe in what they are doing. I believe this is called "ownership" no?

    • The number of Compact Fluorescent Light bulbs CFL that I have gone through is way too many to count. CFL's made a lot of sense when they were higher priced and way more reliable. The cheap crappy junk that is sold nowadays just does not make any economic sense. All this, with a boat load of toxic mercury too! Fortunately, my local hardware store has a toxic waste return program in place. This way, we have a place to put our CFL's, NiCad and other stuff that can be recycled and not put into a landfill.

    • So Jack... It looks like you got the Sony Playstation-3 jitters too no? The biggest counterfeits that I see right now is in the FLASH memory arena. It is very difficult to trust any FLASH memory device nowadays.

    • Ummm... Jack, your 2nd example has a bug in it. int divide(int value1, value2) { if(value2!=0) return value1/value2; } If the if() conditional fails, then there is no return instruction! At this point, the value in the return register, or stack variable is undefined!

    • I was there ... Hey! I thought that dinosaur was some kind of ominous representation ... of the fate of us embedded engineers!

    • $79 for part time and $104 for full time? I would have thought that it would be the other way around. In other words, wouldn't there be a discount for a larger quantity of hours of service? Also, there are other forms of compensation than money. The other forms I am thinking of are: 1. Stock and options 2. Time off

    • Using a WDT as a last-gasp debugging tool is not a very good idea. For most deeply embedded systems; petting the dog as one of the processes in the infinite while(1) loop is OK. However, for systems that sport a full blown operating system, one has the issue of where to pet the DOG. In this case, the 'Deadman' idea that cdhmanning suggests is a very good idea. Basically, the idea is to use a very small non-preemptive timer service which continuously monitors the 'health' of all the threads and perhaps some critical code sections and maybe an ISR or two. This timer service will then POST a message and then do the self-induced deadly embrace which will then fire off the DOG. My clients and I have used the Deadman and it appears to work with pretty good effect. You can also add some fancy stuff to it like statistics, snapshots and such to allow the developers to figure out which code section misbehaved. In general, the fault usually does not lie with where the errant behavior occurred. Usually, something else in the system triggered the errant behavior.

    • These are admirable conditions. However, in the real world, things are a bit more gray than one would expect. 1. A requirement is unambiguous. OK ... unambiguous to the stake-holder(s) More often than not, the requirement is a derivative of many specification. What if one meets most of the specifications, and some are just darned near impossible to meet? Does one spend precious resources, miss time-to-market to get those specifications in-line? 2. A customer is willing to pay for it. Well, most marketing folks will tell you "If you only had this or ... that! Then I can get this customer to pay for it" ... aka Feature Creep! 3. Requirement testability ... we need to be careful here. I have seen many projects get torpedoed because we went overboard making certain all the tests passed ... only to find out later that we shot ourselves in the foot!

    • Oh noez! Photobucket . Jack ... you are quite correct. However, I must deal with the broken Engrish in the numerous tech-manuals and data sheets everyday. It just makes me want to cry out... You're Winner Heh!

    • My sincere condolences to you and your family Jack. Condolences . Losing a loved one really sucks ... no matter how one slices it.

    • Actually, code inspections are OK. However, the process as we know it definitely sucks ... and I mean big time. Too often, I get called in to do an inspection of another engineer's code; only to find that the process is reminiscent of the Spanish Inquisition for the poor programmer. . Photobucket . I have found that the better method is to have one engineer 'help' with the unit test of the critical code sections and to offer suggestions for improvements in the architecture / implementation.

    • So ... Jack ... You say: ... responses from ESD's readers are nearly always well-thought-out and polite. I cannot help but think that you say nearly always ... Perhaps I am one of those in the less than nearly category eh? Photobucket ALL HAIL COBOL! Heh! Congratulations Jack! I hope to see many more of your fine articles.

    • Nothing will happen until some kind of disaster occurs. Then, the reaction will be a huge 180 kneejerk reaction in the opposite direction. Thus is the state of human nature

    • Hello Jack; If you make $80k here in Silicon Valley ... well, let us say that you are not doing too well. The median price for a home in San Jose is $441k. If you wish to live in a bit nicer neighborhood, such as Campbell, the price rises to a cool $586k! You check the prices for yourself here Of course, if you wish to live in the more upscale neighborhoods, such as Saratoga, Palo Alto or Los Altos, then be prepared to pay over $1.5M for a house! I can tell you this. Even though it looks like we make gobs of money ... it all evens out by the cost of living to where we make this money.

    • Migrating away from C/C++ ??? As far as I can tell, the embedded community appears to have finally migrated away from Assembly! I know a few folks that would like to see embedded JAVA ... or FORTH! I have consulted with companies that have tried the real-time JAVA. All I can say, is if you do real-time JAVA, do expect to be patient... for you will have to wait a bit to get a result!

    • I have to side with GLink here on this one. There is this common misconception that full professors have the same work load as an HS Teacher, or Middle School Teacher. I have been through the Academic grist mill, and from what I have seen, the full professor of a name brand university, (Cal Tech, MIT, Berkeley), has about the same work load as a CEO of a small start up!

    • Hoo boy! This is one of the perils of embedded programming. There are so many ways to mess this up. And all of the ways use what appears to be reasonable code. A few things that have worked for me in the past: 1. If you use an OS; use the pre-existing OS services to solve the problem 2. If you do not use an OS; use whatever resources the hardware vendor gives you to solve the problem. So, in a nutshell: - Read the user's manual, examples, appnotes, anything you can get your hands on - See if the software user's manual has any instructions that will aid you in this. A good example is the swi instruction on the ARM7TDMI. - Learn the assembly language and check to see what the compiler is generating. - Make certain it works on paper before implementation begins - If possible, use a debugger and step through the atomic section to see if it does what you expect.

    • Larry Wall says it all...

      Virtues of a programmer 1. Laziness - The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. 2. Impatience - The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. 3. Hubris - Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience.

    • Pie Fight! ooohh! I loves the blogosphere pie fight. ok ... I will weigh in on this one. I did not take the test. I saw absolutely no need to. Whenever I interview a prospective client, if I get a quiz... that is my cue to head on out the door. For me, there are really a limited set of questions that need to be answered: 1. How much money does your idea make? 2. How quickly can we make the money? 3. What are the threats to making the money in this way? . ... well ... you get the idea. As to Q & A, what most interests me is how quickly can the engineer spot and fix the problems? I have seen some incredibly abhorrent code and constructs that appear to work fine! ... and told by senior executives to not touch a thing!!! After all ... most of the problems we fix are problems that were originally generated by ourselves. I call this the "Lassie Effect Photobucket It only took Lassie one episode to get herself into trouble. Then it takes a dozen or so episodes for her to get herself out of trouble! Heh!

    • I can clearly tell you this. It was this guy... stone knives and bearskins ... that was my inspiration when I was a child. Later on in life: - got my undergrad in Chemical Engineering - minor elective in solid state physics - got my graduate degree in Material Science - side elective in PhD program in control theory . ... let us say it was a long and very circuitous route to becoming an EE in the advanced broad band optical networks industry!

    • If one were to put range checking and exception handling in every single function ... I would hazard a guess that this would add at least 15-20% overhead in code size. For deeply embedded systems ... this may not be so good. What I have found however, is if we place exception handling at critical points: - Device drivers - User input - Network Management interfaces . ... We can get a much better leveraging of exception handling and range checking within these areas. Also, there may be times that MACRO substitutions such as ASSERT() may be a decent alternative. It is better to let the bugs surface during testing than to surface out in the field.

    • The stuff I worked on was way more advanced. Photobucket This doo-hickey was a mag-core from the venerable PDP-8 computer. The programming was done usinge a DEC Selenawriter printer interface and the program was punched on a paper tape! I did consult for a fellow that worked on a computer that had the cylindrical drums though!

    • Bowl of Spaghetti is the norm ... unfortunately! I have seen way too many instances of the son-of-BOS. son-of-BOS == modular coded BOS ... That is, you use a bunch of subroutines and compact them in a single BOS-type file!

    • No respect? Rodney Dangerfield Try asking a Liberal Arts Major if they get more or less respect in the US than an engineer or business major!

    • "Give the laziest man the hardest job, he'll find the easiest way of getting it done." - Anton Martin Sorenson - "A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering." - Freeman Dyson - "Beware of the software engineer carrying a screwdriver" - XTALK -

    • I can only speak for myself. My busy schedule means that I can ONLY spend one day at ESC. Usually, I spend ONLY one 1/2 day at the ESC in San Jose. Usually, it is on Wednesday afternoon. The things that virtual cannot do, which I really like: 1. Meet real people face-2-face 2. Browse, and let serendipity rule 3. Bump into folks ... like Jack Ganssle!

    • The assert() macro is good, and good to use. However, where does one "assert" to? In one of my recent projects, I wrote a complete post mortem analyzer. This thing did a complete stack trace, thread dump and a snap shot of all the interrupt service states. After the analyses, the analyzer would turn off all the interrupts and do direct writes to the terminal, and if available, to the FLASH drive. In this case; the ASSERT() macro did wonders for aiding the developers. Later, we conditionally removed the ASSERT() macro as one would expect to do ... Then we found some unexplained behavior out at the customer site. Needless to say, this product still has the ASSERT() macro enabled out in the field for all the units shipped! However ... in most cases, (using the roll-yer-own while(1) loop) There is no good place for the ASSERT() to go.

    • This is a good article. However; one of the main assumptions here is that people generally know what they want and are able to clearly and succinctly specify their desires. In reality, it is usually a bit more muddled.

    • (ARM == less performance) ??? I do not think so. The ARM architecture appears to be dominating the small device space ... by a pretty decent margin too!

    • Even though most engineers are happy doing R&D. I can say that it takes a lot of training just to get here! My instincts tell me that is what is keeping the younger folks from entering into this fine profession.

    • 99.9% ???? That is way to high a figure! According to the Boeing Corporation, There were approximately 18 million flights in the year 2000. Of these, only 20 resulted in fatal accidents. Of the 20, I am most certain only a very few were due to controller failure. Therefore, I would think something on the order of parts-per-million or parts-per-billions is a better metric. It is way way better to have folks not ever know what we do than otherwise ... in general, any publicity, in the general media, about embedded controllers is because of a failure. You can see the statistics ... provided by Boeing ... here ... or course The Boeing company will have a particular bias on the safety of flying.

    • Linux is OK. The part of Linux I really cannot stand is this "Linux Brotherhood" style of programming. If you are not part of the "Brotherhood" ... watch out! Also, the support is non-existent ... that is unless you call Google searches product support! Other than that, I have found Linux to be pretty decent for a wide range of really large projects.

    • There are many ways for an embedded system to go SNAFU! Anyone out there that can make claims to creating a perfect system on the 1st pass is ... well ... being disingenuous. However, this does not mean that it is OK to let stuff like this go. As we live in an age where lower cost is always better, and with the inexorable race to the bottom; more stuff like this will happen. It is a miracle that a lot of stuff out there works. The poor engineering that I have seen go into products is truly astonishing ... and it still appears to work! The big question I have is:

      Why does a low-tech device like a stove have a microprocessor in it???

    • To Kortuk; Come to Silicon Valley! There are tons of jobs for young engineers who want to get into hardware. Most notably: - Smartphone OS - Networking gear - Control systems for alternative energy - Sensors and sensor networks Silicon Valley includes the following municpalities: - San Jose, (heart of Silicon Valley) - Santa Clara - Sunnyvale - Mountain View - Campbell - Cupertino, (Home to Apple Computer) - Fremont, (Home to alternative energy) - Milpitas ... And of course, there are embedded jobs in the SF Bay penninsula. The places I am talking about are: - San Francisco - South San Francisco - Burlingame - San Mateo

    • ummm... Jack? At the last ESC show in Silicon Valley, most of the embedded engineers are old! The main problem we have here is that not many young engineers want to be in our field. The new age engineers most likely are at: - Google - Yahoo - Facebook - Apple . ... you get the idea!

    • so... Where did all the engineering jobs go? China? India? Walmart?

    • Some of the greatest engineers were also brilliant marketeers. Some names that come to mind are: - Thomas Edison - George Westinghouse - Harold Eugene Edgerton - Hiram Maxim - John Browning . ... just to name a few.

    • I can tell you this ... most ... actually, the majority of my consulting customers are, or have been start-ups at one time. Out of all of my customers, I can honestly say that only a handful have hit home runs, (less than five). This recession is very different from the others. What is currently different this time around is the fact that this one is a financial-led recession. That means there is very little speculative money out there to fund the start-up scene. My guess is that this will unfreeze when folks start realizing that there is still a ton of money out there that needs to be invested!

    • Hello Jack I can say this with certainty ... All computing systems are embedded The real time constraints lie primarily within the application. As I have stated before; if you include all those stand-alone desktop PC's that are supervising some test, or other 'shop floor' application, then the Microsoft Windows is still the King. However, I still see Linux as rising in pre-eminence in the not-to-distant future.

    • Hello Jack; you said:

      But I suspect that, in this country at least, the median age of engineers tends towards the gray side. Which is a darn shame, but that's a different topic.
      so... you finally admit that there are fewer young ones getting into our profession eh? Anyhow, I watched the lunar landing, and I was a mere lad of 11 years old. I watched it on a snowy black and white TV. Also, I used a Kueffel and Esser slide rule all throughout my High School years. My Mom purchased one of those HP-21 pocket calculators in the summer before I headed off to UC Berkeley ... 1975 was the 1st year the UC allowed the use of pocket calculators to be used int mid-term exams and finals. The professors still used slide rules then too! So ... did you use a slide rule??? Heh!

    • What? - no 5.25" floppies? - no 1/4" streaming tape backup? Actually, from what I can see, there is a pretty mixed up set of different ways that folks do backup nowadays. Personally, I use those USB flash drives to just backup the data. The corporations use something much more sophisticated ... I am certain of that!

    • You mean other than: 1. Developer's brain 2. Notepaper and pencil ... I suppose the following are pretty high: 1. Desktop PC 2. Cross compiler and debugger 3. Oscilloscope ... indeed, I suppose I am old school.

    • Any time off is good time! I do love what I do though. Consultants do not get any time off. Actually, any small business owner knows of this too.

    • Hello Jack; 1. A pseudo random number is only as good as its seed. There are ways to assure the seed is pretty darned good. 2. In order to get the encryption keys on the computer ... well, you need to be able to freeze spray the thing 1st! 3. I think the more compelling security threat lies with the weakness inherent with humans ... and unsecured WIFI signals! Heh!

    • ... Micron's web site requires an NDA to get a datasheet! Toshiba's site is nearly unusable, and directs datasheet inquiries to local sales reps. The web is all about making your product information widely available, not gating access through the slow and frustrating process of involving some sales guy.
      Amen to that brother! ok ... about NVRAM, or FLASH. I know of quite a few products out there that appear to be well beyong their life-cycle. The various vehicle sensors that are used in the toll roads back East, and bridges out West. I am talking about things such as FastPass, EZPass, Fastrack etc... How do I know? I am the dude that designed these systems. I can tell you that they all have non-volatile memory in them. NVRAM is a must-have for systems such as these. I have worried a little bit about the lifecycle retention .... nah! I really have not worried at all about them. I figure that most of the time, these systems are working 24-7, and if anything goes wrong, they usually have spares sitting in some shed that is close by. ... or something like that!

    • This is some interesting news. At first glance, it appears as if Intel is responding to the threat that ARM represents in the embedded space. However; Intel still has preeminence in the embedded space using Microsoft Windows. I know of a few engineers that may choke on this MS-Windows/Intel/embedded thing ... However, do not underestimate the power of Intel with Microsoft in the embedded arena! If one includes all the 'embedded' Labview applications out there ... then the dominant OS/uProcessor combination out there is Intel with Microsoft inside! ... indeed!

    • All this works fine ... if you have developers that work properly as a team! I worked on a project where I was the kernel dude. One day, I got the complaint that the HEAP was running out of memory and "could I do something about it". It turned out that we had 32M of memory allocated for the heap. One of the developers promptly allocated 31M of memory for a 'personal allocator' ... of which he was only using 200 kilobytes!!! Needless to say ... I got my 'big stick' of coding discipline out and started whacking away. Also, I told him that unless he released all those resources ... I was going to put his thread into the nether regions of the project and a very low priority! He complied after all the other developers got all over his case! The other developers were none too happy with what this fellow did. Eventually, I asked the rogue developer ... "Why allocate the 31M???". He said ... "I felt just in case I needed it!" Heh!

    • Jack... Dang! That is a lot of hand-wringing you are doing here. I suppose I may not be fair in my assessment since I do not get the volume and kinds of email you get. I can say this for sure. The dynamic for engineers is rapidly changing. Off-shoring is a force that cannot be stopped. Also, this recession like all things negative must pass ... just as kidney stones pass! There will be a fair amount of pain still to come though. My advice to most of the folks out there is to not attempt consulting if you have been laid-off. ... and this coming from me! who has made a career as a hi-tech consultant.

    • This is a great article about a pretty obscure, but nevertheless vital subject for embedded systems design. A few points here: Alignment is critical in DSP, (Digital Signal Processor) based systems. Most DSP's achieve 32-bit alignment by storing part of the word with the LSB=0, and storing the other pat with the LSB=1. The chip vendors do this to save on hardware I believe. In general, it is better to use "copy by value" instead of the older memcpy(). Here is an example, (works both in C and C++) typedef struct exampleStruct { unsigned char cv; unsigned int iv; void *ptr; } exampleStruct; extern exampleStruct *p_src; exampleStruct my_dst; memcpy memcpy (&my_dst, p_src, sizeof(exampleStruct)); Copy by value my_dst = *p_src; Even though both examples are equally valid, and produce the correct result; I believe the copy-by-value to be less prone for error, and 'inadvertent mistakes' by the programmer.

    • Jack ... as usual, a very fine commentary on the soup du jour! Anyhow, this agile programming looks very much like a rehash of extreme programming. One of the primary difficulties I have found with the XP approach is that it does not do well to keep making iterations on the code after the product starts shipping. There is a ton of stuff out there that pretty much has to work well over the expected lifespan of 8+ years! I think one needs to make sure that the system works on paper before implementing eh? Or ... better, how about that system architecture that is implemented in a few 1000's of lines of code that must be able stable and reliable, and support over a few dozen engineers? Making iterations on such a system would be very difficult and potentially disastrous.

    • This is a great review of the Amazon.com Kindle device. Unfortunately, from what it seems, I cannot use it to read: 1. Tech and reference manuals 2. Hardcore science and engineering journals 3. Comic books! Heh!

    • Jack; I can say this: I am proud to be one of the 1000's of engineers that make everyday tech work for everyday people!

    • Hmmm... Your sources say:

      They state about software: "[no process] consistently delivers reliable, dependable, and affordable software systems. Approximately one-third of software projects fail to deliver anything, and another third deliver something workable but not satisfactory."
      Whereas, for enterprise and desktops, this may be acceptable... I think it is quite unfair to lump us embedded dudes in with that category! The Boeing airplane company quote that roughly 18 million flights were done in the year 2000. Let us say that we design our systems to 10 ppm reliability per year. This means that over the course of the year, we should see roughly 180 catastrophic events. How about 1 ppm? This implies a probability of seeing at least 18 catastrophic events in the airline industry per year! These real numbers are way better than the 66.7% that your sources say eh? I believe there is an implied 'higher standard' with our profession.

    • From what I can see there are a few worst-case-scenarios: 1. Getting axed while working at director or VP level 2. Seeing a sea-change shift in tech, (think dot-com bust) 3. Seeing your carefully nurtured skills demand completely dry-up 4. Calling all your buddies and find out they are getting axed too! I have seen all of this, and more!

    • Just like reputations: reputation It takes a bunch of successes to build a decent reputation It only takes one really big SNAFU to torpedo the reputation Embedded Systems It takes a bunch of lines to make decent code It only takes one bug to torpedo the whole thing!

    • so... Which skills are the more important? Basic? - languages, (design and software) - compilers - chipsets - protocols Sector Specific? - business trends - current tech

    • Computer Science degree? From what I can tell, a ton of embedded engineers hail from the ranks of EE, or better.... EECS. That is Electrical Engineering and Electrical Engineering and Computer Science. But alas ... enrollment in those majors are declining too!

    • All kidding aside: Time, and time again, I slog through data sheets and app-notes that look like this: Huile Stereo Earphone If that did not come out ... Here is a web URL where you can read the instructions for the "Huile Stereo Earphone" http://www.engrish.com//wp-content/uploads/2008/08/huile-stereo-earphone.jpg By the way, "huile" is French for "oil" ... I think the translator meant to write the word whole ... instead got huile! sigh!

    • Let us not forget the Zilog Z80, or more importantly, the venerable 8085 core architecture. There are a lot of stuff out there that use the 808x architecture. From what I can tell though, the ARM7, ARM9 and 8051 are really the top dogs in the embedded space. I myself, am a bit partial to the Texas Instruments MSP4xx ultra low power architecture. What's not to like about a processor that can get power from a grape???

    • PDP == Pretty Darned Perfect hmmm.... PDP == Preposterously Defect Prone! Heh!

    • ok... I can tell you this. Anectdotally, the last recession appeared to hit the TECH sector worse than the current one. However, time will tell whether or not this one rolls completely into TECH. My greatest fear is not the near term, but the long term health of the embedded/DSP engineering disciplines. From what I can see, no new younger folk are coming into our fields. This poses serious long term consequences. People tell me that this represents long term job security for folks like me ... but I cannot help but be concerned for the viability of our field if no new/younger folk take up mantle of embedded development work.

    • ummmm.... Jack!? Your DVD problem is not sales related ... it appears to be a problem with functionality ... which is smack dab in our domain as engineers. Oh ... and marketing too! Heh!

    • Visual Basic? Microsoft Windows? Embedded? Yes ... Really! A lot of folks out there will purchase a cheap desktop, load up Windows, a cheap PCI I/O card and Visual Basic ... and a few weeks later voila! An embedded application that solves some problem is born.

    • Hey Jack! You said: "The screen is so small, though" I say: "The curse of modern technology ... We get smaller sizes, (thru-hole vs. SMT; paper vs. iPod Nano) ... and we get older, and it is more difficult to read the darned stuff" . ... or am I just dreaming here??? Heh!

    • What we got heah ... is a failyah to communicate ... between processors and memory that is! We have successfully beaten the path from processor bandwidth limitation to peripheral, or interconnect bandwidth limitation. It appears as if we hit this limit fairly recently too.

    • Things have changed a lot in the last 10 or so years. At one time, it was enough to know: - C - rudimentary interface such as I2C, RS232 - PIO - interrupts - how to roll-your-own using the while(1) construct ... Nowadays, you need: - Some understanding, or knowledge of synthesis, (VHDL, CUPL, Verilog) - Off-the shelf OS, (vxWorks, pSOS, Nucleus, Thread-X) ... and Linux! - An understanding of Layer-2 through Layer-4 protocols - Embedded TCPIP - Signal processing - Crunching complex math in real time Yes indeed! The real-time world has changed a lot!

    • I don't know. I do know this ... General Instruments was a case study of a poorly run company. The PIC is indeed, a very good processor, with a very good market. My main concerns are on the longevity of some of Atmel's product lines ... especially the SAM9260, or ARM-9 products. I know of a ton of folks out there that would not want to redesign their architectures if the new company decides to phase out Atmel's ARM processor line.

    • so... What is all this about politics? Is it not enough to haggle between the merits of: - C++ - C - Assembler ??? ... or in some cases: - Roll 'yer own OS - Linux - Proprietary ??? We have enough controversy ... Even within our very own field of making stuff work! Heh!

    • I can say this ... for the overall general economy, we are in, and going to be ... in a world of hurt. However, from what I can see locally, here in Silicon Valley, the economy seems to be holding up rather well. What I see: - Large dramatic increase in rush hour traffic - Ton of new folks in the local eateries during lunch hour - Some new hiring of engineering and marketing types by my clients - I still get approximately 1 phone call per week from recruiters Now, all of this is anecdotal ... and anecdotal evidence is of the weakest kind. As to that $700b bailout package? From what I can see, some of the sweeteners that were added are a real boon to Silicon Valley. We have: - Tax credits for R&D - Credits for alternative energy - 'readjustment' of the AMT ... so, I suppose, for the short term things are gonna be ok. However, my main concern is what Jan-Feb of 2009 have in store for us! Ken Wada

    • Great article! so.... How does one get this study? Or better yet, how does one get the Executive summary for the study?

    • Do I pay attention to product warning labels? I pay about as much attention to them as those EULA statements I must check I ACCEPT and AGREE before installing that software!

    • Yeah right! Engineering Director/client: "Hey 'krwada'! we need a bugfix on some of that code that is in the system. It does this and that" krwada: "I dunno, I stole that code on the Internet ... or something like that!" It is potential scenarios like this that keep me from 'reusing' GPL code! I will, however; make attempts at fixing stuff that was not written by me. In fact, I do this most of the time!

    • All economies, since time immemorial, have relied on ... Cheap, abundant, relatively easy-to-get energy. food==energy ... energy==food. The only real problem is where to get the stuff in vast quantities. Actually, there really is an abundance of fossil fuels left on our planet. The real problem is that the cheap stuff is already accounted for. In the near term, fossil fuels will reach some new and higher price equilibrium. The problem, in my opinion, is not one about price ... but our inexorable rush to keep burning the stuff up, whilst at the same time burning up our planet! I believe this problem is the more difficult one to solve. It took us several decades to get to where we are now!

    • Great article Jim! I can say this about Myth #1. I believe this falls in the same category as "There are over 500 channels to watch ... but there is nothing worth watching!". That is, there are a myriad of different processor choices. However, none of them are the exact fit for a particular application. If there were, that company would soon discontinue that processor line. Many managers that I have worked with complain about this 'dearth' of choices. What usually wins out though is some experience with the architecture ... and of course, the never ending fashion show that is the microprocessor design win!

    • $40k ??? I can tell you this Jack ... My wife is a project architect for the city of San Jose. A $40K boo-boo comes about twice a month in these large architectural projects! She just had to write up a change order for a $40K boo-boo that was cast in concrete ... REAL CONCRETE ... Let's get out the jack hammers!!! Haw!

    • All of these projections work well if we make the basic assumption that the current advance in the technology does not change. Then ... WHAM! some really new cutting edge process, or architecture takes shape and we get a bunch of new and cool stuff. I believe there will be new advancements in architecture, component design and process technologies that will allow us to keep that Moore curve going for at least another couple of decades or so!

    • Today's projects, in general, have gotten so large and complicated that it requires a real savvy team of managers and engineers to get the thing done. I have found that almost nobody uses engineering notebooks anymore. The over 50 set still use notebooks. Most folks nowadays place most of their thoughts directly in the code as cryptic comments. Me? I use: - Ton of comments in various header files - Engineering notebooks - Microsoft Visio - Microsoft Word - notepad.exe - Adobe PDF writer ... that pretty much sums up what works for me.

    • ok... We humans have a penchant for making up a bunch of stuff. I can tell you this; there are those, in another community that have no compunction towards defining a ton of new stuff that only a PhD would or could sort out ... along with an army of other erstwhile professionals. Why bother? - with TCPIP when you got CDO, (collateralized debt obligations)? - with L2TP or SNAP when you got SIV's? - with complex equations when you got asset backed securities? It appears as if we humans have a penchant for more information, more complex information, and more ways to confuse ourselves, and more ways to lose money eh? Heh! Ken Wada

    • I can this for sure. The best resource usually is the stuff that you have already done before ... however, it needs to work before you reuse it! "A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering. - Freeman Dyson

    • All this time, I thought defect tracking was somewhat a trailing indicator. How can one know about defects in advance? Unless someone intentionally places defects in a project, I find it difficult to quantify defects as an leading indicator. I can tell you this though, tracking defects, and defect history, along with resolution and time to resolution are all good indicators. These types of metrics go a long way in aggregating valuable statistics on the health of the team and management capabilities. Ken Wada

    • Nice article Jack! Say, I count 14 valves per word. Does that mean the colossus only utilizes 7 bits per octet? Or is there something else going on here? Ken Wada

    • Well... all of the above, some of the above, and none of the above. In general, all those fancy computer aided tools will get you is as good as what is put in. You know that old GIGO buffer effect! I can tell you this though, the days of the lone embedded engineer, working on that one project, over and over ... and over, are starting to come to an end. The newer methods are starting to prevail. And by this, I mean team-based firmware development. Unfortunately, this style tends to work best if sufficient resources are relegated up front to create some kind of framework or API that engineers of the future may easily leverage into new products with new features in a shorter amount of time. But alas! Usually marketing becomes too impatient and starts hamstringing the process by making promises that cannot be kept to the customer!

    • Well... I suppose that it depends. The numbers you quote, 0.5-1.0% is a tad bit high for most embedded systems ... at least for the ones I have been involved in. But then again, I suppose the acceptable defect rate should be different when one compares, let's say, an MP3 player vs. a tele-presence surgical robot. So... are these average numbers, or are these numbers specific to software in general? Ken Wada

    • I suppose ... it depends on the following: - application - environmental constraints - managerial tastes Let us throw the Way-back machine a mere decade ago, (1998, thereabouts), and one will see most embedded systems being programmed using the 'C' language. Now, 10 years later, one will see most embedded systems being programmed using ... 'C' again!. I can say if we fast forward another 10 years, we will see most embedded systems being programmed using ... what else? 'C'. That is not to say that C++ is making inroads. There are a lot of projects out there with embedded GUI's and embedded Linux that are benefitting from a cadre of engineers that are using C++ for embedded. But alas, more and more, my clients are insisting that we engineers stay away from assembler. That is unless we are working on DSP projects. But DSP's are different from microprocessors no? Today, most of my assembler expertise is used in assisting other engineers determine why Linux, Nucleus, Thread-X or other OS has just thrown an exception fault ... that and reading the post mortem analyzer to determine where the resource leak or faulty pointer originated from. That is about all!

    • Hello Jack; ok ... I thought that maybe it would be good for me to weigh in here. Sorry for being gone so long from your fine forum. I have been pretty overwhelmed with a ton of new initiatives over at my client's place. Your overview, of what it takes to be a successful consultant is pretty spot-on! I suppose I can add to some of your observations and experiences. First, an overview of my outlook: - Successful consulting practice since 1988 - Participated on 3 successful IPO teams - Currently, it looks like home run #4 may happen in FY2008 - Started consulting as a moon-lighter in 1987 - Got out of School in 1983, (Masters at UC Berkeley) - Of course, I have a few patents hanging in my den at home. ok ... now on to the nitty gritty: - Commitment! Let me be frank here. One does not do consulting just because they cannot find a job, or want to earn a few dollars. In order to be successful, you must be committed to this new lifestyle - Pain == Opportunity! In today's modern globalized work force, you must be fully aware of why your potential client may want to entertain the notion of bringing you on board - Know your market! The better you understand the mechanics of supply and demand, the better your business will be. I know too many ex-consulting friends that made a ton of money in 1997-2000 ... only to be working in the real estate and mortgage business in 2007! - Carefully understand where you can add value for your customer. The expectations are pretty high for consultants right now. The ones that are getting hired are the ones that can instantly bring value into the company in less than 1-week's time. Even though the "extra pair of hands" consulting is coming back on line .... many times, these "extra pair", wind up being telecommuted from Hyderabad India! I can go on and on on this ... but I believe this comment should give you, and others a bit to chew on. Ken Wada