Below is a sample of the emails you can expect to receive when signed up to Ganssle.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor's Notes | ||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. Arm has released a free e-book of interest to people integrating Cortex-M parts into their SoCs: System-on-Chip Design with Arm Cortex-M Processors. Be careful what you read. Renesas's new S1JA SoC is based on the Cortex-M23 and appears to be a heck of a part, with just about every peripheral you can imagine. But a writeup on embedded.com reads, in part: "The microcontrollers' ultra-low power extends battery life for battery-operated portable and battery backup applications. The software standby mode consumes only 500 nA to enable 20-year battery-operated applications that spend extended periods in sleep mode." Unless the "battery" is a radioisotope generator the 20-year claim exceeds the shelf-life of the batteries used in portable electronics. Getting years of life from a battery is a hard problem with many subtle issues. For more info see this (though that paper focuses on the CR2032 cell, the concepts scale to most battery types). |
||||
Quotes and Thoughts | ||||
"It is better to define your system up front to minimize errors, rather than producing a bunch of code that then has to be corrected with patches on patches" Margaret Hamilton of Apollo Guidance Computer fame. |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Thor wrote:
|
||||
Freebies and Discounts | ||||
This month's giveaway is a copy of Embedded Systems World-Class Designs. Enter via this link. |
||||
The Rust Programming Language | ||||
I'm getting a lot of email about the Rust language, in particular, in using Rust on embedded projects. There's a lot to like about the language. It superficially looks like C/C++. At compile time a borrow-checker tests for memory safety. Basically, each value has an owner. There's only one owner of a variable at a time, and when the owner goes out of scope, the value is dropped. Many people scream at the borrow-checker as it can cause headaches, but users report after a while they learn to abide by Rust's rules, and get a lot of benefit from the memory-safety checks, as it eliminates data races and other common problems. Here's an example factorial program, from the Wikipedia entry: fn factorial(i: u64) -> u64 { let mut acc = 1; for num in 2..=i { acc *= num; } acc } Where's the return argument? In Rust, if there's no return statement the last expression is the return value. I find that strangely appealing. The "let" keyword reminds me of the bad old days of Dartmouth BASIC. Rust is used in embedded development, and the main site has a sub-page about this, with examples using a Cortex M processor. While C is a great language for low-level programming and embedded development, it lacks modern features like strong typing (and so much more) that helps create correct programs. The SPARK people call this "correctness by construction." Ada, SPARK, and to a lesser extent Rust enforce rules which lead to safer code. Studies (e.g., Software Static Code Analysis Lessons Learned, Andy German, QinetiQ Ltd., Nov 2003 Crosstalk) show programs in Ada and SPARK have only a fraction of the defects found using C. To my knowledge there's no such data about Rust, but it seems reasonable that Rust code will be less error-prone than C code. I have seen no data on Rust's efficiency (in size and speed), bus suspect it's similar to C. However, as fascinating as it is to learn new languages, there's one place where Rust fails. It's evolving at a rapid pace, and there is no ANSI standard. That's generally not much of a problem in web development or for small embedded projects. But many embedded systems have lives of years and decades. In the railroad industry support has to be guaranteed for 30 years. What will Rust look like a decade or two hence? Will you be able to get a compiler that handles the old dialect? If you have hundreds of thousands of lines of Rust legacy code, reuse might be impossible if all of that is coded using a long-obsolete version. C made its way into the embedded space in the 1980s. Lots of compilers abounded. None were compatible. Remember Manx C? That decade was a veritable Babel of incompatible Cs which was resolved only with the advent of standardization under ANSI C 89/90. As technologists we want the best possible solution. Yet sometimes that has to take second place to business realities. Every engineering effort involves some amount of risk, but we do want to minimize that risk, especially if it could have devastating long-term consequences. Megabucks invested in developing code that can no longer be compiled is a risk that is not, in my opinion, worth taking. I look forward to the day when Rust joins the stable of standardized languages, and have no doubt we'll see that happen in the next decade or so. Standardization efforts move slowly. ANSI spent six years working on the first C standard. |
||||
Encoder Bouncing | ||||
Recent Muses (TEM 384 and TEM 385) had discussions about encoders, which engendered quite a bit of interesting email correspondence. I decided to look at bounce characteristics of a few models. I picked low-cost devices as these are common in controls (e.g., radio volume controls). My focus was (mostly) on mechanical encoders, as it's reasonable to assume these will have significant bounce issues. Bourns's PEC11R-4215F mechanical encoder gives 24 PPR (pulses per revolution). The datasheet specs 2 ms bounce though that is footnoted "Devices are tested using standard noise reduction filters." It's not clear to me if the 2 ms was with or without the filter, but the unit behaved much better than specified. With no filter, this is the worst bouncing I saw: That's pretty ugly, but the bouncing lasted only about 250 µs. The datasheet recommends this circuit to clean up the noise:
With it, I saw no bouncing. The resulting waveform gives rise and fall times greater than expected from the RC time constant (3.7 ms rise, 1.9 ms fall); presumably there's some internal resistance: CTS's 288V232R161B2 mechanical encoder gives 4 PPR. 5 ms bounce is specified. No filter circuit is recommended. The worst bounce I saw was about 300 µs.: CUI Devices's ACZ11BR4E-20KQ01-12C gives 12 PPR. No bounce data is given in the datasheet. Here's the worst I saw - about 5 ms of terror: The recommended filter circuit is identical to the one Bourns suggests (see above). With it, well, the results were not great: The scope is set to 10 ms/division. Some of those supposedly-filtered zits exceed 2V. Even a Schmitt trigger, like the 74HCT14, will pass these on as valid logic signals. At least the bounces are very narrow. One could write some code that rejects pulses shorter than a ms or so. Just to put this data in perspective, I also tried an optical encoder, expecting clean outputs. And indeed, there was no bouncing. This is the Grayhill 62AG11-L0-P, which sports 32 PPR: Note the slow rise and fall times, which I saw at times exceeding 8 ms. That is better, however, than the rated 30 ms worst-case numbers. I presume this is an artifact of the optical interrupter swinging into the light beam. Be sure to figure this into your max rotation speed. Assuming 30 ms rise time, and another 30 ms fall time, with 32 PPR the max speed will be under 0.5 rotations/second. I recently rented a Toyota; the radio was almost unusable as turning the tuning knob caused wild and unpredicable results. A clockwise rotation often increased the frequency, as expected, but sometimes the the tuner jumped down or crazily up. One wonders if the engineers used an encoder yet didn't anticipate For ideas about debouncing, see this. |
||||
Of R&D | ||||
Research and Development. R&D. It's the lifeblood of tech companies, and it's what we engineers do all day, every day. Nonsense. There's no such thing as R&D. There's R, and there's D, and the two are completely separate activities. Research is all about discovering new things. It's the science that ultimately enables the products we build, the metaphorical man-behind-the-curtain pulling the levers to control the machines we create. Research might also involve discovering new algorithms, like new ways to smooth signals or compress data. "New" might mean new to us but not to the world. So we research an idea or a need, and then switch to development mode. The result of research is an approach that one can then implement. Development is taking known ideas and using them to build products. That's the bulk of an engineer's work. We transform an algorithm to something physical, like converting a CRC algorithm to C code, to VHDL inside an FPGA, or to logic components. One of my top ten reasons for failed projects is "bad science," or the inability to separate R from D. When a company starts building a product before really understanding what is being measured the schedule is doomed. Start coding an algorithm without it being sharply defined and, at best, you'll wander aimlessly till, with luck, settling on an approach that works. Research simply can't be scheduled. If you don't believe that, please develop a (realistic) schedule for discovering the cure for cancer. You might be able to guesstimate simple research schedules, like doing a search for a known algorithm, but even that is, in my experience, very difficult to estimate. The first "Eureka" is often followed by disappointment when a little experimenting reveals some fatal flaw, requiring more research to find a better approach. Yet I constantly see teams conflating R and D, leading inevitably to late or failed projects. Sure, there are some projects that necessarily pursue R and D in parallel. But those care rarely be scheduled with any accuracy. What do you think? Have you ever had a project disaster because you were doing R and the same time as D?
|
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. Standards, n.: The principles we use to reject other people's code. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor's Notes | ||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. Arm has released a free e-book of interest to people integrating Cortex-M parts into their SoCs: System-on-Chip Design with Arm Cortex-M Processors. Be careful what you read. Renesas's new S1JA SoC is based on the Cortex-M23 and appears to be a heck of a part, with just about every peripheral you can imagine. But a writeup on embedded.com reads, in part: "The microcontrollers' ultra-low power extends battery life for battery-operated portable and battery backup applications. The software standby mode consumes only 500 nA to enable 20-year battery-operated applications that spend extended periods in sleep mode." Unless the "battery" is a radioisotope generator the 20-year claim exceeds the shelf-life of the batteries used in portable electronics. Getting years of life from a battery is a hard problem with many subtle issues. For more info see this (though that paper focuses on the CR2032 cell, the concepts scale to most battery types). |
||||
Quotes and Thoughts | ||||
"It is better to define your system up front to minimize errors, rather than producing a bunch of code that then has to be corrected with patches on patches" Margaret Hamilton of Apollo Guidance Computer fame. |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Thor wrote:
|
||||
Freebies and Discounts | ||||
This month's giveaway is a copy of Embedded Systems World-Class Designs. Enter via this link. |
||||
The Rust Programming Language | ||||
I'm getting a lot of email about the Rust language, in particular, in using Rust on embedded projects. There's a lot to like about the language. It superficially looks like C/C++. At compile time a borrow-checker tests for memory safety. Basically, each value has an owner. There's only one owner of a variable at a time, and when the owner goes out of scope, the value is dropped. Many people scream at the borrow-checker as it can cause headaches, but users report after a while they learn to abide by Rust's rules, and get a lot of benefit from the memory-safety checks, as it eliminates data races and other common problems. Here's an example factorial program, from the Wikipedia entry: fn factorial(i: u64) -> u64 { let mut acc = 1; for num in 2..=i { acc *= num; } acc } Where's the return argument? In Rust, if there's no return statement the last expression is the return value. I find that strangely appealing. The "let" keyword reminds me of the bad old days of Dartmouth BASIC. Rust is used in embedded development, and the main site has a sub-page about this, with examples using a Cortex M processor. While C is a great language for low-level programming and embedded development, it lacks modern features like strong typing (and so much more) that helps create correct programs. The SPARK people call this "correctness by construction." Ada, SPARK, and to a lesser extent Rust enforce rules which lead to safer code. Studies (e.g., Software Static Code Analysis Lessons Learned, Andy German, QinetiQ Ltd., Nov 2003 Crosstalk) show programs in Ada and SPARK have only a fraction of the defects found using C. To my knowledge there's no such data about Rust, but it seems reasonable that Rust code will be less error-prone than C code. I have seen no data on Rust's efficiency (in size and speed), bus suspect it's similar to C. However, as fascinating as it is to learn new languages, there's one place where Rust fails. It's evolving at a rapid pace, and there is no ANSI standard. That's generally not much of a problem in web development or for small embedded projects. But many embedded systems have lives of years and decades. In the railroad industry support has to be guaranteed for 30 years. What will Rust look like a decade or two hence? Will you be able to get a compiler that handles the old dialect? If you have hundreds of thousands of lines of Rust legacy code, reuse might be impossible if all of that is coded using a long-obsolete version. C made its way into the embedded space in the 1980s. Lots of compilers abounded. None were compatible. Remember Manx C? That decade was a veritable Babel of incompatible Cs which was resolved only with the advent of standardization under ANSI C 89/90. As technologists we want the best possible solution. Yet sometimes that has to take second place to business realities. Every engineering effort involves some amount of risk, but we do want to minimize that risk, especially if it could have devastating long-term consequences. Megabucks invested in developing code that can no longer be compiled is a risk that is not, in my opinion, worth taking. I look forward to the day when Rust joins the stable of standardized languages, and have no doubt we'll see that happen in the next decade or so. Standardization efforts move slowly. ANSI spent six years working on the first C standard. |
||||
Encoder Bouncing | ||||
Recent Muses (TEM 384 and TEM 385) had discussions about encoders, which engendered quite a bit of interesting email correspondence. I decided to look at bounce characteristics of a few models. I picked low-cost devices as these are common in controls (e.g., radio volume controls). My focus was (mostly) on mechanical encoders, as it's reasonable to assume these will have significant bounce issues. Bourns's PEC11R-4215F mechanical encoder gives 24 PPR (pulses per revolution). The datasheet specs 2 ms bounce though that is footnoted "Devices are tested using standard noise reduction filters." It's not clear to me if the 2 ms was with or without the filter, but the unit behaved much better than specified. With no filter, this is the worst bouncing I saw: That's pretty ugly, but the bouncing lasted only about 250 µs. The datasheet recommends this circuit to clean up the noise:
With it, I saw no bouncing. The resulting waveform gives rise and fall times greater than expected from the RC time constant (3.7 ms rise, 1.9 ms fall); presumably there's some internal resistance: CTS's 288V232R161B2 mechanical encoder gives 4 PPR. 5 ms bounce is specified. No filter circuit is recommended. The worst bounce I saw was about 300 µs.: CUI Devices's ACZ11BR4E-20KQ01-12C gives 12 PPR. No bounce data is given in the datasheet. Here's the worst I saw - about 5 ms of terror: The recommended filter circuit is identical to the one Bourns suggests (see above). With it, well, the results were not great: The scope is set to 10 ms/division. Some of those supposedly-filtered zits exceed 2V. Even a Schmitt trigger, like the 74HCT14, will pass these on as valid logic signals. At least the bounces are very narrow. One could write some code that rejects pulses shorter than a ms or so. Just to put this data in perspective, I also tried an optical encoder, expecting clean outputs. And indeed, there was no bouncing. This is the Grayhill 62AG11-L0-P, which sports 32 PPR: Note the slow rise and fall times, which I saw at times exceeding 8 ms. That is better, however, than the rated 30 ms worst-case numbers. I presume this is an artifact of the optical interrupter swinging into the light beam. Be sure to figure this into your max rotation speed. Assuming 30 ms rise time, and another 30 ms fall time, with 32 PPR the max speed will be under 0.5 rotations/second. I recently rented a Toyota; the radio was almost unusable as turning the tuning knob caused wild and unpredicable results. A clockwise rotation often increased the frequency, as expected, but sometimes the the tuner jumped down or crazily up. One wonders if the engineers used an encoder yet didn't anticipate For ideas about debouncing, see this. |
||||
Of R&D | ||||
Research and Development. R&D. It's the lifeblood of tech companies, and it's what we engineers do all day, every day. Nonsense. There's no such thing as R&D. There's R, and there's D, and the two are completely separate activities. Research is all about discovering new things. It's the science that ultimately enables the products we build, the metaphorical man-behind-the-curtain pulling the levers to control the machines we create. Research might also involve discovering new algorithms, like new ways to smooth signals or compress data. "New" might mean new to us but not to the world. So we research an idea or a need, and then switch to development mode. The result of research is an approach that one can then implement. Development is taking known ideas and using them to build products. That's the bulk of an engineer's work. We transform an algorithm to something physical, like converting a CRC algorithm to C code, to VHDL inside an FPGA, or to logic components. One of my top ten reasons for failed projects is "bad science," or the inability to separate R from D. When a company starts building a product before really understanding what is being measured the schedule is doomed. Start coding an algorithm without it being sharply defined and, at best, you'll wander aimlessly till, with luck, settling on an approach that works. Research simply can't be scheduled. If you don't believe that, please develop a (realistic) schedule for discovering the cure for cancer. You might be able to guesstimate simple research schedules, like doing a search for a known algorithm, but even that is, in my experience, very difficult to estimate. The first "Eureka" is often followed by disappointment when a little experimenting reveals some fatal flaw, requiring more research to find a better approach. Yet I constantly see teams conflating R and D, leading inevitably to late or failed projects. Sure, there are some projects that necessarily pursue R and D in parallel. But those care rarely be scheduled with any accuracy. What do you think? Have you ever had a project disaster because you were doing R and the same time as D?
|
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. Standards, n.: The principles we use to reject other people's code. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||||
Contents | ||||||||
|
||||||||
Editor's Notes | ||||||||
Happy Beethoven's birthday! Some HP SSDs "stop running after the 32,768-hour mark." The citation is from an article in Electronic Design. The language is a bit muddy; I expect they fail as the time rolls over from 32,767 to 32,768 hours. Bugs are all-too-common but consider this: That's almost four years. No reasonable amount of testing would uncover the problem. While test is critical, it's inadequate. Without access to the code it's impossible to be certain, but I suspect even achieving 100% test coverage would not have picked up the problem. Test is just one of many filters needed to insure correct code. Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. It's a beautiful country with great people, but a long way from my homestead in Maryland. |
||||||||
Quotes and Thoughts | ||||||||
Re: Wilbur Wright: "Wilbur was a man who established a goal with care, then never lost sight of it. He was the perfect engineer - isolating a basic problem, defining it in the most precise terms, and identifying the missing bits of information that would enable him to solve it. Other students of the subject lost themselves in a welter of confusing details; they were lured into extraneous, if fascinating, blind alleys that led away from the basic problem." From the book The Bishop's Boys by Tom Crouch. |
||||||||
Tools and Tips | ||||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Mat Bennion raised one of the issues we hear about from time to time with the use of C:
In a time when so many articles in the trade press are thinly-disguised press releases, it's important to acknowledge those pushing back against this sort of uber-marketing. Bill Schweber's articles in Electronic Design consistently provide information of use to engineers. They typically describe how some component or circuit works, like this week's excellent piece that describes flyback circuits. |
||||||||
Freebies and Discounts | ||||||||
Curt Bruns won the power supply in the November contest. This month's giveaway is a copy of Embedded Systems World-Class Designs. Enter via this link. |
||||||||
DO-178C On Requirements | ||||||||
It's believed, until the recent 737-MAX crashes, that no one had ever lost a life in a commercial aircraft due to a software problem. Why is this? No one really knows. All commercial aircraft software in the USA is crafted to DO-178C. Is it the use of this standard, or is it a safety culture that is willing to embrace the burdensome regs? Regardless, few industries regularly achieve the high quality of code done to DO-178C. Harold Kraus sent in the following about the importance of requirements in avionics. But first, a couple of definitions for those unfamiliar with DO-178C:
Here's Harold's write-up:
|
||||||||
Benchmarking Firmware Teams | ||||||||
How does your team compare to others in the industry? Is it world-class, or sub-par? Benchmarking is the practice of comparing some aspect of a business with other companies in the same industry. For instance, a business might average 46 days to collect a receivable. What does that mean? If the industry average is 35 days, 46 is nothing to brag about. If 80% of their competitors do worse, then 46 is a great number. It's likely going to be hard to gain much improvement. I've advocated benchmarking firmware teams for many years. Alas, it's hard to get good numbers, and the standard deviations are high. But we do have some data. In my Better Firmware Faster class I stress the importance of engineering with numbers. As David Aikin said: "Engineering is done with numbers. Analysis without numbers is only an opinion." For instance, most teams average a 5 to 10% defect rate after getting a clean compile before any testing starts. Worst-in-class engineers generate 250 defects per KLOC. There's no measurable difference between C and C++. So for a 10KLOC project figure on chasing 500 to 1,000 problems. Ever wonder why projects run late? Clearly these numbers are abysmal. Cut them by half and the schedule will improve dramatically. Ada teams are about an order of magnitude better, and SPARK developers crush even Ada. Where do bugs come from? This table shows defects/KLOC for a poorly-performing team, and one rated at Capability Maturity Level 3, considered a pretty disciplined outfit: And here's where defects are removed: Defect Removal Efficiency (DRE) is one of those tortured terms academics love. It's merely the percentage of defects removed during engineering and up to 90 days post-initial delivery. You'd hope for 100%. Here's where the industry stands. "Bugs/KLOC" is the number of shipped bugs per thousand lines of code: Poor quality teams tend to rely mostly on test to find defects. Capers Jones identifies over 60 ways to minimize these, though no one does or should use all of those. I view this as a series of filters, each stage removing some percentage of problems. It has been shown that test, by itself, typically finds only 50%. For more numbers Capers Jones' books are a great resource. The sadly-defunct Crosstalk Magazine was also a valuable resource. How does your team measure up? |
||||||||
Rust Redux | ||||||||
Muse 387's comments about the Rust programming language generated a lot of discussion. Nick P's thoughts were useful:
Tock is an RTOS written in Rust. The Case for Writing a Kernel in Rust is a worthwhile paper about how Rust is a good choice for RTOS work, though I stand by my thoughts in Muse 387. |
||||||||
More on R&D | ||||||||
A number of people responded to last issue's comments on R&D. Charles Manning wrote:
From Mike Davis:
Rob Milne commented:
Emil Imrith had a suggestion:
|
||||||||
Jobs! | ||||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||||
Joke For The Week | ||||||||
These jokes are archived here. bug, n: A son of a glitch. |
||||||||
About The Embedded Muse | ||||||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||||
Contents | ||||||||
|
||||||||
Editor's Notes | ||||||||
Happy Beethoven's birthday! Some HP SSDs "stop running after the 32,768-hour mark." The citation is from an article in Electronic Design. The language is a bit muddy; I expect they fail as the time rolls over from 32,767 to 32,768 hours. Bugs are all-too-common but consider this: That's almost four years. No reasonable amount of testing would uncover the problem. While test is critical, it's inadequate. Without access to the code it's impossible to be certain, but I suspect even achieving 100% test coverage would not have picked up the problem. Test is just one of many filters needed to insure correct code. Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. It's a beautiful country with great people, but a long way from my homestead in Maryland. |
||||||||
Quotes and Thoughts | ||||||||
Re: Wilbur Wright: "Wilbur was a man who established a goal with care, then never lost sight of it. He was the perfect engineer - isolating a basic problem, defining it in the most precise terms, and identifying the missing bits of information that would enable him to solve it. Other students of the subject lost themselves in a welter of confusing details; they were lured into extraneous, if fascinating, blind alleys that led away from the basic problem." From the book The Bishop's Boys by Tom Crouch. |
||||||||
Tools and Tips | ||||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Mat Bennion raised one of the issues we hear about from time to time with the use of C:
In a time when so many articles in the trade press are thinly-disguised press releases, it's important to acknowledge those pushing back against this sort of uber-marketing. Bill Schweber's articles in Electronic Design consistently provide information of use to engineers. They typically describe how some component or circuit works, like this week's excellent piece that describes flyback circuits. |
||||||||
Freebies and Discounts | ||||||||
Curt Bruns won the power supply in the November contest. This month's giveaway is a copy of Embedded Systems World-Class Designs. Enter via this link. |
||||||||
DO-178C On Requirements | ||||||||
It's believed, until the recent 737-MAX crashes, that no one had ever lost a life in a commercial aircraft due to a software problem. Why is this? No one really knows. All commercial aircraft software in the USA is crafted to DO-178C. Is it the use of this standard, or is it a safety culture that is willing to embrace the burdensome regs? Regardless, few industries regularly achieve the high quality of code done to DO-178C. Harold Kraus sent in the following about the importance of requirements in avionics. But first, a couple of definitions for those unfamiliar with DO-178C:
Here's Harold's write-up:
|
||||||||
Benchmarking Firmware Teams | ||||||||
How does your team compare to others in the industry? Is it world-class, or sub-par? Benchmarking is the practice of comparing some aspect of a business with other companies in the same industry. For instance, a business might average 46 days to collect a receivable. What does that mean? If the industry average is 35 days, 46 is nothing to brag about. If 80% of their competitors do worse, then 46 is a great number. It's likely going to be hard to gain much improvement. I've advocated benchmarking firmware teams for many years. Alas, it's hard to get good numbers, and the standard deviations are high. But we do have some data. In my Better Firmware Faster class I stress the importance of engineering with numbers. As David Aikin said: "Engineering is done with numbers. Analysis without numbers is only an opinion." For instance, most teams average a 5 to 10% defect rate after getting a clean compile before any testing starts. Worst-in-class engineers generate 250 defects per KLOC. There's no measurable difference between C and C++. So for a 10KLOC project figure on chasing 500 to 1,000 problems. Ever wonder why projects run late? Clearly these numbers are abysmal. Cut them by half and the schedule will improve dramatically. Ada teams are about an order of magnitude better, and SPARK developers crush even Ada. Where do bugs come from? This table shows defects/KLOC for a poorly-performing team, and one rated at Capability Maturity Level 3, considered a pretty disciplined outfit: And here's where defects are removed: Defect Removal Efficiency (DRE) is one of those tortured terms academics love. It's merely the percentage of defects removed during engineering and up to 90 days post-initial delivery. You'd hope for 100%. Here's where the industry stands. "Bugs/KLOC" is the number of shipped bugs per thousand lines of code: Poor quality teams tend to rely mostly on test to find defects. Capers Jones identifies over 60 ways to minimize these, though no one does or should use all of those. I view this as a series of filters, each stage removing some percentage of problems. It has been shown that test, by itself, typically finds only 50%. For more numbers Capers Jones' books are a great resource. The sadly-defunct Crosstalk Magazine was also a valuable resource. How does your team measure up? |
||||||||
Rust Redux | ||||||||
Muse 387's comments about the Rust programming language generated a lot of discussion. Nick P's thoughts were useful:
Tock is an RTOS written in Rust. The Case for Writing a Kernel in Rust is a worthwhile paper about how Rust is a good choice for RTOS work, though I stand by my thoughts in Muse 387. |
||||||||
More on R&D | ||||||||
A number of people responded to last issue's comments on R&D. Charles Manning wrote:
From Mike Davis:
Rob Milne commented:
Emil Imrith had a suggestion:
|
||||||||
Jobs! | ||||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||||
Joke For The Week | ||||||||
These jokes are archived here. bug, n: A son of a glitch. |
||||||||
About The Embedded Muse | ||||||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor's Notes | ||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. Engineering changes at an accelerating pace. The boss wants more bug-free code, today. Tomorrow he'll want even more in the same time-frame. Are you on top of the best ways to deliver it? Some tell me they just don't have time to attend seminars. I'm reminded of this: It is important to fight today's engineering battle. But the war will be lost if you don't find better ways to win. This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends today. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. It's a beautiful country with great people, but a long way from my homestead in Maryland. Jack's latest blog: A Lack of Forethought |
||||
Quotes and Thoughts | ||||
I never give anyone hell. I only tell the truth. They think it's hell. Harry S. Truman |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. |
||||
Freebies and Discounts | ||||
This month's giveaway is a Cypress CY8KIT-044 PSoC 4 M-series Pioneer kit. Enter via this link. Brian Cuthie reports that the schematic editor/simulation software Micro-Cap is now free. See this. |
||||
On Requirements Documents | ||||
How long are your requirements documents? How complete are they? Getting hard data is notoriously difficult in the software world. Capers Jones probably has more than anyone. He stresses the large standard deviation, but makes it clear that one can gain some insight from it. I view the data as an impressionist painting, where the outlines might be fuzzy, but one can still make out the general shape of things. The following table is derived from data in Jones' The Economics of Software Quality. It shows how many pages of requirements are found for various-sized projects. The "Requirements Completeness" column illustrates all-to-pathetically how short those pages are of the delivered functionality. Jones uses function points instead of lines of code. Most of us are uncomfortable with function points, so I've converted them to lines of C code using the generally-accepted average of one FP being 130 lines of C. Playing with the numbers, for 100% completeness you'd need about one page of requirements documentation for every ten lines of code. It's not clear if a "page" means 500 words, or perhaps just a sentence or two, with perhaps each requirement standing proudly on its own page. What do your numbers look like? |
||||
More New Years Resolutions | ||||
Vlad Z sent more New Year's resolutions:
|
||||
On E-Voting | ||||
Later this year the US will chose a new president. But who will make that choice? I last wrote about electronic voting machines in the election year of 2008. Twelve years later little has changed. Vermin the world over will exploit any computer weakness to extort tens of thousands of dollars from the unsuspecting populace. Those are pretty puny stakes compared with the presidential election, which will consume billions of dollars of campaign funds and will shape the direction of the most powerful nation on the planet for at least four years. So how did we react? By acquiring voting machines with many known security flaws, developed without using best engineering practices, whose code is proprietary, and that use hacker-friendly operating systems. In effect, the government, by making these purchasing decisions, sanctioned a "we're the government, you can trust us" appeal to the electorate. Ironically, the citizenry has never trusted the government less than in recent years. We know how to build reliable software systems. We know how to build secure software systems. We decided not to. How dumb is that? Democracy is hard. We citizens have to be involved. We need to hold our elected officials accountable, and toss them out when they fail to meet our standards. That requires we trust the integrity of the ballot box. E-voting travails are not new; ballot-stuffing is as old as the Republic. The difference is that now it may be possible to stuff millions of votes with a few clicks. I believe that e-voting holds the promise of eliminating compromised elections. But not with the approaches used now. I'm sickened to read of various commissions demanding that vendors add printers to their machines. That's does nothing to prove that each vote is recorded properly. The printer could show one candidate and record another. And the voting machine itself is not the issue: it's the entire system, including the computers that hold the databases, which are even more attractive targets for bad actors. We citizens must demand a system that works. That requires the following:
Will this happen? I doubt it. Conspiracy theorists probably feel the overlords who control the government want to have hackable elections. But I suspect there's more truth in: Never ascribe to malice, that which can be explained by incompetence. |
||||
The Secret of My Success | ||||
The blue light of the TV flickered on the blank wall, but it went unnoticed by me as I slumped in my old armchair. It had been a bad week. She left on Monday, screaming that she couldn't take all of the equipment piled everywhere. Me, I thought that old Tek 545 was a collector's item, an antique. Sure, the dust was pretty bad, but you can bet we were the only couple in town with a living room populated by old scopes and CP/M machines. Yeah, I do mess up some times, like that time my homebrew furnace controller burped and drove the house to 115 degrees when we were gone for the weekend. Hey, I never liked those pets anyway, and the smell did eventually come out of the carpets. Pretty much. I mean, it was just a little software bug; we all have those! And there was the fire. Yeah, next time I'll put a bigger heat sink on the power supply. I admit it - I learned a lesson. The scorch marks on her dresses don't really look all that bad. I reached for another bag of chips as the chair groaned a bit more. One of these days I'm gonna have to work off some of the excess pounds. A decade spent in the lab drinking Jolt and munching fries had taken its toll. Despite the flab I still know calculus and can program in C; surely a dream dude for any discerning woman. I bet I could wow them at the local watering hole with my great stories about TCP/IP! Well, this is Silicon Valley after all, where relationships, jobs and careers are measured in milliseconds and loyalty doled out by the microgram. Electronics is a dog-eat-dog business and I'm an old hand at crawling out from the wreckage. Like that last startup I worked for. I told 'em we'd get that product out the door, eventually anyway. We woulda survived if that idiot president just got another couple of mil of venture capital. For a while at least. Ya know, maybe it was losing that job that ticked her off. I figure, what's the big deal? She should be used to this by now. Check out my resume - it shows lots of experience at lots of places. No one can beat this! I picked up the phone but heard only the accusing silence of a non-payment disconnection. No matter. Time to find another company looking for my embedded expertise. There's a startup a minute here, pigeons ripe for picking. I clumped out of the trailer's front door and found Big Al, the usual wild look in his eyes, mouth working hard on this morning's sugar raised, the white powder spotting his beard. "Al, buddy, you're outa work too, huh? How's the wife and kids?" "Kids? Kids? Yeah, come to think of it I did notice some little people living with me. I wonder where they came from? Check this out." With that he shoved a coffee-stained fragment of the San Jose Mercury News into my hands. I quickly took in the circled want ad. "ENGINEERs – microprocessor savvy designers and programmers needed. C, FPGAs, assembly a plus. Exciting opportunity for a motivated developers in a new high-growth company." A slow smile spread across my face. Here was our pigeon; I was already mentally spending the signing bonus. That afternoon, T-shirts cleaned and pressed, with most of the donut detritus hurriedly wiped from Al's beard, we met with the president of Galaxar Enterprises. Yep, just as usual, this man was the typical harried executive desperate for people, so desperate he had neither the time nor resources to do much of a background check. Not that my background is so terrible; it's just that there's so much of it. "You know C? Schematic capture? What's the last project you worked on?" he mumbled, looking at his watch while the cell pinged an urgent tune. "We did that Internet cappuccino maker for Kitchen Services; you must have read about it in the press. Yep, that puppy had a RISC-V based coffee engine with 10 gigs of RAM…" "Didn't they go Chapter 7?", he interrupted, interested now. "Trust me on this. The boss was an idiot. He just didn't understand how much compute power we needed to blend the perfect cuppa joe. That sucker could crank some coffee, believe me. If they hadn't been so stuck on the cost of goods we coulda cleaned up the cappuccino market. We were practically done with development when the SEC raided us." "OK, OK, look, when can you start? Now? Don't you guys ever shave? Hell, just sit here and Bob will tell you what to do." Bob, engineering VP, was one of those snotty-nosed brats with a degree and an attitude. "We're building a new marine VHF radio for the recreational boating market. That means there are three main design parameters. First, the unit must be totally sealed to insure it's waterproof. Second, the sell price can't exceed $250. And obviously the unit must be simple enough that even the most casual boater can use it." He went on to tell us how we were going to design the product. Us! Can you imagine? As if I don't understand project planning, structured design, discipline design, and all of that utter crap. Me, I prefer to skip all of that non-productive nonsense and just bang it out. I zoned out, the drone of Bob's voice barely noticeable, nodding at the right time while planning my next move. Clearly it was time for the old end-run. Saturday night Al and I marched into the president's office. "Herb," I started, "we know you're running out of venture money and an IPO is at least a year away. Bob's planning to spend another three months just doing preliminary design. Whatdoya want, a design or a product? Trust me on this – we can pound out a design in a week, max, and then get the radio done in no time." Herb's eyes gleamed. It seems that he, too, was frustrated by Bob's methodical approach to engineering. This valley is the land of Steve Jobs, where unbridled passion and hope fuels the dream of tomorrow's big score. Discipline? Bah. Just lemme at a problem and I'll get it done. With a bit more prodding Herb agreed that this project was so important he'd give it skunk-works treatment, get Bob off of our backs, and let us report directly to his president's office. The week sped by like a read from cache memory. Al slouched into my cubicle, let out a long, satisfying-sounding belch, and asked "didn't we promise Herb a spec or something?" Right! Never let the boss, down, that's my motto. Unless there's a good reason, of course. "Sure, look, just grab those header files we've been working on and edit a bit of descriptive stuff at the beginning. They'll never read it all anyway. If he complains we'll tell 'em not only is the spec done, we've incorporated it into the firmware. How can he get upset if he sees we're already coding?" Herb swallowed our header files hook, line and sinker. He's thrilled that we're already cranking out software, and giddily reported our progress to the venture capitalists. I think they're already mentally spending their IPO profits. Bob is muttering vague threats, but he's been squeezed into the user-interface group. He wants Al and I to take on that new college grad, Marty. We're supposed to show him how to get projects done. It's not all bad; the kid has a car so can get us beers and carry-out. The secret to success in this business is to look busy, keep a prototype in a state that looks like it has some level of functionality, and always agree with the boss. And you can't act like you have a personal life when battling a schedule! Heck, after just three days on the job Marty asked if he could leave at 5 to celebrate his first anniversary. I straightened him out. "Kid, trust me on this. We all go through one or two starter marriages, you know, no kids, no property, no regrets. Don't take it too seriously. Now let's order a pizza and get back to work." It was probably a good thing that I turned off the switchboard that night, so he wouldn't get distracted by all of those frantic calls from home. And that kid did need some attention. I caught him late one night doing a spell check on his comments! Somehow he missed the fact that a ship date loomed; comments are always the first thing to go. "Kid, trust me on this. Never include a comment that will help someone else understand your code. If they understand it, they don't need you." I think he gets the picture now. As time moved on we started having trouble fitting the binary image into the CPU's address space. "This always happens", I reassured Herb, "them 16 bitters just can't handle the sort of code we're cranking out for you. Look, we'll just stuff a bigger part in there this afternoon. No problemo; I've done this a million times." Big Al's eyes lit up when I suggested we look into a 64 bit processor. "I've got just the ticket. There's one I've been itching to try; it's totally reconfigurable, you can even define your own instruction set. Man, this is gonna look great on my resume!" Ah, resume fodder, the grease of the industry. Herb didn't seem to concerned about the increased cost of goods – at least he wasn't asking any questions – so I set out trying to find some way to cool the sucker. With luck a big old heat sink and decent-sized fan might be adequate. Jeez, maybe I'll use the next size up; those burnt dresses still haunt me at times. We optimized the instruction set on the CPU to play DoomStar III at awesome speeds. The best part of using a custom architecture was that I got to port the entire GNU toolchain to our chip. That compiler sure is tricky! First time I'd ever fiddled with a code generator, so it naturally took a bit longer than planned to get working – mostly – tools. As the weeks passed Herb got noticeably more antsy, checking on our progress on a daily, and then hourly, basis. This always happens, and is a sign that the old cash reserve is evaporating. I started running to the bank the minute paychecks came out. No one's gonna stick me with bouncing paper! Been there, done that. Bob – remember Bob? – strolled into the lab one afternoon to check on our progress. It seems the fool had actually invested his own money into the company! He's correspondingly annoying about what we do, even though my end-run had gotten him off the project months before. Oddly, he seemed upset about the cooling fan. "This thing has got to be totally sealed, so no water gets in!" he whined. "Yeah, yeah, just mount it in a dry place or something", I replied. "I can't be bothered with that sort of stuff. You know how much power this sucker uses?" These company men are all stress puppies. Not me; I'll be going strong when he suffers his first mid-30s myocardial infarction. Christmas rolled around – or was it Easter? I dunno, we were plenty busy chasing down bugs and making feature changes. Bob's paycheck bounced. I knew that Herb had been doing some fancy footwork to keep things afloat, but when everyone in accounting quit, complaining about insolvency or something, the standard exodus began. As usual, engineering remained untouched by the various rounds of layoffs. They needed the products we make to survive. I love this field! This seemed like a great time for a two week vacation, though Marty seemed almost hysterical that I'd take off now. "Kid, trust me on this. Never complete a project on time. If you do, they will think it was easy and anyone can do it and they don't need you. Now I'm outa here for a while. Look busy and we'll sort it all out when I get back." I got back, more or less sober but feeling great, to find the front door padlocked and a sheriff standing guard. Marty, skulking in a dark corner, grabbed my arm and moaned that he couldn't build the code at all while I was away. It seems he had trouble locating all of the source. "Kid, trust me on this. Never archive all the sources necessary to build a binary. Always hide a few on your own disk. If they can build your binary, they don't need you. What do they teach you in college, anyway?" He said the creditors got fed up and were demanding their money. Half the employees were suing because their paychecks bounced. A satisfied grin spread across my face as I recalled beating the rest of those idiots to the bank. Marty shrieked that Herb was suing all of us in engineering for not meeting promised dates, specs, or features. "Kid, trust me on this. They always sue. That's why I own nothing. What do they think they'll get, my trailer? The bank owns that!" Well, it seems my two week holiday might extend itself a bit. No worries there! After such a tough project I needed a break. It's time to sleep in for a while, build up those reserves. Days later an awful booming interrupted my sleep. "My god, it's not even noon!" I shouted, "go away". The door slammed open and Big Al loomed over me. "Check this out." He unwrapped the newspaper from around his BLT and handed me a section from the want ads. Yep, old Al was right on top of things again. Another startup, as usual desperate for a pair of gurus like us, no doubt willing to hire at any price. A harried president briefly interviewed the two of us, asking lots of questions about our most recent experience. We gave them the scoop on the VHF radio, but had to parry his request for references. "Sorry – they went out of business. Shame, that. There's no one there you can call. But we built a hell of a radio for those guys. It's too bad management was so screwed up they folded. Hey, it happens all the time in this industry." "But trust me on this – you need a graybeard like me to mentor your young engineers, and to get this project out now! I'm ready to start coding today. What is it we're building?" |
||||
This Week's Cool Product | ||||
Bob Paddock sent in a link to an article about a new-fangled battery. The key specs: It's SMT-compatible in an EIA 1812 package. The article doesn't list a price (a practice that is unacceptable), but Digi-Key lists these at $8.30 in small quantities. While this is an interesting part, with only 100 µAh of capacity and the relatively high cost, I'm not sure where such a part makes sense. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. Tomislav Razov sent this: Changing random stuff until your program works is "hacky" and "bad coding practice". But if you do it fast enough it is "Machine learning" and pays 4x your current salary. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor's Notes | ||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. Engineering changes at an accelerating pace. The boss wants more bug-free code, today. Tomorrow he'll want even more in the same time-frame. Are you on top of the best ways to deliver it? Some tell me they just don't have time to attend seminars. I'm reminded of this: It is important to fight today's engineering battle. But the war will be lost if you don't find better ways to win. This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends January 20. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. It's a beautiful country with great people, but a long way from my homestead in Maryland. Jack's latest blog: How I Write Code. A recent article in Electronic Design spotlights crashing DRAM and NAND prices. The latter are off 79% from their mid-2017 numbers. But a stunning graph later in the article shows that 1 GB of DRAM cost around $70k in 1991! It's around $3 today. I don't know how accurate that $70k number is, but even if it's off by an order of magnitude that shows astonishing progress in electronics over the last three decades. |
||||
Quotes and Thoughts | ||||
Coding is "90% finished" for half the total coding time. Fred Brooks |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. John Carter likes the D language, and he also included a useful link to Stroustup's and Sutter's C++ guidelines:
Interestingly, D does not support 8 or 16 bit processors. From the overview page: "No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space and supports 64 bit as well." I assume that means no MMU or MPU, which is a shame, as these resources can be useful in preventing complete system crashes. |
||||
Freebies and Discounts | ||||
This month's giveaway is a Cypress CY8KIT-044 PSoC 4 M-series Pioneer kit. Enter via this link. Percepio is giving away one-year licenses for their TraceAlyzer debugging tool. I've played with it and find it a great way to visualize how your code interacts with the RTOS (many RTOSes supported). The giveaway is not exactly free - you have to send a description of what you'll do with it, and follow-up with a story about solving the problem. More info here. I image the story could be pretty short. Not a freebie for Muse readers, but here's an astonishing giveaway: a business card that runs Linux. Production cost: $3 in low volumes. Linux for three bucks? For all the sturm and drang in the political news, sometimes we need to take a step back and just be amazed at how cool things are. Thanks for Martin Buchanan for sending the link. |
||||
New Year's Resolutions for Firmware Developers | ||||
Happy New Year! I thought it would be fun to Google for New Year's resolutions for software people. Most of the results were things like "share more," "work with the community," "contribute to open source," "cut back to one quart of whiskey per day," and the like. Nice thoughts, but what technical resolutions are worthwhile? First, I don't like aspirations like "work harder at..." That's impossible to measure. Without numbers, we're lost in a fog. Without numbers, we can't understand if we're improving. Without numbers, we don't know how we measure up against others (e.g., am I in the bottom quartile of developers?). And, as Harry Roberts demonstrates in Quality is Personal, "trying harder" rarely works. So here are some thoughts:
|
||||
Principles For Interfacing With Humans | ||||
John Carter sent an excerpt from Standard Practice for Human Engineering Design for Marine Systems, Equipment and Facilities. These notions should be embraced by all engineers. Humans are flawed, which this standard addresses explicitly. But first, a story. I read (somewhere recently, maybe in the Smithsonian's Air and Space magazine) that during WWII B-17s crashed on landing far more often than one would expect. Turns out, the gear and flaps levers were located near each other and looked similar. Tired, stressed pilots would mix up the controls. Relocating and changing the appearance eliminated those sorts of accidents. The moral: design with real people in mind. Here are the practices: 4.2 Principles of Human Behavior: 4.2.1 There are basic principles of human behavior that control or influence how each person performs in their workplace. Some of these behaviors are culturally derived, while others are general and uniform across all cultures and geographical regions of the world. These behaviors influence a person's physical, social, and psychological approach toward the work they do and how safely they do that work. Failure to satisfy these behavioral principles in the design of a ship or maritime structure can encourage, or even coerce, maritime personnel into taking unsafe risks in their everyday activities. It is, therefore, imperative that designers of ships and maritime equipment, systems, and facilities know these principles to provide a safe and efficient workplace for maritime personnel. 4.2.2 These principles include: 4.2.2.1 If the design of the ship or maritime facility is considered to be unsafe or inefficient by the crew, it will be modified by the users, often solving the initial problem but introducing others that may be as bad, or worse, than the original. 4.2.2.2 Equipment design shall be such that it encourages safe use, that is, does not provide hardware and software that can be used in an unsafe manner. 4.2.2.3 If the equipment or system is not designed to operate as the users' cultural and stereotypical expectations lead them to think that it will operate, the chance for human error is significantly increased. 4.2.2.4 If equipment or systems are perceived by operators/maintainers to be too complex or require more effort to operate or maintain than they believe is necessary, they will always look for a "shortcut." Further, this "shortcut" may be perceived as being safe when it is not. 4.2.2.5 No amount of training, company or organizational policy, threats of retaliatory action, warning notes in a technical manual or training guide, or pleading with personnel to be safe on the job can overcome poor design that encourages, leads, or even coerces personnel into unsafe acts on the job. The most efficient way to prevent unsafe design from contributing to an accident is to eliminate the unsafe design. 4.2.2.6 Equipment users tend to be very unimaginative when it comes to identifying unsafe features and they do not visualize the consequences of unsafe acts. Therefore, do not expect that an "obviously dangerous" task will always be recognized as such by every user. 4.2.2.7 Designers shall consider the possibility for human error and design equipment so that incorrect use (deliberate or accidental) will result in little or no harm to the user. 4.2.2.8 Equipment operators and maintainers tend to make guesses as to what a label, instruction, or operational chart states if it is not complete, legible, readable, and positioned correctly. 4.2.2.9 Designers and engineers shall never use themselves as the standard against which a particular design is evaluated. People come in many shapes, sizes, mental capacities, and capabilities. Therefore, design for the full range of potential users, physically, mentally, and socially. 4.2.2.10 People shall be protected against themselves. Designers cannot create an unsafe piece of equipment or system and expect the users to assume full responsibility for its safe use. 4.2.2.11 Ease of equipment maintenance affects the equipment's reliability, that is, the harder it is to be maintained, the less it will be maintained. 4.2.2.12 Equipment designed to require multiple operators working together simultaneously increases the likelihood of operator errors. 4.2.2.13 Operational/maintenance procedures shall be clear, definitive, and comprehensive, otherwise, they will be misinterpreted or ignored. 4.2.2.14 Structural items such as piping, cable trays, or any other item that appears strong enough to be used by a person to hold onto or stand on, and is placed in a convenient location to use for that purpose, will eventually be used for that purpose. 4.2.2.15 Humans expect consistency in the design and arrangement of their workplace. Therefore, if that workplace, or any part thereof, appears in more than one place in their work environment, it is expected to be located and look the same way at every location. 4.2.2.16 When controls and displays associated with particular pieces of equipment are placed on a console or control panel, they shall be located on that console or panel to replicate the actual location of the equipment on the ship or structure as both are viewed by the operator. Therefore, equipment that is to the operator's left as he/she faces the control station shall appear on the left of the control panel or console, and equipment to the right shall appear on the right side of the console or panel. This "spatial relationship" between the real world and the controls and displays that are associated with the equipments and systems of that world is extremely important in the design of ships and maritime structures. 4.2.3 Humans develop behavioral patterns based on their cultural experiences. Designing a ship or structure that ignores or violate those culturally derived behavior patterns will inevitably lead to human error. |
||||
Just How Big is a Million Lines of Code? | ||||
A million lines of code. It's a number bandied about more than ever as software sizes develop overactive pituitaries. Some cell phones use upwards of twenty million. Last year Ford announced that the F150 truck has 150 million. Everett Dirksen once may have said: "A billion here, a billion there, pretty soon you're talking real money." Well, a million lines of code here, a million there, pretty soon you're talking about a program that is as mind boggling and incomprehensible as our national debt. A million lines of code printed out would be 18,000 pages. That's a stack six feet tall (on typical 20 pound paper). Ironically, the listing weighs in at 180 pounds while the actual operating code is mass-free; it'll live in a fraction of a gram of silicon. Like DNA, code's human-readable description requires tremendously more mass than its actual instantiation. A million lines of code is probably on the order of 20 million instructions, or around half a billion bits. That's not far off of the 3 billions base pairs in human DNA. Unlike DNA, which has redundancies and so-called "junk" sequences, every single bit in the code must be perfect. A single error causes greater or lesser failure. Since a typical atom is around 0.3 nm in diameter, if one had as many atoms lined up as the number of instructions needed for a million lines of code, they would stretch 10 cm. That many Ebola viruses would stretch 15 meters. A million lines of code is as long as 14 copies of War And Peace, 25 of Ulysses, 63 copies of The Catcher in the Rye, or 66 copies of K&R's C Programming Language. A million lines of code is not ten times more than 100,000. It's well-known that schedules grow exponentially faster than the code. Barry Boehm estimates the exponent is around 1.35 for embedded software. So the schedule for developing a million lines of code is 22 times bigger than for 100,000 LOC. In the March, 1996 issue of IEEE Computer Watts Humphrey published crude rules of thumb for estimating software projects. Though hardly scientific, they do give a sense of scale. Using his estimates:
A million lines of code costs $20m to $40m. That's the cost of an F-18 jet, a thousand cars (in America), ten million gallons of gas, seven times the inflation-adjusted cost of the ENIAC, and something like ten million times the cost of the flash chips it lives in. Think about that last analogy: Ten million times the cost of the flash chips. Accounting screams over each added penny in recurring costs, while chanting the dual mantras "software is free," and "hey, it's only a software change." |
||||
This Week's Cool Product | ||||
Hex-Five Security's MultiZone product is a software layer that uses hardware to enforce high security when using untrusted code. Currently RISC-V versions are available. It's a small (under 2 KB) bit of code that is formally verifiable. That's a big selling point when pursuing a Common Criteria security standard. As I understand it, the product enforces separation zones to keep bad actors out of others' sandboxes, which sounds like the Common Criteria's separation kernels. A datasheet is here. It's free for non-commercial use. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable PI can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change. - FORTRAN manual for Xerox Computers |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor's Notes | ||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. Engineering changes at an accelerating pace. The boss wants more bug-free code, today. Tomorrow he'll want even more in the same time-frame. Are you on top of the best ways to deliver it? Some tell me they just don't have time to attend seminars. I'm reminded of this: It is important to fight today's engineering battle. But the war will be lost if you don't find better ways to win. This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends today. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. It's a beautiful country with great people, but a long way from my homestead in Maryland. Jack's latest blog: A Lack of Forethought |
||||
Quotes and Thoughts | ||||
I never give anyone hell. I only tell the truth. They think it's hell. Harry S. Truman |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. |
||||
Freebies and Discounts | ||||
This month's giveaway is a Cypress CY8KIT-044 PSoC 4 M-series Pioneer kit. Enter via this link. Brian Cuthie reports that the schematic editor/simulation software Micro-Cap is now free. See this. |
||||
On Requirements Documents | ||||
How long are your requirements documents? How complete are they? Getting hard data is notoriously difficult in the software world. Capers Jones probably has more than anyone. He stresses the large standard deviation, but makes it clear that one can gain some insight from it. I view the data as an impressionist painting, where the outlines might be fuzzy, but one can still make out the general shape of things. The following table is derived from data in Jones' The Economics of Software Quality. It shows how many pages of requirements are found for various-sized projects. The "Requirements Completeness" column illustrates all-to-pathetically how short those pages are of the delivered functionality. Jones uses function points instead of lines of code. Most of us are uncomfortable with function points, so I've converted them to lines of C code using the generally-accepted average of one FP being 130 lines of C. Playing with the numbers, for 100% completeness you'd need about one page of requirements documentation for every ten lines of code. It's not clear if a "page" means 500 words, or perhaps just a sentence or two, with perhaps each requirement standing proudly on its own page. What do your numbers look like? |
||||
More New Years Resolutions | ||||
Vlad Z sent more New Year's resolutions:
|
||||
On E-Voting | ||||
Later this year the US will chose a new president. But who will make that choice? I last wrote about electronic voting machines in the election year of 2008. Twelve years later little has changed. Vermin the world over will exploit any computer weakness to extort tens of thousands of dollars from the unsuspecting populace. Those are pretty puny stakes compared with the presidential election, which will consume billions of dollars of campaign funds and will shape the direction of the most powerful nation on the planet for at least four years. So how did we react? By acquiring voting machines with many known security flaws, developed without using best engineering practices, whose code is proprietary, and that use hacker-friendly operating systems. In effect, the government, by making these purchasing decisions, sanctioned a "we're the government, you can trust us" appeal to the electorate. Ironically, the citizenry has never trusted the government less than in recent years. We know how to build reliable software systems. We know how to build secure software systems. We decided not to. How dumb is that? Democracy is hard. We citizens have to be involved. We need to hold our elected officials accountable, and toss them out when they fail to meet our standards. That requires we trust the integrity of the ballot box. E-voting travails are not new; ballot-stuffing is as old as the Republic. The difference is that now it may be possible to stuff millions of votes with a few clicks. I believe that e-voting holds the promise of eliminating compromised elections. But not with the approaches used now. I'm sickened to read of various commissions demanding that vendors add printers to their machines. That's does nothing to prove that each vote is recorded properly. The printer could show one candidate and record another. And the voting machine itself is not the issue: it's the entire system, including the computers that hold the databases, which are even more attractive targets for bad actors. We citizens must demand a system that works. That requires the following:
Will this happen? I doubt it. Conspiracy theorists probably feel the overlords who control the government want to have hackable elections. But I suspect there's more truth in: Never ascribe to malice, that which can be explained by incompetence. |
||||
The Secret of My Success | ||||
The blue light of the TV flickered on the blank wall, but it went unnoticed by me as I slumped in my old armchair. It had been a bad week. She left on Monday, screaming that she couldn't take all of the equipment piled everywhere. Me, I thought that old Tek 545 was a collector's item, an antique. Sure, the dust was pretty bad, but you can bet we were the only couple in town with a living room populated by old scopes and CP/M machines. Yeah, I do mess up some times, like that time my homebrew furnace controller burped and drove the house to 115 degrees when we were gone for the weekend. Hey, I never liked those pets anyway, and the smell did eventually come out of the carpets. Pretty much. I mean, it was just a little software bug; we all have those! And there was the fire. Yeah, next time I'll put a bigger heat sink on the power supply. I admit it - I learned a lesson. The scorch marks on her dresses don't really look all that bad. I reached for another bag of chips as the chair groaned a bit more. One of these days I'm gonna have to work off some of the excess pounds. A decade spent in the lab drinking Jolt and munching fries had taken its toll. Despite the flab I still know calculus and can program in C; surely a dream dude for any discerning woman. I bet I could wow them at the local watering hole with my great stories about TCP/IP! Well, this is Silicon Valley after all, where relationships, jobs and careers are measured in milliseconds and loyalty doled out by the microgram. Electronics is a dog-eat-dog business and I'm an old hand at crawling out from the wreckage. Like that last startup I worked for. I told 'em we'd get that product out the door, eventually anyway. We woulda survived if that idiot president just got another couple of mil of venture capital. For a while at least. Ya know, maybe it was losing that job that ticked her off. I figure, what's the big deal? She should be used to this by now. Check out my resume - it shows lots of experience at lots of places. No one can beat this! I picked up the phone but heard only the accusing silence of a non-payment disconnection. No matter. Time to find another company looking for my embedded expertise. There's a startup a minute here, pigeons ripe for picking. I clumped out of the trailer's front door and found Big Al, the usual wild look in his eyes, mouth working hard on this morning's sugar raised, the white powder spotting his beard. "Al, buddy, you're outa work too, huh? How's the wife and kids?" "Kids? Kids? Yeah, come to think of it I did notice some little people living with me. I wonder where they came from? Check this out." With that he shoved a coffee-stained fragment of the San Jose Mercury News into my hands. I quickly took in the circled want ad. "ENGINEERs – microprocessor savvy designers and programmers needed. C, FPGAs, assembly a plus. Exciting opportunity for a motivated developers in a new high-growth company." A slow smile spread across my face. Here was our pigeon; I was already mentally spending the signing bonus. That afternoon, T-shirts cleaned and pressed, with most of the donut detritus hurriedly wiped from Al's beard, we met with the president of Galaxar Enterprises. Yep, just as usual, this man was the typical harried executive desperate for people, so desperate he had neither the time nor resources to do much of a background check. Not that my background is so terrible; it's just that there's so much of it. "You know C? Schematic capture? What's the last project you worked on?" he mumbled, looking at his watch while the cell pinged an urgent tune. "We did that Internet cappuccino maker for Kitchen Services; you must have read about it in the press. Yep, that puppy had a RISC-V based coffee engine with 10 gigs of RAM…" "Didn't they go Chapter 7?", he interrupted, interested now. "Trust me on this. The boss was an idiot. He just didn't understand how much compute power we needed to blend the perfect cuppa joe. That sucker could crank some coffee, believe me. If they hadn't been so stuck on the cost of goods we coulda cleaned up the cappuccino market. We were practically done with development when the SEC raided us." "OK, OK, look, when can you start? Now? Don't you guys ever shave? Hell, just sit here and Bob will tell you what to do." Bob, engineering VP, was one of those snotty-nosed brats with a degree and an attitude. "We're building a new marine VHF radio for the recreational boating market. That means there are three main design parameters. First, the unit must be totally sealed to insure it's waterproof. Second, the sell price can't exceed $250. And obviously the unit must be simple enough that even the most casual boater can use it." He went on to tell us how we were going to design the product. Us! Can you imagine? As if I don't understand project planning, structured design, discipline design, and all of that utter crap. Me, I prefer to skip all of that non-productive nonsense and just bang it out. I zoned out, the drone of Bob's voice barely noticeable, nodding at the right time while planning my next move. Clearly it was time for the old end-run. Saturday night Al and I marched into the president's office. "Herb," I started, "we know you're running out of venture money and an IPO is at least a year away. Bob's planning to spend another three months just doing preliminary design. Whatdoya want, a design or a product? Trust me on this – we can pound out a design in a week, max, and then get the radio done in no time." Herb's eyes gleamed. It seems that he, too, was frustrated by Bob's methodical approach to engineering. This valley is the land of Steve Jobs, where unbridled passion and hope fuels the dream of tomorrow's big score. Discipline? Bah. Just lemme at a problem and I'll get it done. With a bit more prodding Herb agreed that this project was so important he'd give it skunk-works treatment, get Bob off of our backs, and let us report directly to his president's office. The week sped by like a read from cache memory. Al slouched into my cubicle, let out a long, satisfying-sounding belch, and asked "didn't we promise Herb a spec or something?" Right! Never let the boss, down, that's my motto. Unless there's a good reason, of course. "Sure, look, just grab those header files we've been working on and edit a bit of descriptive stuff at the beginning. They'll never read it all anyway. If he complains we'll tell 'em not only is the spec done, we've incorporated it into the firmware. How can he get upset if he sees we're already coding?" Herb swallowed our header files hook, line and sinker. He's thrilled that we're already cranking out software, and giddily reported our progress to the venture capitalists. I think they're already mentally spending their IPO profits. Bob is muttering vague threats, but he's been squeezed into the user-interface group. He wants Al and I to take on that new college grad, Marty. We're supposed to show him how to get projects done. It's not all bad; the kid has a car so can get us beers and carry-out. The secret to success in this business is to look busy, keep a prototype in a state that looks like it has some level of functionality, and always agree with the boss. And you can't act like you have a personal life when battling a schedule! Heck, after just three days on the job Marty asked if he could leave at 5 to celebrate his first anniversary. I straightened him out. "Kid, trust me on this. We all go through one or two starter marriages, you know, no kids, no property, no regrets. Don't take it too seriously. Now let's order a pizza and get back to work." It was probably a good thing that I turned off the switchboard that night, so he wouldn't get distracted by all of those frantic calls from home. And that kid did need some attention. I caught him late one night doing a spell check on his comments! Somehow he missed the fact that a ship date loomed; comments are always the first thing to go. "Kid, trust me on this. Never include a comment that will help someone else understand your code. If they understand it, they don't need you." I think he gets the picture now. As time moved on we started having trouble fitting the binary image into the CPU's address space. "This always happens", I reassured Herb, "them 16 bitters just can't handle the sort of code we're cranking out for you. Look, we'll just stuff a bigger part in there this afternoon. No problemo; I've done this a million times." Big Al's eyes lit up when I suggested we look into a 64 bit processor. "I've got just the ticket. There's one I've been itching to try; it's totally reconfigurable, you can even define your own instruction set. Man, this is gonna look great on my resume!" Ah, resume fodder, the grease of the industry. Herb didn't seem to concerned about the increased cost of goods – at least he wasn't asking any questions – so I set out trying to find some way to cool the sucker. With luck a big old heat sink and decent-sized fan might be adequate. Jeez, maybe I'll use the next size up; those burnt dresses still haunt me at times. We optimized the instruction set on the CPU to play DoomStar III at awesome speeds. The best part of using a custom architecture was that I got to port the entire GNU toolchain to our chip. That compiler sure is tricky! First time I'd ever fiddled with a code generator, so it naturally took a bit longer than planned to get working – mostly – tools. As the weeks passed Herb got noticeably more antsy, checking on our progress on a daily, and then hourly, basis. This always happens, and is a sign that the old cash reserve is evaporating. I started running to the bank the minute paychecks came out. No one's gonna stick me with bouncing paper! Been there, done that. Bob – remember Bob? – strolled into the lab one afternoon to check on our progress. It seems the fool had actually invested his own money into the company! He's correspondingly annoying about what we do, even though my end-run had gotten him off the project months before. Oddly, he seemed upset about the cooling fan. "This thing has got to be totally sealed, so no water gets in!" he whined. "Yeah, yeah, just mount it in a dry place or something", I replied. "I can't be bothered with that sort of stuff. You know how much power this sucker uses?" These company men are all stress puppies. Not me; I'll be going strong when he suffers his first mid-30s myocardial infarction. Christmas rolled around – or was it Easter? I dunno, we were plenty busy chasing down bugs and making feature changes. Bob's paycheck bounced. I knew that Herb had been doing some fancy footwork to keep things afloat, but when everyone in accounting quit, complaining about insolvency or something, the standard exodus began. As usual, engineering remained untouched by the various rounds of layoffs. They needed the products we make to survive. I love this field! This seemed like a great time for a two week vacation, though Marty seemed almost hysterical that I'd take off now. "Kid, trust me on this. Never complete a project on time. If you do, they will think it was easy and anyone can do it and they don't need you. Now I'm outa here for a while. Look busy and we'll sort it all out when I get back." I got back, more or less sober but feeling great, to find the front door padlocked and a sheriff standing guard. Marty, skulking in a dark corner, grabbed my arm and moaned that he couldn't build the code at all while I was away. It seems he had trouble locating all of the source. "Kid, trust me on this. Never archive all the sources necessary to build a binary. Always hide a few on your own disk. If they can build your binary, they don't need you. What do they teach you in college, anyway?" He said the creditors got fed up and were demanding their money. Half the employees were suing because their paychecks bounced. A satisfied grin spread across my face as I recalled beating the rest of those idiots to the bank. Marty shrieked that Herb was suing all of us in engineering for not meeting promised dates, specs, or features. "Kid, trust me on this. They always sue. That's why I own nothing. What do they think they'll get, my trailer? The bank owns that!" Well, it seems my two week holiday might extend itself a bit. No worries there! After such a tough project I needed a break. It's time to sleep in for a while, build up those reserves. Days later an awful booming interrupted my sleep. "My god, it's not even noon!" I shouted, "go away". The door slammed open and Big Al loomed over me. "Check this out." He unwrapped the newspaper from around his BLT and handed me a section from the want ads. Yep, old Al was right on top of things again. Another startup, as usual desperate for a pair of gurus like us, no doubt willing to hire at any price. A harried president briefly interviewed the two of us, asking lots of questions about our most recent experience. We gave them the scoop on the VHF radio, but had to parry his request for references. "Sorry – they went out of business. Shame, that. There's no one there you can call. But we built a hell of a radio for those guys. It's too bad management was so screwed up they folded. Hey, it happens all the time in this industry." "But trust me on this – you need a graybeard like me to mentor your young engineers, and to get this project out now! I'm ready to start coding today. What is it we're building?" |
||||
This Week's Cool Product | ||||
Bob Paddock sent in a link to an article about a new-fangled battery. The key specs: It's SMT-compatible in an EIA 1812 package. The article doesn't list a price (a practice that is unacceptable), but Digi-Key lists these at $8.30 in small quantities. While this is an interesting part, with only 100 µAh of capacity and the relatively high cost, I'm not sure where such a part makes sense. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. Tomislav Razov sent this: Changing random stuff until your program works is "hacky" and "bad coding practice". But if you do it fast enough it is "Machine learning" and pays 4x your current salary. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor's Notes | ||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. I'll present the Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here. Please note that the seminar is nearly full. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. It's a beautiful country with great people, but a long way from my homestead in Maryland. |
||||
Quotes and Thoughts | ||||
Software specifications and documentation are often an afterthought, and the development of requirements after the design is created is sometimes even touted as a benefit or necessity. This simply isn't true for safety-critical software where the loss might involve not only human life but physical property, critical mission loss, and damage to the environment. It should be considered malpractice for software to be created before the safety requirements are identified. - Nancy Leveson |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. |
||||
The Futility of Testing | ||||
The next article is a review of a debugger that includes code coverage, which insures every statement and even every instruction in a program gets tested. However test is simply not adequate to insure an application is correct. Test does nothing to evaluate the correctness and completeness of the requirements, for example. But absent coverage, it's impossible to know if all of the code has been evaluated. A big project may have so many possible paths that insuring 100% coverage could be a huge effort. In The Software Quality Challenge by the brilliant and sadly-deceased Watts Humphrey, published in the also sadly-deceased CrossTalk magazine (June 2008), Humphrey shows that the number of paths (and therefore required tests) a program can take depends on the quantity of decisions contained. Here's his results: His analysis is based on an extreme assumption that every branch is likely to affect every other. However, the numbers are stunning and thought-provoking. One takeaway is that it's incredibly important to decouple modules as much as possible so Humprey's assumption (every branch is likely to affect every other) doesn't haunt our efforts. He goes on to graph pre-test error rates for 810 experienced developers: (Note that test finds only about half of all defects, a result consistent with many other studies). |
||||
A Review of SEGGER's J-Trace and Ozone | ||||
I generally don't do traditional reviews of software, as most software tools have a vast number of features. However, I do make general observations about these tools, which is what follows for SEGGER's J-Trace Pro and their "Ozone" debugger. First, full disclosure: SEGGER places paid ads in the Muse and on my web site. The J-Trace Pro I evaluated is for Cortex-M/A/R, processors. The motivation for these observations started at last summer's Embedded Systems Show in California. I was walking past SEGGER's booth and saw a demo of their coverage feature (which shows the lines of code that were executed). While I think measuring coverage is important, it's also problematic as most tools instrument the code. For line-by-line coverage that can add a lot of overhead, undesirable in a real-time system. I inquired and was told SEGGER's version adds no overhead. It's measured by watching the real-time trace data supplied by the Arm processor. That's a bit of a game changer. Part of the problem with usual test regimens is that they are usually incomplete; one just doesn't know if the entire program was exercised. With coverage that ambiguity goes away. While coverage alone doesn't prove the code is correct, it does show that everything was at least executed. That is mandated by the most demanding standards, like the highest category of avionics testing. (The recent 737-MAX woes also demonstrate that test alone is inadequate). SEGGER's J-Trace is a hardware debugging probe. While it works with IDEs from many other vendors, for my testing I used SEGGER's Ozone debugger program. The package costs $2498 and is currently available. A Cortex-M only (no -A or -R processors) is $1748. Installation of Ozone and starting the demo on the supplied Cortex-M4 demo board took only a few minutes and was brain-dead easy. The demo program is a simple two-task LED blinker using the company's embOS RTOS. Ozone appears to have SEGGER's SystemView monitor (I reviewed it in TEM299) program integrated. There are so many useful windows in Ozone that you'll want a big monitor. Mine is 24" and I wouldn't want anything less. The application appears deceptively simple when first opened. File, View, Find, Debug, Tools, Window and Help are the only pull-down menu items; with the exception of the View menu, each of those pull-downs has only a few entries. It's mostly controlled via a vast number of right-click context-sensitive items. Ozone is very flexible in letting you add buttons to the toolbar, and I suspect that after a few minutes using it you'll add your favorite actions to reduce two clicks to one. Here are my observations:
![]() There's much more in the Ozone/J-Trace tool. The above comes from reading the first 135 pages of the 312 page manual; I simply ran out of time. The manual is pretty complete but I felt it's hard to use; it needs more examples of using the features. And there are a lot of forward references which can make understanding a feature a bit difficult. The manual is arranged in alphabetical order of the windows which means some complex ideas are introduced before the basics. Ozone is extremely responsive, and I encountered no notable delays. Click on this short video to see how quickly things are updated as I slew the cursor around: The application is pretty intuitive, though there are so many features you'll want to curl up with the manual. Did I say feature-rich? I can't think of anything extra we'd want in a debugger other than the mythical "find bug" and "fix bug" buttons. A very important feature is that acquired data can be exported to a file. That's crucial in many safety-critical projects where regulatory agencies require proof about testing completeness. And it's valuable to QA departments as well. Examples of exportable data include code coverage, count of statements executed, register, variable and even expression results. In the 1980s and 90s I ran a company that made In-Circuit Emulators. These were debugging tools that offered tons of features that all ran in real-time. The ICE business imploded early this century for a number of reasons, but the death knell was that they just couldn't keep up with emerging fast clock rates. The embedded community then regressed to simpler debugging probes which were inexpensive, but feature-poor. Ironically, our applications were growing in complexity yet our tools fell behind. The J-Trace has gone beyond what ICEs could do. I'm very impressed. You can find an overview of the J-Trace Pro and a tutorial about using it here. |
||||
Final Thoughts on New Year's Resolutions | ||||
Wouter van Ooijen has thoughts about C++"
Finally, Capers Jones published Twenty Five Software Engineering Targets from 2015 Through 2019 five years ago. These aspirational goals might make a basis for New Year's resolutions. I disagree with some of these, and many, while as desirable as a resolution to achieve world peace, are about as hard to attain. (Jones uses function points, each of which is about 130 lines of C.) His yearning to reach measurable goals is praiseworthy:
The full paper with his reasoning behind each goal can be found here (registration required). |
||||
This Week's Cool Product | ||||
Not quite yet a product, but for ultra-low-power products, why not use the triboelectric current from falling snow? Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor's Notes | ||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. I'll present the Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here. Please note that the seminar is nearly full. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. It's a beautiful country with great people, but a long way from my homestead in Maryland. |
||||
Quotes and Thoughts | ||||
Software specifications and documentation are often an afterthought, and the development of requirements after the design is created is sometimes even touted as a benefit or necessity. This simply isn't true for safety-critical software where the loss might involve not only human life but physical property, critical mission loss, and damage to the environment. It should be considered malpractice for software to be created before the safety requirements are identified. - Nancy Leveson |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. |
||||
The Futility of Testing | ||||
The next article is a review of a debugger that includes code coverage, which insures every statement and even every instruction in a program gets tested. However test is simply not adequate to insure an application is correct. Test does nothing to evaluate the correctness and completeness of the requirements, for example. But absent coverage, it's impossible to know if all of the code has been evaluated. A big project may have so many possible paths that insuring 100% coverage could be a huge effort. In The Software Quality Challenge by the brilliant and sadly-deceased Watts Humphrey, published in the also sadly-deceased CrossTalk magazine (June 2008), Humphrey shows that the number of paths (and therefore required tests) a program can take depends on the quantity of decisions contained. Here's his results: His analysis is based on an extreme assumption that every branch is likely to affect every other. However, the numbers are stunning and thought-provoking. One takeaway is that it's incredibly important to decouple modules as much as possible so Humprey's assumption (every branch is likely to affect every other) doesn't haunt our efforts. He goes on to graph pre-test error rates for 810 experienced developers: (Note that test finds only about half of all defects, a result consistent with many other studies). |
||||
A Review of SEGGER's J-Trace and Ozone | ||||
I generally don't do traditional reviews of software, as most software tools have a vast number of features. However, I do make general observations about these tools, which is what follows for SEGGER's J-Trace Pro and their "Ozone" debugger. First, full disclosure: SEGGER places paid ads in the Muse and on my web site. The J-Trace Pro I evaluated is for Cortex-M/A/R, processors. The motivation for these observations started at last summer's Embedded Systems Show in California. I was walking past SEGGER's booth and saw a demo of their coverage feature (which shows the lines of code that were executed). While I think measuring coverage is important, it's also problematic as most tools instrument the code. For line-by-line coverage that can add a lot of overhead, undesirable in a real-time system. I inquired and was told SEGGER's version adds no overhead. It's measured by watching the real-time trace data supplied by the Arm processor. That's a bit of a game changer. Part of the problem with usual test regimens is that they are usually incomplete; one just doesn't know if the entire program was exercised. With coverage that ambiguity goes away. While coverage alone doesn't prove the code is correct, it does show that everything was at least executed. That is mandated by the most demanding standards, like the highest category of avionics testing. (The recent 737-MAX woes also demonstrate that test alone is inadequate). SEGGER's J-Trace is a hardware debugging probe. While it works with IDEs from many other vendors, for my testing I used SEGGER's Ozone debugger program. The package costs $2498 and is currently available. A Cortex-M only (no -A or -R processors) is $1748. Installation of Ozone and starting the demo on the supplied Cortex-M4 demo board took only a few minutes and was brain-dead easy. The demo program is a simple two-task LED blinker using the company's embOS RTOS. Ozone appears to have SEGGER's SystemView monitor (I reviewed it in TEM299) program integrated. There are so many useful windows in Ozone that you'll want a big monitor. Mine is 24" and I wouldn't want anything less. The application appears deceptively simple when first opened. File, View, Find, Debug, Tools, Window and Help are the only pull-down menu items; with the exception of the View menu, each of those pull-downs has only a few entries. It's mostly controlled via a vast number of right-click context-sensitive items. Ozone is very flexible in letting you add buttons to the toolbar, and I suspect that after a few minutes using it you'll add your favorite actions to reduce two clicks to one. Here are my observations:
![]() There's much more in the Ozone/J-Trace tool. The above comes from reading the first 135 pages of the 312 page manual; I simply ran out of time. The manual is pretty complete but I felt it's hard to use; it needs more examples of using the features. And there are a lot of forward references which can make understanding a feature a bit difficult. The manual is arranged in alphabetical order of the windows which means some complex ideas are introduced before the basics. Ozone is extremely responsive, and I encountered no notable delays. Click on this short video to see how quickly things are updated as I slew the cursor around: The application is pretty intuitive, though there are so many features you'll want to curl up with the manual. Did I say feature-rich? I can't think of anything extra we'd want in a debugger other than the mythical "find bug" and "fix bug" buttons. A very important feature is that acquired data can be exported to a file. That's crucial in many safety-critical projects where regulatory agencies require proof about testing completeness. And it's valuable to QA departments as well. Examples of exportable data include code coverage, count of statements executed, register, variable and even expression results. In the 1980s and 90s I ran a company that made In-Circuit Emulators. These were debugging tools that offered tons of features that all ran in real-time. The ICE business imploded early this century for a number of reasons, but the death knell was that they just couldn't keep up with emerging fast clock rates. The embedded community then regressed to simpler debugging probes which were inexpensive, but feature-poor. Ironically, our applications were growing in complexity yet our tools fell behind. The J-Trace has gone beyond what ICEs could do. I'm very impressed. You can find an overview of the J-Trace Pro and a tutorial about using it here. |
||||
Final Thoughts on New Year's Resolutions | ||||
Wouter van Ooijen has thoughts about C++"
Finally, Capers Jones published Twenty Five Software Engineering Targets from 2015 Through 2019 five years ago. These aspirational goals might make a basis for New Year's resolutions. I disagree with some of these, and many, while as desirable as a resolution to achieve world peace, are about as hard to attain. (Jones uses function points, each of which is about 130 lines of C.) His yearning to reach measurable goals is praiseworthy:
The full paper with his reasoning behind each goal can be found here (registration required). |
||||
This Week's Cool Product | ||||
Not quite yet a product, but for ultra-low-power products, why not use the triboelectric current from falling snow? Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor's Notes | ||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. Engineering changes at an accelerating pace. The boss wants more bug-free code, today. Tomorrow he'll want even more in the same time-frame. Are you on top of the best ways to deliver it? Some tell me they just don't have time to attend seminars. I'm reminded of this: It is important to fight today's engineering battle. But the war will be lost if you don't find better ways to win. This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends January 20. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia. It's a beautiful country with great people, but a long way from my homestead in Maryland. Jack's latest blog: How I Write Code. A recent article in Electronic Design spotlights crashing DRAM and NAND prices. The latter are off 79% from their mid-2017 numbers. But a stunning graph later in the article shows that 1 GB of DRAM cost around $70k in 1991! It's around $3 today. I don't know how accurate that $70k number is, but even if it's off by an order of magnitude that shows astonishing progress in electronics over the last three decades. |
||||
Quotes and Thoughts | ||||
Coding is "90% finished" for half the total coding time. Fred Brooks |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. John Carter likes the D language, and he also included a useful link to Stroustup's and Sutter's C++ guidelines:
Interestingly, D does not support 8 or 16 bit processors. From the overview page: "No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space and supports 64 bit as well." I assume that means no MMU or MPU, which is a shame, as these resources can be useful in preventing complete system crashes. |
||||
Freebies and Discounts | ||||
This month's giveaway is a Cypress CY8KIT-044 PSoC 4 M-series Pioneer kit. Enter via this link. Percepio is giving away one-year licenses for their TraceAlyzer debugging tool. I've played with it and find it a great way to visualize how your code interacts with the RTOS (many RTOSes supported). The giveaway is not exactly free - you have to send a description of what you'll do with it, and follow-up with a story about solving the problem. More info here. I image the story could be pretty short. Not a freebie for Muse readers, but here's an astonishing giveaway: a business card that runs Linux. Production cost: $3 in low volumes. Linux for three bucks? For all the sturm and drang in the political news, sometimes we need to take a step back and just be amazed at how cool things are. Thanks for Martin Buchanan for sending the link. |
||||
New Year's Resolutions for Firmware Developers | ||||
Happy New Year! I thought it would be fun to Google for New Year's resolutions for software people. Most of the results were things like "share more," "work with the community," "contribute to open source," "cut back to one quart of whiskey per day," and the like. Nice thoughts, but what technical resolutions are worthwhile? First, I don't like aspirations like "work harder at..." That's impossible to measure. Without numbers, we're lost in a fog. Without numbers, we can't understand if we're improving. Without numbers, we don't know how we measure up against others (e.g., am I in the bottom quartile of developers?). And, as Harry Roberts demonstrates in Quality is Personal, "trying harder" rarely works. So here are some thoughts:
|
||||
Principles For Interfacing With Humans | ||||
John Carter sent an excerpt from Standard Practice for Human Engineering Design for Marine Systems, Equipment and Facilities. These notions should be embraced by all engineers. Humans are flawed, which this standard addresses explicitly. But first, a story. I read (somewhere recently, maybe in the Smithsonian's Air and Space magazine) that during WWII B-17s crashed on landing far more often than one would expect. Turns out, the gear and flaps levers were located near each other and looked similar. Tired, stressed pilots would mix up the controls. Relocating and changing the appearance eliminated those sorts of accidents. The moral: design with real people in mind. Here are the practices: 4.2 Principles of Human Behavior: 4.2.1 There are basic principles of human behavior that control or influence how each person performs in their workplace. Some of these behaviors are culturally derived, while others are general and uniform across all cultures and geographical regions of the world. These behaviors influence a person's physical, social, and psychological approach toward the work they do and how safely they do that work. Failure to satisfy these behavioral principles in the design of a ship or maritime structure can encourage, or even coerce, maritime personnel into taking unsafe risks in their everyday activities. It is, therefore, imperative that designers of ships and maritime equipment, systems, and facilities know these principles to provide a safe and efficient workplace for maritime personnel. 4.2.2 These principles include: 4.2.2.1 If the design of the ship or maritime facility is considered to be unsafe or inefficient by the crew, it will be modified by the users, often solving the initial problem but introducing others that may be as bad, or worse, than the original. 4.2.2.2 Equipment design shall be such that it encourages safe use, that is, does not provide hardware and software that can be used in an unsafe manner. 4.2.2.3 If the equipment or system is not designed to operate as the users' cultural and stereotypical expectations lead them to think that it will operate, the chance for human error is significantly increased. 4.2.2.4 If equipment or systems are perceived by operators/maintainers to be too complex or require more effort to operate or maintain than they believe is necessary, they will always look for a "shortcut." Further, this "shortcut" may be perceived as being safe when it is not. 4.2.2.5 No amount of training, company or organizational policy, threats of retaliatory action, warning notes in a technical manual or training guide, or pleading with personnel to be safe on the job can overcome poor design that encourages, leads, or even coerces personnel into unsafe acts on the job. The most efficient way to prevent unsafe design from contributing to an accident is to eliminate the unsafe design. 4.2.2.6 Equipment users tend to be very unimaginative when it comes to identifying unsafe features and they do not visualize the consequences of unsafe acts. Therefore, do not expect that an "obviously dangerous" task will always be recognized as such by every user. 4.2.2.7 Designers shall consider the possibility for human error and design equipment so that incorrect use (deliberate or accidental) will result in little or no harm to the user. 4.2.2.8 Equipment operators and maintainers tend to make guesses as to what a label, instruction, or operational chart states if it is not complete, legible, readable, and positioned correctly. 4.2.2.9 Designers and engineers shall never use themselves as the standard against which a particular design is evaluated. People come in many shapes, sizes, mental capacities, and capabilities. Therefore, design for the full range of potential users, physically, mentally, and socially. 4.2.2.10 People shall be protected against themselves. Designers cannot create an unsafe piece of equipment or system and expect the users to assume full responsibility for its safe use. 4.2.2.11 Ease of equipment maintenance affects the equipment's reliability, that is, the harder it is to be maintained, the less it will be maintained. 4.2.2.12 Equipment designed to require multiple operators working together simultaneously increases the likelihood of operator errors. 4.2.2.13 Operational/maintenance procedures shall be clear, definitive, and comprehensive, otherwise, they will be misinterpreted or ignored. 4.2.2.14 Structural items such as piping, cable trays, or any other item that appears strong enough to be used by a person to hold onto or stand on, and is placed in a convenient location to use for that purpose, will eventually be used for that purpose. 4.2.2.15 Humans expect consistency in the design and arrangement of their workplace. Therefore, if that workplace, or any part thereof, appears in more than one place in their work environment, it is expected to be located and look the same way at every location. 4.2.2.16 When controls and displays associated with particular pieces of equipment are placed on a console or control panel, they shall be located on that console or panel to replicate the actual location of the equipment on the ship or structure as both are viewed by the operator. Therefore, equipment that is to the operator's left as he/she faces the control station shall appear on the left of the control panel or console, and equipment to the right shall appear on the right side of the console or panel. This "spatial relationship" between the real world and the controls and displays that are associated with the equipments and systems of that world is extremely important in the design of ships and maritime structures. 4.2.3 Humans develop behavioral patterns based on their cultural experiences. Designing a ship or structure that ignores or violate those culturally derived behavior patterns will inevitably lead to human error. |
||||
Just How Big is a Million Lines of Code? | ||||
A million lines of code. It's a number bandied about more than ever as software sizes develop overactive pituitaries. Some cell phones use upwards of twenty million. Last year Ford announced that the F150 truck has 150 million. Everett Dirksen once may have said: "A billion here, a billion there, pretty soon you're talking real money." Well, a million lines of code here, a million there, pretty soon you're talking about a program that is as mind boggling and incomprehensible as our national debt. A million lines of code printed out would be 18,000 pages. That's a stack six feet tall (on typical 20 pound paper). Ironically, the listing weighs in at 180 pounds while the actual operating code is mass-free; it'll live in a fraction of a gram of silicon. Like DNA, code's human-readable description requires tremendously more mass than its actual instantiation. A million lines of code is probably on the order of 20 million instructions, or around half a billion bits. That's not far off of the 3 billions base pairs in human DNA. Unlike DNA, which has redundancies and so-called "junk" sequences, every single bit in the code must be perfect. A single error causes greater or lesser failure. Since a typical atom is around 0.3 nm in diameter, if one had as many atoms lined up as the number of instructions needed for a million lines of code, they would stretch 10 cm. That many Ebola viruses would stretch 15 meters. A million lines of code is as long as 14 copies of War And Peace, 25 of Ulysses, 63 copies of The Catcher in the Rye, or 66 copies of K&R's C Programming Language. A million lines of code is not ten times more than 100,000. It's well-known that schedules grow exponentially faster than the code. Barry Boehm estimates the exponent is around 1.35 for embedded software. So the schedule for developing a million lines of code is 22 times bigger than for 100,000 LOC. In the March, 1996 issue of IEEE Computer Watts Humphrey published crude rules of thumb for estimating software projects. Though hardly scientific, they do give a sense of scale. Using his estimates:
A million lines of code costs $20m to $40m. That's the cost of an F-18 jet, a thousand cars (in America), ten million gallons of gas, seven times the inflation-adjusted cost of the ENIAC, and something like ten million times the cost of the flash chips it lives in. Think about that last analogy: Ten million times the cost of the flash chips. Accounting screams over each added penny in recurring costs, while chanting the dual mantras "software is free," and "hey, it's only a software change." |
||||
This Week's Cool Product | ||||
Hex-Five Security's MultiZone product is a software layer that uses hardware to enforce high security when using untrusted code. Currently RISC-V versions are available. It's a small (under 2 KB) bit of code that is formally verifiable. That's a big selling point when pursuing a Common Criteria security standard. As I understand it, the product enforces separation zones to keep bad actors out of others' sandboxes, which sounds like the Common Criteria's separation kernels. A datasheet is here. It's free for non-commercial use. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable PI can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change. - FORTRAN manual for Xerox Computers |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor's Notes | ||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. In another blow for Boeing, 737-NG aircraft can't land going west. If the runway is facing 270 degrees (true) all six display units blank. Happily, there are only 7 such runways in the world. FAA Airworthiness Directive here. Dave Gutow won last month's contest, for a PSoC dev kit. There's no contest this month due to a few weeks of travel. Stay tuned for March's giveaway. |
||||
Quotes and Thoughts | ||||
From Eric Smith: My favorite quote regarding programming languages in general is C.A.R. Hoare on Algol 60: "Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors." |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Brian Cuthie likes Visual Studio Code and the Saleae logic analyzer:
Tomasz Kos wrote:
We've made some improvements to our tools page, which is comprised of short reviews and comments of various hardware and software tools we embedded people use. |
||||
On Management | ||||
The voice on the other end of the phone was quiet, furtive. In guarded tones "Joe" recounted the sordid details of his story, as if I were an investigative reporter. "I can send you documents, copies of our listings, memos, you name it", he murmured. He worked for a small under-capitalized firm which was intolerant of any sort of failure. Joe's boss had a rule: software bugs were unacceptable. At first I mistakenly assumed he meant delivered products were to be defect-free, a noble goal I'd hope we all share. "Nah, we're not allowed to do any debugging," he almost whispered. "The boss says we've got to write code correctly the first time, and he's not spending any money on fixing our mistakes. So there are no tools and we all work OT to fix problems." I was reminded of my teenaged technician years, when the QA manager decreed that we were to replace only defective components, under threat of dismissal. From time to time we techs screwed up, of course, removing parts that in fact were just fine. Since Mr. QA had us send all of these extracted components to an outside lab for failure analysis, we learned to manually fry those that we had replaced in error. His in-basket consequently received some quite puzzling failure reports from the lab. Once I killed as op amp in a metal can by applying 110 VAC to the leads. It blew a hole through the can. I never saw the failure analysis for that part but imagine much head-scratching ensued. Part of me wanted to believe that Joe's boss was a man of deep insight, who had created a dynamic development environment where the product was so well designed all - or most - bugs disappeared before test started. Unhappily the man was as capricious as my old QA tormentor, as he mandated a terribly difficult goal without providing any system or framework in which to achieve it. Developers almost universally complain about managers, for good reasons and bad. The number one complaint I hear is about fickle decision making. Schedules with imposed end-dates, or those arbitrarily revised. Disappearing resources. Marketing overrides very real technical requirements, and even impose plainly impossible technical goals. Too many of today's bosses are often preoccupied with generating reports, preparing for shows, and endlessly meeting with vendors. Though these are important roles, managers have two critical functions that are often neglected. First, managers must manage. This means tracking the day by day, week by week progress of an engineering effort, which presumes there's an honest schedule which forms the project's roadmap. When something changes - and things always change - then an effective manager revises the roadmap. Management means acting as a buffer between the doers and upper level decision makers, insulating developers from distractions from on high, and waging battles to secure needed resources. Management means looking forward and anticipating changes and problems, clearing minor potholes before they become roadblocks. When disaster strikes it means working with the team to find reasonable solutions, and negotiating with the manager's superiors to adapt to the new realities, without imposing impossible requirements on the development team. But there's another aspect to proactive management. Your boss is immediately tasked with building a product, but much more important his role is to create an effective, constantly improving, way of building products. Keep your shoulder to the grindstone and you will eventually fail. Truly enlightened managers transcend an incessant focus on "shipping the damn thing now" to look a year or more ahead, and to develop the skills and technologies that will surely be required. This is an extension to the philosophy promoted in The E-Myth Revisited by Michael Gerber, one of the better books around for people building businesses. Gerber suggests that too many small companies (and by extension, engineering departments) fail because the leader spends too much time doing productive work, and not enough time inventing a company (department) that does better work in less time. We've all discovered a tool that could save us weeks of effort, but being trapped by an impossible deadline we feel we can't spend time to install and learn how to use it. Then there's us. I've observed that all too many developers seem to reach the zenith of their abilities in college. Yes, building real products in industry hones our skills though repetitive practice, but the raw knowledge of how we should design systems and write code seems cast in concrete when the diploma arrives. How many engineers over 30 ever truly master a new concept like OOP or UML? For every success story there are too many who stayed locked into the concepts with which they have long been comfortable. We can acquire new skills only by dint of struggle and practice. With today's development effort always overwhelming every other consideration it's no surprise we careen from project to project with little chance to improve. Home life gets ever more complicated with time; children and spouses require attention that detracts from after-hours study opportunities. Yet this field changes daily. Those not changing with the times are doomed to professional lives in ever more restrictive corners of the field. My dad told a story of a mechanical engineer he knew in the 1960s who was the world's expert at designing wheels for lunar roving vehicles. Surely that poor fellow became unemployable during the engineering crash of the early 70s. We should take charge of our own careers, and manage those careers aggressively. Figure out what you need to know, and then take action. But managers, too, must enhance their peoples' skill sets. A manager's most expensive resource is his or her people. Let them stagnate and the entire team will degrade. We know how to improve software development. The Capability Maturity Model (CMM) is one such process. Though the CMM is no panacea, it does describe a disciplined way to create software products in a predictable manner: predictable bug rates, predictable schedules, and the like. Like ISO9000, the CMM requires a major commitment from management as it changes the nature of the entire organization. Effective? Yep. Hard? You bet. In my opinion software development is so hard that we need every asset possible to help us. Pursuing the CMM is one strategy. Another is Watts Humphrey's Personal Software Process (PSP). Where the CMM requires a total management buy-in from the top down, the PSP is an approach individuals and small teams can use. Yet when I talk to firmware developers just about 0% work for a company pursuing the CMM. Another 0% know anything about the PSP. Managers must manage their people's skills. They've got to cajole, plead, push and order their folks to study these and other ideas to improve. Stagnation is death. And we need to learn from our mistakes. There is no industry I admire more for their management of failure than the commercial airplane business. Every crash brings out an army of investigators who are tasked with finding the accident's cause. The planes themselves are equipped with the notorious "black boxes", tools designed to record and report the parameters that lead up to the crash. When possible, investigators recommend changes in training, documentation or plane design so the chances of a similar problem will be reduced. In other words, the system has a built-in learning process which is highly targeted towards making changes Why don't we work as hard to learn from our mistakes? Failure will always be part of doing anything difficult. We'll miss schedules, deliver products whose quality falls below expectations, run over budget, and even suffer massive redesigns due to our own problems and changes imposed from without. A wise manager simply has to understand that if we don't manage failure, if we don't study our mistakes and turn them into learning experiences, we'll repeat the same old dysfunctional problems forever. The airplane industry has a feedback loop that improves the process. If we don't emulate their example via aggressive failure management, we'll also have a loop: Repeat forever: the usual mistakes. End Program. I've often wondered what happened to Joe. Did his boss resign him to he scrap heap of failed employees? How many of us either manage only to meet just a project's goals, or manage to build an awesome engineering department? |
||||
The 1802 Processor | ||||
Back in the late 70s processors consumed a fair amount of power. It wasn't unusual for one to need two or even three power supplies, one of which was generally a negative voltage. RCA took a different approach: they bet heavily on CMOS technology, which seemed a backwater to most cutting-edge designers. CMOS was both extremely low power and highly radiation resistant, factors critical for space and a few other applications. CMOS, though, was slow, very slow. Laughably slow. Switching speeds could be in the hundreds of nanoseconds, a far cry from the 10-20 nsec speeds achievable by reasonably fast TTL. Most of us considered CMOS an interesting idea that would soon die off. We were all so wrong; today CMOS's speed problems are gone, and it's the logic of choice for most applications. In fact, only the use of CMOS now avoids complex chips from self destructing. RCA joined the microprocessor fray with their 1802, a fully CMOS 8 bit device with a very unusual architecture. It was intensely register based, having many times the number of internal registers as any of the competing NMOS devices. Any one of those could be the program counter. Today we find that one of the tenants of RISC technology is to similarly maximize registers. RCA was clearly ahead of its time. Its greatest flaw, though, was a total lack of a stack. No push, no pop. No call; no return. Indeed, the 1802's innate lack of call instructions was a source of continuous grief. We worked around this by building a non-reentrant pseudo-subroutine structure: you do a call by loading a fixed register with the return address, another with the destination of the subroutine, and then jumping to a "subroutine" that stored the return in memory on a manually-managed stack before finally vectoring off to the destination. Returns were managed in a reverse manner. Rather like a primitive version of Arm's R14, aka LR (link register). The overhead was enormous, but the 1802 was never known as a speed demon. Instead, it found its way into ultra low power applications. My business partner and I managed to get a number of jobs designing deep sea probes that monitored temperature, pressure and other parameters, running for months on small batteries. The 1802 was our only option, as it required only microamps when operating at slow clock rates. We used an assembler which ran on a floppy-based CP/M machine. Happily, the assembler included macro capability which made generated the convoluted call/return sequences much easier. We wrote a very simple monitor program that permitted us to download hex files, fiddle with memory and registers, and stop/stop program execution. The cost of an emulator - about $20k in 1981 dollars - was far beyond our bankroll. The 1802's fully static design greatly simplified debugging. We'd run the machine at one hertz or less at times, using a scope or even a voltmeter to probe address and data lines. Later we found a customer doing research into the aging of fruit. Apparently, during the course of a month-long trans-oceanic voyage fruit emits various gasses as it ripens. Our customer wanted to understand this process, and so desired a system that could sample the air around a fruit container a number of times over the course of the voyage. The solution was to fill (empty?) 30 aluminum containers (ex-fire extinguishers) with a vacuum. A valve on the top of each opened for a few seconds at programmed intervals to suck in the ambient environment. We quickly concluded that only an 1802 could stay alive for the 30 required days, running from a small lead acid battery. The CPU ran a simple program that accepted timing parameters, and that then counted time till it made sense to open a valve. As I recall we ran the 1802 at about 100 hertz to conserve power. The data collection program was a great success... until a dockworker dumped a 50 ton container on the instrument. |
||||
This Week's Cool Product | ||||
In the early embedded days we debugged code using text-based tools. Set a breakpoint and the terminal (or, earlier, the TTY) would print a character when the program stopped. That morphed into IDEs using windows, a huge improvement, but we're still interacting with the project via a mouse and keyboard. Thirty years ago I dreamed of a debugging tool that would let an engineer manipulate firmware via a VR headset. Grab that interrupt vector and reroute it. That never happened. A new tool for engineers working on PCB hardware, though, is somewhat available (somewhat, as the free, limited, version is out, but it appears the pro versions have not yet been released). It's called inspectAR, and utilizes augmented reality. The website is a bit light on details, but watch the second (3 minute) video on the home screen to get a sense of what the tool can do. It's pretty cool! Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. Elephant: (n) A mouse with an operating system. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
It has been two years since my last salary survey. Follow this link to take the 2020 version (it''s only a dozen questions), which also has a question probing your work in these coronavirus times. I''ll publish the results in the May 4 Muse. Three copies of The Art of Designing Embedded Systems will be awarded to three randomly-selected participants. Based on early results, the vast majority of us report we''re working from home due to the virus. Jack''s latest blog: Lessons From a Failure I''m on the AmpHour ("Keeping You Current") this week. |
||||
Quotes and Thoughts | ||||
The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. David Akin |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. When faced with an intractable bug... wash your hands! A new(ish) site for industrial IOT is interesting. Percepio, responding to engineers working at home during the Coronavirus pandemic, are offering two months free use of their Tracealyzer. |
||||
Freebies and Discounts | ||||
This month''s giveaway is a BBC Micro:bit Go Bundle. Enter via this link. |
||||
More on Reuse | ||||
In reply to the last Muse''s comments on reuse, Stuart Jobbins wrote:
John Carter commented:
|
||||
Sequence Points in C | ||||
Do you know what this code does? sum = sum * 10 - ''0'' + (*p++ = getchar()); Don''t feel bad; no one does. As the standard says: "the actual increment of p can occur at any time between the previous sequence point and the next sequence point (the ;), and the call to getchar can occur at any point prior to the need of its returned value." The standard lets compilers evaluate parts of an expression with all of the discipline of sailors at a bar on shore leave. It says "The order in which subexpressions are evaluated and the order in which side effects take place, except as specified for the function-call (), &&, ||, ?:, and comma operators" is unspecified. To give us predictability the standard has the concept of sequence points, To quote the standard again: "The presence of a sequence point between the evaluation of expressions A and B implies that every value computation and side effect associated with A is sequenced before every value computation and side effect associated with B." A sequence point occurs on:
So be very wary of expressions like: b = a + a++; The value of b is going to depend on the order of evaluation of the expression. Because logical ANDs cause sequence points an expression like: a++ && a++ is perfectly legitimate. But my preference is to avoid such constructs that may confuse the unwary. Do note that adding a Lisp-like swarm of parenthesis will not change the compiler-generated order of evaluation. MISRA rule 13.2 addresses sequence points: "The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders." (Emphasis in original). CERT rule EXP30-C is more succinct: "Do not depend on order of evaluation between sequence points. " |
||||
Precedence Rules | ||||
Do you know C operator precedence rules? I don''t. At least, not well. Most of us stumble when queried about this. In fact, in Developer Beliefs About Binary Operator Precedence by Derek M. Jones shows that even experienced developers strike out when asked which of C''s 18 operators is evaluated before the others: John Watson was surprised when he found out that Sherlock Holmes didn''t know that the Earth revolves around the sun. Holmes said "What the deuce is it to me? You say that we go round the sun. If we went round the moon it would not make a pennyworth of difference to me or to my work." I feel the same way about precedence rules. They are arcane and uninteresting. Much better: use parenthesis when the order of evaluation isn''t crystal clear. Clarity is our goal. |
||||
This Week''s Cool Product | ||||
iRobot is launching a robot programming education initiative. They have (free!) on-line tools which let students develop and simulate robots. Looks like fun! Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad. Do you know Cobol? See this. |
||||
Joke For The Week | ||||
These jokes are archived here. Tis the dream of each programmer,
|
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||||||||||||||||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||||||||||||||||||||
Contents | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
Editor''s Notes | ||||||||||||||||||||||||
Last issue''s articles about Knowledge Capture and Hardware, Software or Hardware/Software generated a flood of correspondence. It wasn''t possible to include all of your replies, but so many had so much to say that this issue of the Muse is focused on some of those replies. Thanks for all of the feedback, which I always appreciate. |
||||||||||||||||||||||||
Quotes and Thoughts | ||||||||||||||||||||||||
Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time. David Akin |
||||||||||||||||||||||||
Tools and Tips | ||||||||||||||||||||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Referring to a note in the last Muse, David Strip wrote:
Jerry Mulchin responded to thoughts on cheap PCBs:
And Dave Smart wrote:
Sergio Caprile responded to my thoughts about state machines:
Francois Baldassari also had a useful link for finite state machines:
|
||||||||||||||||||||||||
Freebies and Discounts | ||||||||||||||||||||||||
Dainius Stankevicius won the Firia Labs Explorer Kit in the July contest. Firia Labs is donating one of their CodeBots (a Python-enabled robot with a host of sensors) for this month''s giveaway. Enter via this link. |
||||||||||||||||||||||||
More on Knowledge Capture | ||||||||||||||||||||||||
Anton Ivanovsky was one of many responding to the article on capturing knowledge:
Ted wrote:
Eric Geller corrected my reference to OneNote:
Graham wrote:
George sent this:
Carl Palmgrenhas a couple of suggestions:
Neil Cherry is in DevOps:
Frequent contributor Luca Matteini wrote:
In Robert Lange''s submission, (DFMEA = Design Failure Mode and Effects Analysis, CAR = Corrective Action Report, typically a root cause analysis of a failure:
Daniel McBrearty likes those who can look at a problem from 10,000 meters:
Martin Glunz is a systems person:
J.G.Harston was slightly off topic but brings up an important point:
|
||||||||||||||||||||||||
More on Hardware, Software, or Hardware/Software? | ||||||||||||||||||||||||
John Sloan and many others had thoughts about this article in the last Muse:
Boi Okken wrote:
Steve Taylor made an important point about the Socratic Method::
I''m a fan of the Socratic Method, which is basically a process of helping people figure things out by asking good questions. It''s far better to mentor a young engineer by using questioning to help that person gain understanding than simply tossing off an answer. John Kougoulos wrote:
John''s comments on specialization resonated with me. My dad was a mechanical engineer who worked on Apollo at Grumman. He told me one of the engineers there was the world''s expert in designing wheels for lunar roving vehicles. I''ve always wondered what happened to that person post-Apollo? Specialization can be useful, but remember that technology moves on and that certain skill can be obsolete overnight. Francois Baldassari figures it''s all about seniority:
|
||||||||||||||||||||||||
Failure of the Week | ||||||||||||||||||||||||
S. Stewart sent this. When the Wyze watch Android app doesn''t sync on Blue Tooth it seems to fill some data fields with 72123: |
||||||||||||||||||||||||
Jobs! | ||||||||||||||||||||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||||||||||||||||||||
Joke For The Week | ||||||||||||||||||||||||
These jokes are archived here. Outage (as in Internet outage): Isn''t it interesting how close that is in spelling to "outrage"? |
||||||||||||||||||||||||
About The Embedded Muse | ||||||||||||||||||||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
Jack''s latest blog: Does Anyone Remember In-Circuit Emulators? |
||||
Quotes and Thoughts | ||||
When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along. David L. Akin. |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Though I''m hesitant to enter the editor wars, I''ve been using Ultraedit for many, many years and it is my preferred editor on Windows. They''re up to version 27; I''m using 24 as I just can''t think of any additional features I''d need or want. The Ultraedit folks do sell a file compare, but I''m addicted to Beyond Compare from the oddly-named Scooter Software. It''s fast and it shows deltas brilliantly. Bob Paddock wrote:
|
||||
Freebies and Discounts | ||||
July''s giveaway, courtesy of Firia Labs, is one of their Explorer Kits, which includes 2 micro:bit circuit board computers and associated components for experimenting. Enter via this link. |
||||
Microcontroller Basics with PIC | ||||
What, another book about the Microchip PIC? Aren''t there shelves groaning under the weight of these tomes? Well, yes, but Tam Hanna''s new book Microcontroller Basics with PIC is a bit different. It''s aimed at students and embedded wanna-bees rather than practitioners. This is a hands-on book that teaches both hardware and software design in a manner analogous to how practicing engineers work. Many simple projects are introduced and explained. The wise reader will build and test the projects. However, unlike every other hands-on book, there is no specified evaluation or demo board used. He recommends using a PIC16F18877 with a solderless breadboard like this: Then, each of the projects is built simply by plugging in a few parts on the board. This is an excellent approach as demo boards come and go; if gone, so would the value of the book be. (Alas, Tam doesn''t use the word "solderless breadboard" and I''m afraid a novice wouldn''t know how to go about obtaining this item). The book starts with the basics and begins with assembly language (another nit: it doesn''t explain what assembly is or why it''s important). MPLAB is the IDE used, and Tam gives a great overview of installing and using that product. Hardware and software are presented as a unified gestalt, as is proper in the embedded world. Code to toggle a pin is accompanied with oscilloscope screen shots showing the result. Even better, drawings annotated with events show what''s happening when, such as: Assembly instructions are presented with example usage and resulting scope outputs. I''d recommend that a reader have a scope handy to follow along; even a low-bandwidth USB scope would suffice. Sometimes blinking an LED is that "ah-ha" moment that turns people on to embedded systems. I think the real exciting bit from the book is a table-driven sine wave generator and the accompanying scope shot. The second half of the book is about using C. As the author notes, it''s not a C text and assumes the reader has some familiarity with the language. But it does dig into using interrupts and various serial protocols. The book is chatty, perhaps too much so with many references to the author. But it is a great introduction to embedded systems and I recommend it. I''d pair this book with Alex Dean''s Embedded Systems Fundamentals with ARM Cortex-M based Microcontrollers as two works, taken together, which would give a decent foundation to this field. Tam''s will get you going in the 8-bit world; Alex pushes that to 32 bits and more complex subjects. Both are eminently practical and readable. |
||||
Requirements Traceability | ||||
Responding to last issue''s article about Software Elements Out Of Context, Harold Kraus wrote:
|
||||
Failure of the Week | ||||
From Scott Sweeting: |
||||
This Week''s Cool Product | ||||
Not quite a product, but researchers have a way of creating short pulses. How short? On the order of 5 ps. There''s more here. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad. |
||||
Joke For The Week | ||||
These jokes are archived here. From Clive Souter: I''ll never forget the first time I saw a universal remote. I thought, "This changes everything!" |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||
Contents | ||||||
|
||||||
Editor''s Notes | ||||||
Tip for sending me email: My email filters are super aggressive. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me. |
||||||
Quotes and Thoughts | ||||||
In any project, large or small, each engineer''s work is expected to be consistent and transparent so that another engineer can check it - by following its assumptions, logic and computations - for inadvertent errors. Henry Petroski |
||||||
Tools and Tips | ||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Brian Cuthie addresses an issue I think is important with regards to watchdog timers:
Jeremy Overesch and several others recommend Compiler Explorer:
The Sticky Bits blog has an article about using Compiler Explorer with test-driven development. |
||||||
Freebies and Discounts | ||||||
This month''s giveaway is a LA104 mini logic analyzer. I reviewed it in Muse 406. Enter via this link. |
||||||
Get it Wrong, Pay the Price | ||||||
In one of Capers Jones'' many papers he presents the following: Defect removal efficiency (DRE) is the percentage of bugs found in all phases of developing a system up to 90 days after initial delivery. A 75% efficiency means that percentage of bugs was removed; another 25% lurk even three months after customer delivery. What is the cost to fix these defects? There are a lot of numbers bandied about. Remember, these errors are those found in the field, post shipping, and are the most expensive of all. Some data points to something like $5000/shipped bug, but I''ve worked with customers where the numbers are much, much worse, typically in regulated environments. These post-shipping problems probably involve multiple people, including software engineers, managers, QA, telephone support and even field support. That number neglects the lousy image bad code gives of the vendor, which may ultimately be even more expensive to the business. The post-compile total number of bugs in firmware typically runs 5 to 10% of the total number of lines of code. Assuming the mean of that, 7.5%, and we find these numbers for different sized projects with each of the three defect removal efficiencies, assuming $5k/fix: I can''t tell you the number of times people have told me they don''t have time or a budget for process improvement. Given that the engineering costs to build a system is $20 to $40 per line of code, fixing fielded bugs in a 100KLOC device at a 75% DRE will consume about a third of all of the money originally spent on engineering the code in the first place. (Disclaimer: the numbers vary tremendously. Use these to get a feel for the problem rather than an exact number. An impressionistic painting shows the shape and nature of an image; it isn''t a high-res photo. These metrics are similarly impressionistic, though that does not diminish their importance.) |
||||||
Responses to Expanding One''s Capabilities | ||||||
A reader asked how one can go about getting less pigeonholed; widening one''s skills and adding value to a career. Several people responded. Steve Johnson doesn''t specialize:
I agree with Richard Prosser about courting startups:
Nick Soroka has a trifecta of suggestions:
|
||||||
Why Did You Become an Engineer? | ||||||
In the last Muse a reader asked why we became engineers. Christopher Eddy''s contribution makes me wonder about genetics: can 20k or so genes encode an engineer''s personality? Or, as some believe epigenetic factors affected later generations after the Dutch Hongerwinter in 1944-45 could there be a similar effect for nerds? (For a wonderful book on genetics which has some - in my opinion, speculative - discussion of the Hongerwinter and epigenetics, see The Gene: An Intimate History, by Siddhartha Mukherjee). Christopher writes:
Gordon Dick''s path was a little different:
To add a twist to these stories, I''ll include another personal anecdote. As I mentioned last issue, my dad was a mechanical engineer who spent his career mostly in the space program. He did not fall into the field in the same way as those quoted above. Just before WWII his parents bought a diner just outside of Grumman''s gates in Bethpage, NY. With the war Grumman''s business boomed and the diner prospered. In senior year of high school his dad promised to set him up with his own diner, which was all my dad wanted. A teacher more or less forced him to take a scholarship exam, pretty much against his will, and he earned a full ride to MIT. So he sort of fell into engineering accidentally. |
||||||
Failure of the Week | ||||||
Ray Keefe sends this week''s failure. He writes "This is from a running app on my phone. The numbers come good after a bit so it looks like it draws the GUI before it has completed the calculations and must not initialise the variables beforehand or mark them as not ready." |
||||||
This Week''s Cool Product | ||||||
Bill Schweber has an article in EDN about using bus bars on a PCB to provide low-impedance power rails across a PCB. This is important in higher-power large boards. For example, Storm Power Components sells bars used like this: This is hardly a new concept. Designing boards for Nova minicomputers in the 1970s we used these as these were 15 x 15" boards: enormous, and with hundreds of TTL ICs quite a few amps were needed. Multilayer boards weren''t around back then. The bus bars distributed the massive columbic flow and eliminated board flex. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||
Jobs! | ||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||
Joke For The Week | ||||||
These jokes are archived here. Flon''s Law: There is not now, and never will be, a language in which it is the least bit difficult to write bad programs. |
||||||
About The Embedded Muse | ||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||
Contents | ||||||
|
||||||
Editor''s Notes | ||||||
|
||||||
Quotes and Thoughts | ||||||
The real miracle of the Wright Brothers'' flight was than they accomplished it without the use of any electronics at all - Allen Puckett |
||||||
Tools and Tips | ||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Carl Dreher wrote:
|
||||||
Freebies and Discounts | ||||||
September''s giveaway is courtesy of Binho, and is one of their Nova Multi-Protocol USB Host Adapters with accessories. Enter via this link. |
||||||
Assembly - Dead as a Dodo? | ||||||
A very long time ago, when dinosaurs still roamed the Earth, I designed a computer (using the fire-blackened end of a spear on a cave''s wall.)? Still in high school, I was geekily-somewhat competent with digital circuits but knew nothing about computer architecture. But I had learned Fortran and naively assumed some parallel between that language and how computers worked. The result: a machine that would have been a complete failure, and which used a greatly subsetted and compressed form of Fortran as its native instruction set. College gave me grade-destroying access to a Univac 1108 and I learned its assembly language. Suddenly computer architecture became crystal clear. The one-to-one mapping of machine instructions to simple logic circuits was beautiful; the stored program that substituted instructions in memory for massive amounts of hardware breathtaking. Since then I''ve read many books about computer design but feel none would reveal a fundamental insight into CPU architecture without relying heavily on the essentials of assembly language. The ALU, program counter and stack pointers are dead lifeless things,? capable of nothing till animated like Frankenstein''s monster with instructions stored in memory. Assembly is both the basis of all computers and the name of a class of languages. Often used to specify a particular variant (e.g,. "8051 assembly"), it oddly doesn''t even get a capitalized first letter as all other languages do. Or, did, until grammar died a horrible death at the hands of clowns sporting marketing degrees. Proper nouns like Fortran, Ada, C, and Pascal gave way to iPhone, dBASE, and eEverything. The nuns at St. Camillus would have beaten us senseless for peppering our writing with uPPeraNdLowercAse, yet today that affectation is not only common, one is relieved when at the very least the spelling is correct. In the early days of microprocessors all programs were written in assembly. No C compilers existed for the minimal CPUs of the day and memory was so expensive and processors so slow that no one dreamed of sacrificing any form of efficiency for reduced development costs. All firmware folk were experts at at least one assembly language. Usually several. C and IDEs were desperately-needed additions to our toolbox. Though I still think assembly is more fun than using a high-level language, C reduces development costs so much I''d never dream of cranking much assembly code anymore. But one effect of this great gift is a new distance between engineers and the underlying hardware. That has both positive and negative consequences. On the down side I worry that a lot of us no longer have that deep insight into computer architecture. A brief review of the nature of assembly in Programming 201 hardly forces one through PC-relative versus absolute jumps, or how the Cortex M uses a link register to preserve a return address. In real-time systems interrupts reign, but their very real costs are disguised by simple C structures that hide the stacking and unstacking of the system''s context. Many people ask me how to go about becoming an embedded developer. Part of my advice is to learn - really learn - an assembly language. Do you use much assembly anymore? Are you fond of programming at the bare metal level? |
||||||
The Pint-Sized LA104 Logic Analyzer | ||||||
About a year ago I reviewed the MiniDSO, which is an iPhone-sized oscilloscope. It''s pretty cool and could be a great gift for an engineer who has everything. Recently Guangzhou E-design Intelligent Technology Co., Ltd. sent me one of their LA104 logic analyzers for a review. My understanding of Chinese companies is a bit vague as they have complex interconnections, but I suspect Guangzhou manufactures both the MiniDSO and the LA104. Both are a similar size and have pretty much the same user interface. And the LA104 logic analyzer, like it''s scope brother, is a pretty cool bit of tech. First, the specs: it''s rated at 100 MHz with 100 MSa/s sample rate. It sports four input channels with 8 MB of memory, though just how that memory is apportioned isn''t clear to me. I2C, SPI and UART protocol decoders are included, as are four programmable outputs. I couldn''t figure out how to set up the outputs. The UI is unusual, and is much like that on the MiniDSO. Two wheels control a menu; one advances selections left and right, the other selects from vertical submenus. OK, MENU, ESCAPE and SAMPLE buttons complete the interface. It''s a little awkward at first but quickly becomes natural. A ribbon cable plugs into the left side of the unit and forms the probes. There are nine connections: 4 inputs and ground, 4 outputs and +3V. The back of the unit has very nice labels indicating which connection is which. Triggering seems to be pretty decent for such a tiny unit. Here''s the options from the user manual: Here''s a closeup of the screen: Note there are six channels displayed, yet there are only four probes. I don''t know what channels 5 and 6 refer to. The solid bar across the bottom shows the entire buffer; in this case acquiring a 25 MHz square wave on channel 1. Up from that are statistics for channels 1 and 2. Though the unit has the ability to save screens as .CSVs or .BMPs, I didn''t see a way to recall them or to upload them to a PC. The unit did not come with a manual, but you can download one from here. It''s rather incomplete. The LA104 is available from many sources, such as Seeed Studio for $89. You can''t beat the price. Me, I prefer a logic analyzer that sends data to a big PC screen. But if you''re price or space-constrained, this is a pretty remarkable bit of test equipment. This will be February''s giveaway. |
||||||
Taking Charge | ||||||
In one of the made-for-TV pseudo-histories of the Apollo program, an astronaut figured landing on the moon would be something like flying helicopters. So he learned to fly choppers. He didn''t ask permission. His boss wasn''t involved. No one told him to acquire this new skill. In the every-man-for-himself astronaut office astronauts took action to fill holes in their experience. How often do you listen to a developer whine about his dead-end job? How many of us wind up in dead-end jobs because we refuse to gather new skills and experiences? Back in the old days, paternal corporations benevolently managed their employees'' careers. You could leave college and work for IBM till you retired. They''d take care of you. Need a new skill? Your boss would identify the weakness and schedule some sort of training. No more. In these troubled times companies are worried about their own survival. Cost-cutting and squeezing out a profit is all that matters. Get the product out the door today no matter what the personal cost may be. Joe is still struggling with C++? Replace the SOB! There''s an army of applicants knocking at the door. The company has neither the time nor the incentive to engage in training and career management. I believe it''s our personal responsibility to upgrade our skills. constantly. Relentlessly. Technology changes so fast, and even the first derivative of that change is accelerating. Too many developers stop learning when they leave college. Do that, and your career will end in your twenties. Companies will use your skills as long as they are still relevant and then spit you out, a burned-out husk obsolete at 30. It''s up to you, and to no one else, to learn new things, to become more productive, and to embrace the new technologies that will influence your career. There''s a wealth of resources available, from books to magazines, and websites. Some colleges have put their classes on-line, free of charge. No doubt the astronauts have an incredible amount of personal freedom in their jobs, as well as a budget we can only dream of. They are all dynamic personalities who look at a problem, figure what resources might be needed, and immediately take action. That sounds like a great description of the engineering method. Take action. Learn. Grow. Become expert at something new. Stasis in this industry is death. Especially now, when jobs are scarce and layoffs all too common. |
||||||
Failure of the Week | ||||||
From Glenn Hamblin: |
||||||
This Week''s Cool Product | ||||||
RADAR has traditionally been an expensive sort of sensor, but that is changing. An interesting article (written by TI) enumerates a number of cool scenarios where low-cost RADAR can be useful. The focus is TI''s IWR6843, a 60 GHz RADAR on a chip (just add a power supply and antenna). It includes three transmitters and four receivers so can support beam forming. In singles it''s about $30, falling to $22 in 500 lots. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||
Jobs! | ||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||
Joke For The Week | ||||||
These jokes are archived here. All programmers are playwrights and all computers are lousy actors. |
||||||
About The Embedded Muse | ||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
It has been two years since my last salary survey. Follow this link to take the 2020 version (it''s only a dozen questions), which also has a question probing your work in these coronavirus times. I''ll publish the results in the May 4 Muse. Three copies of The Art of Designing Embedded Systems will be awarded to three randomly-selected participants. Based on early results, the vast majority of us report we''re working from home due to the virus. Jack''s latest blog: Lessons From a Failure I''m on the AmpHour ("Keeping You Current") this week. |
||||
Quotes and Thoughts | ||||
The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. David Akin |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. When faced with an intractable bug... wash your hands! A new(ish) site for industrial IOT is interesting. Percepio, responding to engineers working at home during the Coronavirus pandemic, are offering two months free use of their Tracealyzer. |
||||
Freebies and Discounts | ||||
This month''s giveaway is a BBC Micro:bit Go Bundle. Enter via this link. |
||||
More on Reuse | ||||
In reply to the last Muse''s comments on reuse, Stuart Jobbins wrote:
John Carter commented:
|
||||
Sequence Points in C | ||||
Do you know what this code does? sum = sum * 10 - ''0'' + (*p++ = getchar()); Don''t feel bad; no one does. As the standard says: "the actual increment of p can occur at any time between the previous sequence point and the next sequence point (the ;), and the call to getchar can occur at any point prior to the need of its returned value." The standard lets compilers evaluate parts of an expression with all of the discipline of sailors at a bar on shore leave. It says "The order in which subexpressions are evaluated and the order in which side effects take place, except as specified for the function-call (), &&, ||, ?:, and comma operators" is unspecified. To give us predictability the standard has the concept of sequence points, To quote the standard again: "The presence of a sequence point between the evaluation of expressions A and B implies that every value computation and side effect associated with A is sequenced before every value computation and side effect associated with B." A sequence point occurs on:
So be very wary of expressions like: b = a + a++; The value of b is going to depend on the order of evaluation of the expression. Because logical ANDs cause sequence points an expression like: a++ && a++ is perfectly legitimate. But my preference is to avoid such constructs that may confuse the unwary. Do note that adding a Lisp-like swarm of parenthesis will not change the compiler-generated order of evaluation. MISRA rule 13.2 addresses sequence points: "The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders." (Emphasis in original). CERT rule EXP30-C is more succinct: "Do not depend on order of evaluation between sequence points. " |
||||
Precedence Rules | ||||
Do you know C operator precedence rules? I don''t. At least, not well. Most of us stumble when queried about this. In fact, in Developer Beliefs About Binary Operator Precedence by Derek M. Jones shows that even experienced developers strike out when asked which of C''s 18 operators is evaluated before the others: John Watson was surprised when he found out that Sherlock Holmes didn''t know that the Earth revolves around the sun. Holmes said "What the deuce is it to me? You say that we go round the sun. If we went round the moon it would not make a pennyworth of difference to me or to my work." I feel the same way about precedence rules. They are arcane and uninteresting. Much better: use parenthesis when the order of evaluation isn''t crystal clear. Clarity is our goal. |
||||
This Week''s Cool Product | ||||
iRobot is launching a robot programming education initiative. They have (free!) on-line tools which let students develop and simulate robots. Looks like fun! Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad. Do you know Cobol? See this. |
||||
Joke For The Week | ||||
These jokes are archived here. Tis the dream of each programmer,
|
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||||||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||||||||||
Contents | ||||||||||||||
|
||||||||||||||
Editor''s Notes | ||||||||||||||
Tip for sending me email: My email filters are super aggressive. If you include the phrase "embedded muse" in the subject line your email will wend its way to me. Bad news for router users: a recent study looked at 127 routers (of the style used in homes) and found all have security problems. Major security problems. 50 of them have hard-coded passwords and the like. All run Linux, generally older versions. This raises the question: How does one support a product, especially as it ages? A big OS like Linux will always have bugs. How long should a vendor provide support for a product? Phil Matthews poses this interesting question: What childhood experiences influenced you to become an engineer? For me it was probably that my dad was a mechanical engineer working in the space program, though how I got interested in electronics I don''t remember. I did build a crystal radio at 8 or 9 years of age, and always liked building "forts" and other items. I got a ham license at 16 and had a lab in the basement from an early age. My interest has always been in building stuff, an interest that has never waned. What was your experience? |
||||||||||||||
Quotes and Thoughts | ||||||||||||||
One should expect that the expected can be prevented but that the unexpected should have been expected. Unknown author |
||||||||||||||
Tools and Tips | ||||||||||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. There has been some discussion of inexpensive PCB vendors in the Muse lately. I recently found that Digikey has a PCB service that gets quotes from a half-dozen vendors here. Chris Bucsko wrote:
Joe Vandzura responded to an article in the last Muse:
|
||||||||||||||
Freebies and Discounts | ||||||||||||||
Jake Michael won last month''s Binho Nova Multi-Protocol USB Host Adapters. This month''s giveaway is a LA104 mini logic analyzer. I reviewed it in Muse 406. Enter via this link. |
||||||||||||||
Replies to "Is Assembly Language Dead as a Dodo?" | ||||||||||||||
A ton of people replied to this article in the last Muse. Most said they write little Assembler code but read a fair amount. And there was some discussion about whether "Assembler" should be capitalized. I bow to the general consensus that it should be... and wonder where the word came from. Here are a handful of reader replies. Dan Daly wrote:
From Chris van Niekerk:
James Thayer, like your editor, goes back to the early days of this field:
Tom Mazowiesky often writes and sent this:
Steve Paik''s insights are worthwhile:
Tony Garland dives into Assembler when needed:
Daniel McBreaty bridges comments on Assembler with another Muse article on taking charge/continuous learning:
|
||||||||||||||
On Taking Charge | ||||||||||||||
Plenty of email also came in regarding the article in the last Muse about Taking Charge. Some highlights follow. Neil Cherry wrote:
Steve Paik sent this:
Finally, a reader who wishes to remain anonymous poses an interesting question:
|
||||||||||||||
Failure of the Week | ||||||||||||||
From Leon Bazdar: |
||||||||||||||
Jobs! | ||||||||||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||||||||||
Joke For The Week | ||||||||||||||
These jokes are archived here. A bug in the code is worth two in the documentation. |
||||||||||||||
About The Embedded Muse | ||||||||||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||
Contents | ||||||
|
||||||
Editor''s Notes | ||||||
A recent EEWorldonline article states "TIRIAS Research forecasts that 98% of all edge devices will use some form of machine learning/artificial intelligence by 2025." In my opinion, this AIn''t gonna happen anytime soon. A long but fascinating history of the transistor is here. Jack''s latest blog: Networking Did Not Start With the IoT |
||||||
Quotes and Thoughts | ||||||
58% of innovations fail, except for those originated by top management, which fails at a rate of 74%. - The Economist |
||||||
Tools and Tips | ||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Recent Muses have had comments about using state machines. But what about tools? I have heard good things about IAR''s Visual State. Michele Corradin wrote that they are using Yakindu. I had not heard of it but he says they''ve had great success with it and the web site looks interesting. Does anyone have any experience with either of these tools? |
||||||
Freebies and Discounts | ||||||
Firia Labs is donating one of their CodeBots (a Python-enabled robot with a host of sensors) for this month''s giveaway. Enter via this link. |
||||||
Knowledge Capture | ||||||
In Knowledge Capture and Management for Space Flight Systems author John Goodman argues that, particularly in aerospace projects, much vital project knowledge exists only in engineers'' heads. Imperfect memories, career changes and retirement means this information goes missing, often to the detriment of a current program, or a future one that could have drawn on what might have been painfully-acquired experience. Goodman relates that early space efforts took just a few years to complete; Project Mercury ran just over four years from contract award till final flight, Gemini took 5 years. The Shuttle program spanned 38 years, an engineer''s entire career. How many original engineers were associated with that system over the entire program? Just two years after contract award the P-38 fighter had made its first flight, and was introduced to the service two years later. The F-4 flew three years after the contract. But the F-22, despite the contractor having built a flying prototype before winning the competition, required an additional six years for the first flight of the contracted aircraft, and a further eight before the first production model made it to the Air Force. The F-35''s schedule appears unbounded. These are more ambitions projects than the primitive, by today''s standards, P-38 and F-4, so comparisons are not completely fair. But it''s clear that both the complexity of the programs and the engineering duration means preserving design decisions is increasingly important. In the commercial world the problems are little different. I''ve often wondered how the automotive companies preserve corporate knowledge. Ford learned at great expense how to position gas tanks due to the Pinto fiasco, but do young engineers who weren''t even alive at the time know those lessons learned so painfully, so long ago? Middle-aged readers who can''t find their keys understand that even a single person''s memory is pretty unreliable. I figure the brain is a FIFO queue. When it fills, around age 50, something has to go when one learns something new. So how do we preserve knowledge? Traditional tools aren''t up to snuff. Goodman suggests the use of "Brain Books," more or less engineering notebooks used by developers to record design decisions, test results, and the like. He cites a case where a Brain Book saved a project. But hardcopy is tough to search and poor penmanship hinders understanding. I keep a notebook in my woodworking shop to record things I learn that I''ll surely forget. There''s no computer in that room and the volume of data is very low, so that works well. A variety of pretty organized files on my PCs keep resource notes, interesting quotes, facts and the like. But perhaps a wiki is the ultimate Brain Book repository, and reading Goodman''s article has given me motivation to set up a personal Brain Book on a wiki. We''re drowning in information and, unless preserved and categorized, an excess of data is the same as no data. Microsoft Notes is an interesting system for recording ideas. I''ve had pretty good success with it. But not trusting any cloud provider to be around forever I do download the data from time to time as a backup. How do you preserve your design notes and other important bits of information that exist outside of normal tool flow? |
||||||
Efficacy of Bug-Finding Tools | ||||||
I stumbled across a 2005 paper by Stefan WagnerJan J?rjensClaudia KollerPeter Trischberger called Comparing Bug Finding Tools with Reviews and Now, the study was about Java code and the bug-finding tools were open source, not the commercial versions now available. Here are their conclusions: Interestingly, code reviews were much more effective at finding the worst bugs than bug-finding tools. Tests were not as good as reviews, but were far better than the tools for these impactful bugs. The tools shine at detecting the least consequential errors. Tests found none of these. My takeaway: use the tools to cheaply find some errors. Apply reviews, and then tests. Think in terms of a series of filters, as no one approach will give quality code. |
||||||
Hardware, Software or Hardware/Software? | ||||||
When the embedded field was young most developers wore at least two hats, that of firmware and hardware designer. Some also came up with analog, power and maybe even RF circuits. A single engineer might be responsible for most of the electronics in a product. Sometimes the same person would even lay out the PCB and assemble prototypes. That was a lot of fun! But systems were simpler back then. 8 KB of code was a lot, and SMT hadn''t turned board assembly into an art practiced only by the caffeine-deprived. 12 bit A/D converters were expensive, which meant those of us working in the analog domain had, in general, smaller noise issues than today''s systems that measure femtoamps. Low clock rates dodged Maxwell''s Laws and programmable logic was merely a dream. Though a huge number of embedded systems are still small, often containing a bare sliver of silicon embodied in a small PIC or other minimal MCU, big applications are common. Firmware can consume hundreds of thousands or even millions of lines of code. Hardware people design with multi-hundred pin chips running with tiny noise margins, while wrestling with EMI and ESD requirements that were unheard-of decades ago. It''s natural that engineers started to specialize, at first to divide the work into manageable chunks, and later because of the specialized knowledge required to deal with advancing technology and requirements. Today an increasing number of embedded systems developers live in their own domain, with little knowledge of other aspects of the system they''re building. That''s a natural part of the progression of knowledge: as a technology or science advances people''s expertise at their own arcane area grows while their breadth narrows. But it''s interesting how that, in a single generation, we''ve progressed to the point where many firmware developers can''t answer simple questions about their hardware platform. In casual discussions with engineers I''ll often ask about their system''s clock rate, or supply voltage, or any of a number of hardware issues. Quite a few can''t answer; in some cases the software people don''t know what the target processor is. The reverse is often true as well: ask a hardware developer about the firmware''s data structures or which RTOS is used and you might get a blank look. The FPGA whizzes are sometimes clueless about classes and analog gurus can be completely ignorant about PWM control. I''ve worked with groups that use embedded Windows or Linux simply to minimize their need for firmware people, who can be hard to find and a lot more expensive than Visual Studio programmers. These folks may have little idea about the physical instantiation of their product. This natural and necessary specialization has created a new job category, which I call the systems person. The person who does have a deep understanding of all of these interrelated issues, who can sling some VHDL and C while probing a low-noise preamp. Sometimes they''re the computer experts who can tie together the digital hardware and code to interface with the RF crowd to help the entire team solve a challenging multipath problem. These systems people are invaluable and increasingly hard to find. At times I wonder if they are a vanishing breed. But other fields have managed to keep systems folks with armies of specialists. Medical GPs, for instance, look at the whole body. What is your experience? Are systems folks a dying breed? |
||||||
Failure of the Week | ||||||
I took this picture at an airport in Norway. The word "Bug" plastered on the plane didn''t leave a feeling of confidence: |
||||||
This Week''s Cool Product | ||||||
Need a custom PCB? Here''s a site that will quote boards instantly. Change a parameter (say from 2 layer to 4 layer) and the price comes up in under a second. And, small boards are dirt cheap. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||
Jobs! | ||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||
Joke For The Week | ||||||
These jokes are archived here. From Dan Daly, who writes: Seen in Silicon Valley, at a park along a bicycling/hiking trail. There were many casts in the pond, but the most visible, for obvious reasons, were (float). (The jokes section of my website now has 200 computer-related bits of humor.) |
||||||
About The Embedded Muse | ||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
Jack''s latest blog: Is the Future All Linux and Raspberry Pi? |
||||
Quotes and Thoughts | ||||
We should continue to collect and analyze data on how, when, where and why people make software errors in order to find means to avoid people making these errors. Barry Boehm |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Sometimes we have very limited I/O for debugging. One approach I have used is to generate Morse code messages to a speaker. Here''s a program that will do this. This site gives implementations in 62 languages; the C version is very clunky, but the Forth version is intriguing. A couple of years ago a reader wrote that he did this, but the beeping drove other engineers crazy! Max Maxfield has a 9 (!) part series on switch debouncing. Part 9 is here, and that page has links to the earlier parts as well. |
||||
Freebies and Discounts | ||||
Firia Labs is donating one of their CodeBots (a Python-enabled robot with a host of sensors) for this month''s giveaway. Enter via this link. |
||||
Design by Contract | ||||
Design by Contract (DbC) is an idea that I believe was first implemented in the Eiffel1 programming language. Ada-2012 included the notion. Essentially, the idea is the components of a program have contractually-governed relationships to each other. A function, for instance, can only accept parameters that meet certain constraints (e.g., code that computes a rocket''s velocity might only accept positive values). DbC usually includes three types of contracts:
I''ve tried to torture C via macros and other convoluted processes into supporting DbC, without much success. Assertions are a poor-person''s crude-DbC alternative, and I''ve written extensively about better ways of using those here. I recently stumbled across a nice writeup on using DbC in Ada. Recommended, even for C developers, as that page has wisdom worth pondering. 1. Eiffel is an object-oriented programming language that no one in the embedded industry uses. It is described in Betrand Meyer''s Object Oriented Software Construction, which is probably the best book written about OO design. Though it teaches Eiffel most of the book''s ideas scale directly to C++. Meyer is a brilliant writer. |
||||
RTOS... or a State Machine? | ||||
Tony Garland responded to my comments in the last issue about using an RTOS:
Miro''s book is indeed excellent. I did find it a bit heavy going at times, but worth the effort. |
||||
The (Scope) New Math | ||||
Last year I was using an opto-interrupter to measure the speed of a rotating wheel. The pulses went to an oscilloscope, and by measuring their period I could derive RPM. It occurred to me that most scopes today can do some math, though that is limited to a handful of pre-defined operations. Wouldn''t it be nice if the instrument could do any sort of math? That is, the user could type in custom formulas. Then one could observe things like RPM directly. I mentioned this to Siglent; they said they''d look into it. Of course I forgot all about it. Recently I upgraded the firmware in my Siglent SDS5034X and found that the MATH button operates normally, but a little clicking around brings up this screen: That''s right - the scope can accept many kinds of user-defined math functions. The middle array of soft-buttons select the source: channels 1 through 4 (C1-C4), zoomed subsets of those channels (Z1-Z4) and two user-defined functions. The buttons on the left enable common functions and the grouping on the right includes numbers and the basic arithmetic functions. In the formula bar (the arrow points to this) I''ve entered (∫(channel 3 times channel 2)) *√ (channel 1). The computation''s result appears as another trace on the screen. As one moves the cursor a box displays the instantaneous value at the cursor position. Remember when we used to count divisions on the screen and convert those to volts or time? That''s long gone. So too, it now seems, with figuring some function manually. |
||||
Failure of the Week | ||||
This Week''s Cool Product | ||||
Here''s a gyro that''s 10,000 times more accurate than the one in your mobile phone, but is only 10x more expensive. Though not available yet as a product, it''s pretty amazing. This is a golden age of sensors. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here.
|
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||
Contents | ||||||
|
||||||
Editor''s Notes | ||||||
Tip for sending me email: My email filters are super aggressive. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me. Are you comfortable designing with FPGAs? I think this is a skill that is going to be highly marketable. This article shows these parts are becoming much more common. One note: C programmers may find Verilog or VHDL a little odd. Unlike C code, where each statement executes in succession, in general in an HDL everything is running at the same time. In fact, it often doesn''t matter which order the HDL statements are coded. |
||||||
Quotes and Thoughts | ||||||
We''re absolutely going to deliver on time on this project. We were too overconfident on the last one. |
||||||
Tools and Tips | ||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Mark Rubin has what looks like a handy utility:
Bob Paddock sent this link to the definitive computer industry glossary of terms. Phil Koopman, noted Carnegie Mellon professor, has made his embedded software course material available online. The course covers software quality, safety, and security. For those who don''t do YouTube, videos and handouts are here as well. David Thomas posed an interesting question: Does anyone have tips on keeping a workbench reasonably tidy? I find that it''s not long before scope probes and other leads are snaking all over the bench, tools scattered around, and components piled up. Much as I admired the man, I try to avoid a Jim Williams'' like bench:
|
||||||
Freebies and Discounts | ||||||
Murdo McLeod won the BattLab-One tool in last month''s contest. This month''s giveaway is a Pico 2207B 70 MHz USB scope, which I review later in this Muse. Enter via this link. |
||||||
A Buck50 Logic Analyzer | ||||||
Need a logic analyzer but Covid has depleted your cash reserves? Can you shell out $1.50? Mark Rubin has created the "buck50" logic analyzer which has a UI that runs under Linux/Unix and maybe (this is untested) a Mac. This isn''t a product that he sells. It''s completely open source. Source code and documents are here. And it is extremely well documented. The hardware is just a "Blue Pill" STM32F103 eval board, widely available for a dollar-fifty. You buy the board, download the firmware, and install the application. You''ll want to solder a header to the board for test probes. Features include:
As Mark says: "At $1.50 for the hardware plus $0.00 for the firmware and software, if there''s a competition for the world''s cheapest logic analyzer I want to enter it. Please note this is very much a beta release and bug reports are welcome." Way cool! |
||||||
Pico 2207B USB Scope Review | ||||||
Pico Technology is one of the pioneers in USB oscilloscopes. They sell a huge range of test instruments and related gear; their website, though frustratingly slow, is worth perusing. The company sent me their 2207B MSO, a 2 channel 70 MHz scope with a 64 MS buffer, and 1 GHz sample rate. It collects 80,000 waveforms per second. Though I tested this using their Windows application, they have beta versions for Linux and Macs. The unit comes nicely boxed with an excellent full color poster showing the UI, with annotations describing how each element works. It''s too big to reproduce here but I commend Pico for this "lagniappe" (a Louisiana term meaning a bonus gift). Also included is a soft carrying case, two scope probes, and digital logic probes. A quick start guide is included, but you''ll want to download the 239 page user manual from their web site. If you didn''t know anything about the company, you''d quickly infer that they''ve been in the scope business for some time. The manual, in PDF form and a help file, is extensive and very complete. And the scope simply works. There''s no fiddling with USB setups. No connection hiccups. Pico UI. Click on image for a bigger version. The UI is complete and totally intuitive. Channel control, horizontal and vertical, is on the top ribbon. Triggering and measurements on the bottom. Channel A is in blue; on the left side of the screen the voltage levels are shown. Channel B''s voltages, in red, are on the right. I''ve added an arrow to show the trigger position, denoted by a yellow dot. You can change this by simply dragging that dot to any position on the waveform. In the previous picture I added peak-to-peak and frequency measurements, which are shown on the bottom of the screen. I counted 19 of these which include two kinds of RMS and pulse counts. But those tiny numbers sure are hard to see, aren''t they? The UI, though, allows one to select any font size for these. For instance: As is common on digital scopes, there''s a zoom feature to narrow which part of the buffer is shown. Unusually, a "picture in a picture" shows a really nice image of where in the buffer the zoomed display is presented. It''s easy to grab the cursor in that small image to drag the zoomed display around. I was disappointed that you can only select vertical and horizontal ranges using the usual 1-2-5 sequence until discovering that the channel selection button lets you type any range. And in that menu for the vertical signals there''s a bandwidth limit option, which is also freely selectable - you''re not limited to a few canned bandwidths. The spectrum analyzer mode gives a remarkably accurate and clear display. The following shows a quite pure 10 MHz sine wave. Note the frequency labels below the waveform. Though at the far bottom left the scale is shown in kHz, I would prefer that the axis be labeled. Instead of the bland "1000" shown, it would be better to show "1000 kHz". 23 serial protocol decoders are included, and each can be set up using either the analog or digital channels. Also supported: mask testing, where one defines a "legal" waveform and an alarm or trigger occurs when the sampled wave falls out of the legal range. Like most scopes, the Pico will do math. For instance, one can display a waveform that represents A+B. Unlike most, you can create your own equations. This is one example: Not long ago I asked Siglent to add this feature to their scopes, which they did. I had been working on a system with rotating components. My report had screen shots showing RPM indirectly, as a frequency measurement. How much better to show actual RPM! The model tested has 16 digital channels. These are arranged in two groups, and the threshold voltages can be set to any value for each group. Finally, the unit includes an arbitrary waveform generator that will produce the usual signals up to 1 MHz with 12 bits of resolution. Nothing ground-breaking there. Want a custom wave? A single click brings up a waveform editor which lets you create anything. This is the easiest-to-use waveform creator I''ve come across... and it''s downright fun to use. The following took about three seconds to build: The 2000 series of PicoScopes, of which this unit is a member, ranges from 10 MHz, 2 analog channels, 100 MS/S sample rate and no digital channels for $139, to 100 MHz, 4 analog, 128 MS memory for $1125. The unit I tested sells for $769. More info here. Bottom line: This is the best USB scope I''ve tested. |
||||||
Failure of the Week | ||||||
From Martin Grill: |
||||||
This Week''s Cool Product | ||||||
Want to play with AI? Google is offering their "AIY" (Artificial Intelligence Yourself) kits. Currently available are kits for playing with AI for voice and for vision. Looks like fun! Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||
Jobs! | ||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||
Joke For The Week | ||||||
These jokes are archived here. TOOLS EXPLAINED DRILL PRESS : A tall upright machine useful for suddenly snatching flat metal bar stock out of your hands so that it smacks you in the chest and flings your beer across the room, denting the freshly-painted project which you had carefully set in the corner where nothing could get to it. WIRE WHEEL : Cleans paint off bolts and then throws them somewhere under the workbench with the speed of light. Also removes fingerprints and hard-earned calluses from fingers in about the time it takes you to say, ''Oh sh*t'' CHOP SAW : A portable cutting tool used to make studs too short. PLIERS : Used to round off bolt heads. Sometimes used in the creation of blood-blisters. BELT SANDER : An electric sanding tool commonly used to convert minor touch-up jobs into major refinishing jobs. HACKSAW : One of a family of cutting tools built on the Ouija board principle... It transforms human energy into a crooked, unpredictable motion, and the more you attempt to influence its course, the more dismal your future becomes. VISE-GRIPS : Generally used after pliers to completely round off bolt heads. If nothing else is available, they can also be used to transfer intense welding heat to the palm of your hand. OXYACETYLENE TORCH : Used almost entirely for lighting on fire various flammable objects in your shop. Also handy for igniting the grease inside the wheel hub out of which you want to remove a bearing race. TABLE SAW : A large stationary power tool commonly used to launch wood projectiles for testing wall integrity. HYDRAULIC FLOOR JACK : Used for lowering an automobile to the ground after you have installed your new brake shoes, trapping the jack handle firmly under the bumper. BAND SAW : A large stationary power saw primarily used by most shops to cut good aluminum sheet into smaller pieces that more easily fit into the trash can after you cut on the inside of the line instead of the outside edge. TWO-TON ENGINE HOIST : A tool for testing the maximum tensile strength of everything you forgot to disconnect. PHILLIPS SCREWDRIVER : Normally used to stab the vacuum seals under lids or for opening old-style paper-and-tin oil cans and splashing oil on your shirt; but can also be used, as the name implies, to strip out Phillips screw heads. STRAIGHT SCREWDRIVER : A tool for opening paint cans. Sometimes used to convert common slotted screws into non-removable screws and butchering your palms. PRY BAR : A tool used to crumple the metal surrounding that clip or bracket you needed to remove in order to replace a 50 cent part. HOSE CUTTER : A tool used to make hoses too short. HAMMER : Originally employed as a weapon of war, the hammer nowadays is used as a kind of divining rod to locate the most expensive parts adjacent the object we are trying to hit. UTILITY KNIFE : Used to open and slice through the contents of cardboard cartons delivered to your front door; works particularly well on contents such as seats, vinyl records, liquids in plastic bottles, collector magazines, refund checks, and rubber or plastic parts. Especially useful for slicing work clothes, but only while in use. ADJUSTABLE WRENCH: aka "Another hammer", aka "Crescent Wrench". Commonly used as a one size fits all wrench, usually results in rounding off nut heads before the use of pliers. Will randomly adjust size between bolts, resulting in busted buckles, curse words, and multiple threats to any inanimate objects within the immediate vicinity. |
||||||
About The Embedded Muse | ||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||||||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||||||||||
Contents | ||||||||||||||
|
||||||||||||||
Editor''s Notes | ||||||||||||||
Tip for sending me email: My email filters are super aggressive. If you include the phrase "embedded muse" in the subject line your email will wend its way to me. Bad news for router users: a recent study looked at 127 routers (of the style used in homes) and found all have security problems. Major security problems. 50 of them have hard-coded passwords and the like. All run Linux, generally older versions. This raises the question: How does one support a product, especially as it ages? A big OS like Linux will always have bugs. How long should a vendor provide support for a product? Phil Matthews poses this interesting question: What childhood experiences influenced you to become an engineer? For me it was probably that my dad was a mechanical engineer working in the space program, though how I got interested in electronics I don''t remember. I did build a crystal radio at 8 or 9 years of age, and always liked building "forts" and other items. I got a ham license at 16 and had a lab in the basement from an early age. My interest has always been in building stuff, an interest that has never waned. What was your experience? |
||||||||||||||
Quotes and Thoughts | ||||||||||||||
One should expect that the expected can be prevented but that the unexpected should have been expected. Unknown author |
||||||||||||||
Tools and Tips | ||||||||||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. There has been some discussion of inexpensive PCB vendors in the Muse lately. I recently found that Digikey has a PCB service that gets quotes from a half-dozen vendors here. Chris Bucsko wrote:
Joe Vandzura responded to an article in the last Muse:
|
||||||||||||||
Freebies and Discounts | ||||||||||||||
Jake Michael won last month''s Binho Nova Multi-Protocol USB Host Adapters. This month''s giveaway is a LA104 mini logic analyzer. I reviewed it in Muse 406. Enter via this link. |
||||||||||||||
Replies to "Is Assembly Language Dead as a Dodo?" | ||||||||||||||
A ton of people replied to this article in the last Muse. Most said they write little Assembler code but read a fair amount. And there was some discussion about whether "Assembler" should be capitalized. I bow to the general consensus that it should be... and wonder where the word came from. Here are a handful of reader replies. Dan Daly wrote:
From Chris van Niekerk:
James Thayer, like your editor, goes back to the early days of this field:
Tom Mazowiesky often writes and sent this:
Steve Paik''s insights are worthwhile:
Tony Garland dives into Assembler when needed:
Daniel McBreaty bridges comments on Assembler with another Muse article on taking charge/continuous learning:
|
||||||||||||||
On Taking Charge | ||||||||||||||
Plenty of email also came in regarding the article in the last Muse about Taking Charge. Some highlights follow. Neil Cherry wrote:
Steve Paik sent this:
Finally, a reader who wishes to remain anonymous poses an interesting question:
|
||||||||||||||
Failure of the Week | ||||||||||||||
From Leon Bazdar: |
||||||||||||||
Jobs! | ||||||||||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||||||||||
Joke For The Week | ||||||||||||||
These jokes are archived here. A bug in the code is worth two in the documentation. |
||||||||||||||
About The Embedded Muse | ||||||||||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
The Embedded Muse now goes to over 40,000 subscribers. |
||||
Quotes and Thoughts | ||||
Let''s disagree without being disagreeable - Laurene Powell Jobs |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Gerald DeSantis wrote:
|
||||
Freebies and Discounts | ||||
September''s giveaway is courtesy of Binho, and is one of their Nova Multi-Protocol USB Host Adapters with accessories (reviewed later in this issue). Enter via this link. |
||||
The Rust Programming Language | ||||
James Munns is a big advocate of Rust, and he contributed the following article: The Rust Programming Language has been steadily growing in usage and popularity in the five years since its 1.0 release in 2015 (and in the 14 years since its inception in 2006). Although it is a systems language, with comparative performance and control to languages like C, C++, and Ada, it has also taken inspiration from more modern languages, including best-in-class tooling, package and configuration management, testing infrastructure, and other conveniences provided out of the box. As a language, Rust aims to empower **everyone** to build reliable and efficient software: from resource-light embedded systems, to high performance server software. Rust as a language has a number of features, including a strong type system, and a concept of "data ownership", that allow it to guarantee thread and memory safety at compile time, preventing issues such as use-after-frees, data races, and buffer overruns. These safety checks exist primarily at compile time, meaning they can be used effectively for any target system. These foundational concepts make a huge difference between static analysis that can catch bugs some or most of the time, and compile time errors for potential bugs.
The standard library also provides a number of built-in features, such as iterators, pattern matching, tagged enums, and more, which can also be used to write code that is more descriptive of what the developer is doing, rather than how the computer should do it. These features allow for aggressive optimizations at compile time, making them suitable for resource limited systems. The Rust standard library is split into two main parts, "std" and "core", the latter of which can still be used on systems without an Operating System or Allocator. This means that a wide variety of libraries can be used interchangeably on embedded and non-embedded systems, without customization required.
Rust also has a vibrant and widely used package repository, crates.io, with (at the time of writing) nearly 46,000 crates (or packages) available, and over 3.7B crate downloads. This allows for a huge amount of reusable code, and quick iteration and development cycles. This package manager also tracks tools that can be used to help with development, including static analysis tools for code size or speed, tools for embedded logging and testing, and tools for automatic generation of bindings between C, C++, and Rust code bases. Rust has built-in support for FFI interoperability with other languages, making it straightforward to combine languages like Rust and C within a single project.
Over the past five years or so, Rust has gained wide adoption in a number of industries, and is being used in production by companies including Dropbox, Cloudflare, Threema, Microsoft Azure, and more. The Rust project has an RFC based open governance process, allowing for adaptations and changes over time based on needs. This open process has also allowed the project to grow out of its original home at Mozilla, moving into its own foundation later this year. Despite all of these continuous changes, and
having a stable compiler release every 6 weeks, Rust has a strong backwards compatibility guarantee: code you write today will always compile on future versions of Rust.
Since 2018, Rust has also had a specific focus on embedded systems, with bare-metal targets becoming a first class stable target for Rust development. Currently, Rust supports bare-metal Arm Cortex-A, Cortex-R, and Cortex-M devices, RISC-V CPUs, the MSP430 architecture, and more recently, Atmel''s AVR architecture. Rust also supports a wide variety of embedded Linux targets as well. The Rust compiler supports cross compilation natively, which means that you don''t need separate tooling for your desktop and embedded development efforts.
Rust is continuing to progress (particularly for embedded systems), adding support for new tools for embedded development, adding support for new platforms like the Xtensa architecture (which powers ESP32 and ESP8266 processors), and preparing Rust for use in Safety Critical markets, based on interest from the Automotive industry.
Although languages like C, C++, and Ada are not going to be going away any time soon due to the huge investments, niche and legacy targets, and largely working code bases already in wide usage, Rust is working to be an excellent choice for new or critical projects or software components, where performance, development speed, and correctness are paramount. If you''re looking to get started with Rust, check out the Rust Bookshelf, where there are a number of free books and courses for getting started, the Embedded Rust Bookshelf, a similar set of free and open source resources for embedded systems, or reach out to us at Ferrous Systems for guided training or advice.
James Munns is an embedded systems engineer, and Managing Director at Ferrous Systems GmbH in Berlin, Germany. James has experience in a variety of domains, including safety critical avionics, robotics, and gas detection, as well as connected IoT devices. Ferrous Systems GmbH is the largest software consultancy worldwide focused on the Rust Programming Language. Ferrous Systems provides services in advising, development, and training, and has experience developing embedded systems and systems level software in Rust. |
||||
Debugging Embedded and Real-Time Systems | ||||
Arnold Berger has a new book out and his publisher graciously sent me a copy. Debugging Embedded and Real-Time Systems is a worthy addition to the literature. Arnie teaches embedded systems at the University of Washington, and I was stunned to read in this volume that the Circuits 1 students get a breadboard and they actually construct and test circuits. When I went to college circuit theory was entirely theory. A later lab class was a joke of playing with multimeters. So while the pundits complain of education going to hell in a handbasket, my hat is off to the U of W for a class rich in practicum. This book is really aimed at students, and I think it should be a part of the pedagogy of every CS and EE department. Arnie pushes the idea of using a disciplined approach to debugging. Over the decades I''ve seen (and have participated in) too many shotgunning sessions. Sometimes these work though more often much time is wasted. And sometimes a "fix" is masking tape over the wrong issue, creating more havoc later. The book is about debugging embedded systems; not hardware, not software, but both the hardware and the software, which is means it''s written assuming the reader is familiar with both. Though it does zero in on each in isolation at times, it''s a broadly-focused work that should appeal to all embedded practitioners, especially those at the intersection of the two disciplines. When it does come to software Arnie''s first advice is to write bug-free code. For that he presents a strategy. He admits we''ll never be perfect, but the unfortunate truth is that many of us write firmware figuring on long sessions with the debugger instead of employing every means possible to avoid errors. The same is true for hardware, and he presents a number of ideas for designing the hardware correctly. Some of this will be obvious to old-timers; for newbies, not so much so. An example: Use pullups on the bus to implement a NOP so you can run tests without memory loaded. I prefer a software interrupt instruction, when possible, as that will create write cycles as well. A scope or logic analyzer will show all of the resulting bus activity (if any!). Chapter five is a good overview of the tools we use. I was surprised that the oscilloscope didn''t get its own section, though many references are made to that tool in other places. One tidbit I''ve been advocating for years: Keep a debugging log. Have you ever chased a bug for days and find yourself repeating a test, simply because you forgot you ran it? I have. A log documents the process in a disciplined way. Some concepts will be new to even many experienced hands. Ever hear of SIMICS? It''s a fascinating tool I''ve been following for some years, and I''m told Intel (which owns it) uses it to evaluate most of their products. Arnie highly praises going to the Embedded Systems Conference. Alas, that show is a shadow of its former self. Once that advice was spot-on. Today I recommend Embedded World (in Germany) as that gathering is huge and dynamic. Arnie presents lots of anecdotes from his career which makes for fun reading. Debugging Embedded and Real-Time Systems is a quick and easy read that condenses a lot of useful information into 285 pages. Every student of our profession should read it and embrace the concepts. Experienced readers will pick up useful nuggets as well. If there''s one nit to pick it''s the $80 price tag, a price that''s becoming all too common for tech books. I sheepishly admit my own books are also way too expensive. The Embedded Systems Dictionary, which I co-wrote with Mike Barr, is currently $143 on Amazon. Perhaps that explains its pathetic sales! |
||||
The Binho Nova Multi-Protocol USB Host Adapter | ||||
Binho sent me one of their Nova Multi-Protocol USB Host Adapters. I wasn''t quite sure what such a device is or does, so went to the company''s web page, which didn''t shed enough light for a dullard like me to understand. A lot of web sites today are very pretty yet they don''t clearly state what the company is selling. We used to talk about having an elevator speech: a 15 second explanation of what you do. Too many web sites neglect that. However, this page gives an excellent description of the Nova. It is basically an interface between a PC''s USB port and common interfaces found in embedded systems. In particular, the device can interface to devices that communicate via I2C, SPI, UART, 1-WIRE, and SWI. On one side of the device is a USB connector; on the other is a flat ribbon cable with power and ground signals, plus five pins for connecting to these interfaces. Pinouts are: Why would you want to do this? Early in development it may be easier to develop prototype code for a device driver on a PC rather than in the less-friendly cross-development environment. The Nova can also enable automatic testing of devices in an embedded system. And it can be a nice way to download code to flash memory in production. Steve Jobs taught us that beauty can be combined with functionality, and a few makers of test equipment (notably Saleae''s logic analyzers) have profited from that lesson. Binho, too, provides a unit in a slim, elegant metal package, which in turn is shipped in a quite attractive hard case. A GUI interface named "Mission Control" is available for Windows, Linux and Macs. It''s self explanatory. For example, to control an SPI device: An alternative mode lets you use these 5 pins as GPIO connections or A/D inputs. One can be a DAC. Four can be PWMs with controllable frequency and duty cycle. The Mission Control GUI is a clean and easy way to interface to the device, but the real power comes from Python libraries that let you write code to send and receive data at speed via the Nova to your hardware. I did not try this, but the web site contains numerous examples, all too long to list here. You can also drive the Nova from a command terminal like Tera Term. Binho''s web site has very clear step-by-step instructions for installing and using the device. I do wish they were available as a single PDF as I like to keep user manuals on my disk, and prefer random access access rather than stepping through web pages. At $149 the Nova is a very affordable way to tie a PC to an embedded system using any of these serial interfaces. The GUI is simple and powerful. If you''re willing to write some Python code, there''s really no limit to the control you could exercise over a device. |
||||
Failure of the Week | ||||
Another heart rate fail to complement the one in the last Muse. According to the CDC the max heart rate is 220-(age in years) which means this poor person is negative four billion years old. I guess that means he or she will be born about the time the sun turns into a cinder. I suspect at that time we''ll be programming 8051s in C0xFFFFFFFF. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad. |
||||
Joke For The Week | ||||
These jokes are archived here. From Phil Matthews: Everybody trusts a hardware engineer, except themselves. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
The Embedded Muse now goes to over 40,000 subscribers. |
||||
Quotes and Thoughts | ||||
Let''s disagree without being disagreeable - Laurene Powell Jobs |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Gerald DeSantis wrote:
|
||||
Freebies and Discounts | ||||
September''s giveaway is courtesy of Binho, and is one of their Nova Multi-Protocol USB Host Adapters with accessories (reviewed later in this issue). Enter via this link. |
||||
The Rust Programming Language | ||||
James Munns is a big advocate of Rust, and he contributed the following article: The Rust Programming Language has been steadily growing in usage and popularity in the five years since its 1.0 release in 2015 (and in the 14 years since its inception in 2006). Although it is a systems language, with comparative performance and control to languages like C, C++, and Ada, it has also taken inspiration from more modern languages, including best-in-class tooling, package and configuration management, testing infrastructure, and other conveniences provided out of the box. As a language, Rust aims to empower **everyone** to build reliable and efficient software: from resource-light embedded systems, to high performance server software. Rust as a language has a number of features, including a strong type system, and a concept of "data ownership", that allow it to guarantee thread and memory safety at compile time, preventing issues such as use-after-frees, data races, and buffer overruns. These safety checks exist primarily at compile time, meaning they can be used effectively for any target system. These foundational concepts make a huge difference between static analysis that can catch bugs some or most of the time, and compile time errors for potential bugs.
The standard library also provides a number of built-in features, such as iterators, pattern matching, tagged enums, and more, which can also be used to write code that is more descriptive of what the developer is doing, rather than how the computer should do it. These features allow for aggressive optimizations at compile time, making them suitable for resource limited systems. The Rust standard library is split into two main parts, "std" and "core", the latter of which can still be used on systems without an Operating System or Allocator. This means that a wide variety of libraries can be used interchangeably on embedded and non-embedded systems, without customization required.
Rust also has a vibrant and widely used package repository, crates.io, with (at the time of writing) nearly 46,000 crates (or packages) available, and over 3.7B crate downloads. This allows for a huge amount of reusable code, and quick iteration and development cycles. This package manager also tracks tools that can be used to help with development, including static analysis tools for code size or speed, tools for embedded logging and testing, and tools for automatic generation of bindings between C, C++, and Rust code bases. Rust has built-in support for FFI interoperability with other languages, making it straightforward to combine languages like Rust and C within a single project.
Over the past five years or so, Rust has gained wide adoption in a number of industries, and is being used in production by companies including Dropbox, Cloudflare, Threema, Microsoft Azure, and more. The Rust project has an RFC based open governance process, allowing for adaptations and changes over time based on needs. This open process has also allowed the project to grow out of its original home at Mozilla, moving into its own foundation later this year. Despite all of these continuous changes, and
having a stable compiler release every 6 weeks, Rust has a strong backwards compatibility guarantee: code you write today will always compile on future versions of Rust.
Since 2018, Rust has also had a specific focus on embedded systems, with bare-metal targets becoming a first class stable target for Rust development. Currently, Rust supports bare-metal Arm Cortex-A, Cortex-R, and Cortex-M devices, RISC-V CPUs, the MSP430 architecture, and more recently, Atmel''s AVR architecture. Rust also supports a wide variety of embedded Linux targets as well. The Rust compiler supports cross compilation natively, which means that you don''t need separate tooling for your desktop and embedded development efforts.
Rust is continuing to progress (particularly for embedded systems), adding support for new tools for embedded development, adding support for new platforms like the Xtensa architecture (which powers ESP32 and ESP8266 processors), and preparing Rust for use in Safety Critical markets, based on interest from the Automotive industry.
Although languages like C, C++, and Ada are not going to be going away any time soon due to the huge investments, niche and legacy targets, and largely working code bases already in wide usage, Rust is working to be an excellent choice for new or critical projects or software components, where performance, development speed, and correctness are paramount. If you''re looking to get started with Rust, check out the Rust Bookshelf, where there are a number of free books and courses for getting started, the Embedded Rust Bookshelf, a similar set of free and open source resources for embedded systems, or reach out to us at Ferrous Systems for guided training or advice.
James Munns is an embedded systems engineer, and Managing Director at Ferrous Systems GmbH in Berlin, Germany. James has experience in a variety of domains, including safety critical avionics, robotics, and gas detection, as well as connected IoT devices. Ferrous Systems GmbH is the largest software consultancy worldwide focused on the Rust Programming Language. Ferrous Systems provides services in advising, development, and training, and has experience developing embedded systems and systems level software in Rust. |
||||
Debugging Embedded and Real-Time Systems | ||||
Arnold Berger has a new book out and his publisher graciously sent me a copy. Debugging Embedded and Real-Time Systems is a worthy addition to the literature. Arnie teaches embedded systems at the University of Washington, and I was stunned to read in this volume that the Circuits 1 students get a breadboard and they actually construct and test circuits. When I went to college circuit theory was entirely theory. A later lab class was a joke of playing with multimeters. So while the pundits complain of education going to hell in a handbasket, my hat is off to the U of W for a class rich in practicum. This book is really aimed at students, and I think it should be a part of the pedagogy of every CS and EE department. Arnie pushes the idea of using a disciplined approach to debugging. Over the decades I''ve seen (and have participated in) too many shotgunning sessions. Sometimes these work though more often much time is wasted. And sometimes a "fix" is masking tape over the wrong issue, creating more havoc later. The book is about debugging embedded systems; not hardware, not software, but both the hardware and the software, which is means it''s written assuming the reader is familiar with both. Though it does zero in on each in isolation at times, it''s a broadly-focused work that should appeal to all embedded practitioners, especially those at the intersection of the two disciplines. When it does come to software Arnie''s first advice is to write bug-free code. For that he presents a strategy. He admits we''ll never be perfect, but the unfortunate truth is that many of us write firmware figuring on long sessions with the debugger instead of employing every means possible to avoid errors. The same is true for hardware, and he presents a number of ideas for designing the hardware correctly. Some of this will be obvious to old-timers; for newbies, not so much so. An example: Use pullups on the bus to implement a NOP so you can run tests without memory loaded. I prefer a software interrupt instruction, when possible, as that will create write cycles as well. A scope or logic analyzer will show all of the resulting bus activity (if any!). Chapter five is a good overview of the tools we use. I was surprised that the oscilloscope didn''t get its own section, though many references are made to that tool in other places. One tidbit I''ve been advocating for years: Keep a debugging log. Have you ever chased a bug for days and find yourself repeating a test, simply because you forgot you ran it? I have. A log documents the process in a disciplined way. Some concepts will be new to even many experienced hands. Ever hear of SIMICS? It''s a fascinating tool I''ve been following for some years, and I''m told Intel (which owns it) uses it to evaluate most of their products. Arnie highly praises going to the Embedded Systems Conference. Alas, that show is a shadow of its former self. Once that advice was spot-on. Today I recommend Embedded World (in Germany) as that gathering is huge and dynamic. Arnie presents lots of anecdotes from his career which makes for fun reading. Debugging Embedded and Real-Time Systems is a quick and easy read that condenses a lot of useful information into 285 pages. Every student of our profession should read it and embrace the concepts. Experienced readers will pick up useful nuggets as well. If there''s one nit to pick it''s the $80 price tag, a price that''s becoming all too common for tech books. I sheepishly admit my own books are also way too expensive. The Embedded Systems Dictionary, which I co-wrote with Mike Barr, is currently $143 on Amazon. Perhaps that explains its pathetic sales! |
||||
The Binho Nova Multi-Protocol USB Host Adapter | ||||
Binho sent me one of their Nova Multi-Protocol USB Host Adapters. I wasn''t quite sure what such a device is or does, so went to the company''s web page, which didn''t shed enough light for a dullard like me to understand. A lot of web sites today are very pretty yet they don''t clearly state what the company is selling. We used to talk about having an elevator speech: a 15 second explanation of what you do. Too many web sites neglect that. However, this page gives an excellent description of the Nova. It is basically an interface between a PC''s USB port and common interfaces found in embedded systems. In particular, the device can interface to devices that communicate via I2C, SPI, UART, 1-WIRE, and SWI. On one side of the device is a USB connector; on the other is a flat ribbon cable with power and ground signals, plus five pins for connecting to these interfaces. Pinouts are: Why would you want to do this? Early in development it may be easier to develop prototype code for a device driver on a PC rather than in the less-friendly cross-development environment. The Nova can also enable automatic testing of devices in an embedded system. And it can be a nice way to download code to flash memory in production. Steve Jobs taught us that beauty can be combined with functionality, and a few makers of test equipment (notably Saleae''s logic analyzers) have profited from that lesson. Binho, too, provides a unit in a slim, elegant metal package, which in turn is shipped in a quite attractive hard case. A GUI interface named "Mission Control" is available for Windows, Linux and Macs. It''s self explanatory. For example, to control an SPI device: An alternative mode lets you use these 5 pins as GPIO connections or A/D inputs. One can be a DAC. Four can be PWMs with controllable frequency and duty cycle. The Mission Control GUI is a clean and easy way to interface to the device, but the real power comes from Python libraries that let you write code to send and receive data at speed via the Nova to your hardware. I did not try this, but the web site contains numerous examples, all too long to list here. You can also drive the Nova from a command terminal like Tera Term. Binho''s web site has very clear step-by-step instructions for installing and using the device. I do wish they were available as a single PDF as I like to keep user manuals on my disk, and prefer random access access rather than stepping through web pages. At $149 the Nova is a very affordable way to tie a PC to an embedded system using any of these serial interfaces. The GUI is simple and powerful. If you''re willing to write some Python code, there''s really no limit to the control you could exercise over a device. |
||||
Failure of the Week | ||||
Another heart rate fail to complement the one in the last Muse. According to the CDC the max heart rate is 220-(age in years) which means this poor person is negative four billion years old. I guess that means he or she will be born about the time the sun turns into a cinder. I suspect at that time we''ll be programming 8051s in C0xFFFFFFFF. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad. |
||||
Joke For The Week | ||||
These jokes are archived here. From Phil Matthews: Everybody trusts a hardware engineer, except themselves. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
I''m told Embedded World, held this past February in N?rnberg, was a Coronavirused-shell of its former glory. The 2021 affair will be held in March. Hundreds of exhibitors have already signed up. And the Embedded Systems Conference in Silicon Valley is on in January. I admire the optimism of the promoters and exhibitors, but wonder if the conference world will be reshaped by the pandemic. In many disciplines the future is reasonably clear: history curricula changes slowly, in English literature grammar is nearly immutable. Electronics is different; it has always been hard to guess what we''ll see a couple of years hence, and we engineers have grown comfortable with this uncertainty. But today even the near-future a month or three out seems awfully murky. I hope things improve enough to encourage travel and that these important conferences are big successes. What are your thoughts about the future of in-person conferences? Will you be comfortable attending these, and will your company be willing to pay for the travel? Jack''s latest blog: The GP-8E, my first computer |
||||
Quotes and Thoughts | ||||
All programmers are optimists. Fred Brooks |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Like many hobbyists, as a teenager I learned to design circuits. College augmented those practical lessons with theoritical rigor. But only when employed as an EE did I learn how to design circuits that worked and were reliable. One mentor helped me with that as he critiqued each design decision, sometimes to an infuriating degree. I don''t see much in writing about this, but Jason Sachs'' recent article on managing tolerance is very worthwhile. |
||||
Freebies and Discounts | ||||
July''s giveaway, courtesy of Firia Labs, is one of their Explorer Kits, which includes 2?micro:bit?circuit board computers and associated components for experimenting. Enter via this link. |
||||
Know Your Numbers | ||||
Do you know your how many defects will be injected into the next product during development? Or how many of those your team will fix before releasing it to the customer? If not. why not? Capers Jones has written: "All software managers and quality assurance personnel should be familiar with these measurements because they have the largest impact on software quality, cost, and schedule of any known measures." Jones is one of the world''s authorities on software engineering and software metrics. He often makes it clear that teams that don''t track defect metrics are working inefficiently at best. He suggests we track "defect potentials" and "defect removal efficiency." His article "Software Benchmarking" in the October 1995 issue of IEEE Computer defines "The defect potential of a software application is the total quantity of errors found in requirements, design, source code, user manuals, and bad fixes or secondary defects inserted as an accidental byproduct of repairing other defects." In other words, defect potential is the total of all mistakes injected into the product during development. Jones says the defect potential typically ranges between two and ten per function point, and for most organizations is about the number of function points raised to the 1.25 power. Function points are only rarely used in the embedded industry; we think in terms of lines of code (LOC). Though the LOC metric is hardly ideal we do our analysis with the metrics we have. Referring once again to Jones'' work, his November 1995 article "Backfiring: Converting Lines of Code to Function Points" in IEEE Computer claims one function point equals, on average, about 128 lines of C. "Defect removal efficiency" tells us what percentage of those flaws will be removed prior to shipping. That''s an appalling 85% in the US. But in private correspondence he provided me with figures that suggest embedded projects are by far the best of the lot, with an average defect removal efficiency of 95%, if truly huge (1m function points) projects are excluded. Jones claims only 5% of software organizations know their numbers. Yet in the many hundreds of embedded companies I''ve worked with, only two or three track these metrics. Since defects are a huge cause of late projects it''s seems reasonable to track them. And companies that don''t track defects can never know if they are best in class. or the very worst, which, in a glass-half-full way suggests lots of opportunities to improve. What''s your take? What metrics does your company track? |
||||
Zone Triggering | ||||
A common complaint heard from tools vendors is that customers don''t know how to use some of the important features. From a user perspective, you''ve got dozens of instruments, each accompanied by a 500 page manual - who has the time to read all of that material? But some of those overlooked features can save a lot of time. Today some oscilloscopes have a very cool feature that can be occasionally a lifesaver called "zone triggering." You define a region of the screen that will start an acquisition if a signal strays into it. For instance, here''s a 10 KHz sine wave with a 6 us pulse that''s added to it once a second: Normally this signal would be almost impossible to capture as it occurs so infrequently, and happens with a voltage level that''s within the normal sine wave. Here I''ve defined a little square zone trigger visible as a small box on the leading edge of the pulse. Anything that wanders into that box triggers the scope. Nothing else does. The scope I used is a Siglent SDS5034X, though I know Tektronix and other support this feature on some of their instruments. The box is created using iPhone-like pinch-and-squeeze fingers on the touchscreen, though it''s possible to set this up parametrically. This scope supports a pair of zone triggers; each can cause a trigger if a signal wanders into the zone, or if it is found outside that region. Or, the two can be combined with an AND operation for more nuanced acquisitions. A common use is to find bus contention where conflicting signals drive the voltage level to some value between a zero and a one. Or locating a short noise burst on an analog waveform. |
||||
Software Element Out of Context | ||||
The notion of a "Software Element Out of Context" is gaining in importance in safety-critical code, and I''ve been getting an increasing amount of email from readers wanting to learn more. I asked Dave Hughes of HCC Embedded if he could provide some background, which he graciously did, as follows: All of computing history has been about creating building blocks and constantly improving and reconstructing them. This is equally true at both a software and hardware level; think about how you put together a PC or mobile phone; or how you build the software in them. It is a continuous process of improvement and in most cases the building blocks are built without an exact knowledge of the end-product. They just have a general use-case of which simple examples might be a microcontroller in hardware or a RTOS in software. A great description of components like this is "elements out of context" - they were designed to a specification and the integrator must ensure that these elements do what is required. You can think of standard software libraries in the same way: as something designed without the complete context of its final usage being defined. When we get to safety things change. Building a product that has safety considerations is completely different to standard products. A complete assessment of the risks associated with the device must be done and development methods used that fully mitigate those risks. However, safety products need to use proven technology, be it a microcontroller in an air bag or piece of networking software for relaying sensor information. For this reason, we need a methodology for ensuring that the appropriate level of risk mitigation can be done for these elements. In the automotive industry the ISO 26262 standard developed the concept of the Safety Element out of Context (SEooC) - taking general purpose components and integrating them with the development of a road vehicle. The standard covers the whole process of how you validate the element and gives several options for how you achieve this. The two main methods are to use proven-in-use arguments which is really only suitable for hardware components (software does not wear out) or by providing a full set of ISO 26262 development artefacts for the element ready to support its integration. The key to the whole process is the two sets of assumptions that are made. Firstly, there are the assumptions that the target system makes of the SEooC, and secondly the assumptions the SEooC makes of any system to which is integrated. If these are a perfect match, then you can integrate the element and validate it. Normally there will be gaps, particularly if it is software (since any change requires retesting). If changes are required, then you go through a tailoring process. Normally it is the SEooC that needs tailoring and if it has been developed within a safety development process with full traceability then this can be achieved relatively efficiently. Although this is an automotive standard, I see it as a methodology that should be mappable to any other industry, particularly for software where it is the process is more comprehensive a portable than in any other standard I have seen. Although software safety standards are heavily verticalized (ISO26262 for Automotive, IEC 62304 for medical devices, DO178C for aerospace; to name a few of very many) safety software in all industries has the same basic requirements in terms of specification, design, implementation, test and most importantly traceability. It is traceability that gives you the ability to modify with confidence when there are slightly different assumptions made by the target system. For a more detailed description of how SEooCs can be used for software please try our white paper that can be downloaded from: www.hcc-embedded.com/seooc Click on picture to get a full-sized image. |
||||
Failure of the Week | ||||
An ATM in Baltimore: |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. The Definition of an Upgrade: Take old bugs out, put new ones in. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
I''m told Embedded World, held this past February in N?rnberg, was a Coronavirused-shell of its former glory. The 2021 affair will be held in March. Hundreds of exhibitors have already signed up. And the Embedded Systems Conference in Silicon Valley is on in January. I admire the optimism of the promoters and exhibitors, but wonder if the conference world will be reshaped by the pandemic. In many disciplines the future is reasonably clear: history curricula changes slowly, in English literature grammar is nearly immutable. Electronics is different; it has always been hard to guess what we''ll see a couple of years hence, and we engineers have grown comfortable with this uncertainty. But today even the near-future a month or three out seems awfully murky. I hope things improve enough to encourage travel and that these important conferences are big successes. What are your thoughts about the future of in-person conferences? Will you be comfortable attending these, and will your company be willing to pay for the travel? Jack''s latest blog: The GP-8E, my first computer |
||||
Quotes and Thoughts | ||||
All programmers are optimists. Fred Brooks |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Like many hobbyists, as a teenager I learned to design circuits. College augmented those practical lessons with theoritical rigor. But only when employed as an EE did I learn how to design circuits that worked and were reliable. One mentor helped me with that as he critiqued each design decision, sometimes to an infuriating degree. I don''t see much in writing about this, but Jason Sachs'' recent article on managing tolerance is very worthwhile. |
||||
Freebies and Discounts | ||||
July''s giveaway, courtesy of Firia Labs, is one of their Explorer Kits, which includes 2?micro:bit?circuit board computers and associated components for experimenting. Enter via this link. |
||||
Know Your Numbers | ||||
Do you know your how many defects will be injected into the next product during development? Or how many of those your team will fix before releasing it to the customer? If not. why not? Capers Jones has written: "All software managers and quality assurance personnel should be familiar with these measurements because they have the largest impact on software quality, cost, and schedule of any known measures." Jones is one of the world''s authorities on software engineering and software metrics. He often makes it clear that teams that don''t track defect metrics are working inefficiently at best. He suggests we track "defect potentials" and "defect removal efficiency." His article "Software Benchmarking" in the October 1995 issue of IEEE Computer defines "The defect potential of a software application is the total quantity of errors found in requirements, design, source code, user manuals, and bad fixes or secondary defects inserted as an accidental byproduct of repairing other defects." In other words, defect potential is the total of all mistakes injected into the product during development. Jones says the defect potential typically ranges between two and ten per function point, and for most organizations is about the number of function points raised to the 1.25 power. Function points are only rarely used in the embedded industry; we think in terms of lines of code (LOC). Though the LOC metric is hardly ideal we do our analysis with the metrics we have. Referring once again to Jones'' work, his November 1995 article "Backfiring: Converting Lines of Code to Function Points" in IEEE Computer claims one function point equals, on average, about 128 lines of C. "Defect removal efficiency" tells us what percentage of those flaws will be removed prior to shipping. That''s an appalling 85% in the US. But in private correspondence he provided me with figures that suggest embedded projects are by far the best of the lot, with an average defect removal efficiency of 95%, if truly huge (1m function points) projects are excluded. Jones claims only 5% of software organizations know their numbers. Yet in the many hundreds of embedded companies I''ve worked with, only two or three track these metrics. Since defects are a huge cause of late projects it''s seems reasonable to track them. And companies that don''t track defects can never know if they are best in class. or the very worst, which, in a glass-half-full way suggests lots of opportunities to improve. What''s your take? What metrics does your company track? |
||||
Zone Triggering | ||||
A common complaint heard from tools vendors is that customers don''t know how to use some of the important features. From a user perspective, you''ve got dozens of instruments, each accompanied by a 500 page manual - who has the time to read all of that material? But some of those overlooked features can save a lot of time. Today some oscilloscopes have a very cool feature that can be occasionally a lifesaver called "zone triggering." You define a region of the screen that will start an acquisition if a signal strays into it. For instance, here''s a 10 KHz sine wave with a 6 us pulse that''s added to it once a second: Normally this signal would be almost impossible to capture as it occurs so infrequently, and happens with a voltage level that''s within the normal sine wave. Here I''ve defined a little square zone trigger visible as a small box on the leading edge of the pulse. Anything that wanders into that box triggers the scope. Nothing else does. The scope I used is a Siglent SDS5034X, though I know Tektronix and other support this feature on some of their instruments. The box is created using iPhone-like pinch-and-squeeze fingers on the touchscreen, though it''s possible to set this up parametrically. This scope supports a pair of zone triggers; each can cause a trigger if a signal wanders into the zone, or if it is found outside that region. Or, the two can be combined with an AND operation for more nuanced acquisitions. A common use is to find bus contention where conflicting signals drive the voltage level to some value between a zero and a one. Or locating a short noise burst on an analog waveform. |
||||
Software Element Out of Context | ||||
The notion of a "Software Element Out of Context" is gaining in importance in safety-critical code, and I''ve been getting an increasing amount of email from readers wanting to learn more. I asked Dave Hughes of HCC Embedded if he could provide some background, which he graciously did, as follows: All of computing history has been about creating building blocks and constantly improving and reconstructing them. This is equally true at both a software and hardware level; think about how you put together a PC or mobile phone; or how you build the software in them. It is a continuous process of improvement and in most cases the building blocks are built without an exact knowledge of the end-product. They just have a general use-case of which simple examples might be a microcontroller in hardware or a RTOS in software. A great description of components like this is "elements out of context" - they were designed to a specification and the integrator must ensure that these elements do what is required. You can think of standard software libraries in the same way: as something designed without the complete context of its final usage being defined. When we get to safety things change. Building a product that has safety considerations is completely different to standard products. A complete assessment of the risks associated with the device must be done and development methods used that fully mitigate those risks. However, safety products need to use proven technology, be it a microcontroller in an air bag or piece of networking software for relaying sensor information. For this reason, we need a methodology for ensuring that the appropriate level of risk mitigation can be done for these elements. In the automotive industry the ISO 26262 standard developed the concept of the Safety Element out of Context (SEooC) - taking general purpose components and integrating them with the development of a road vehicle. The standard covers the whole process of how you validate the element and gives several options for how you achieve this. The two main methods are to use proven-in-use arguments which is really only suitable for hardware components (software does not wear out) or by providing a full set of ISO 26262 development artefacts for the element ready to support its integration. The key to the whole process is the two sets of assumptions that are made. Firstly, there are the assumptions that the target system makes of the SEooC, and secondly the assumptions the SEooC makes of any system to which is integrated. If these are a perfect match, then you can integrate the element and validate it. Normally there will be gaps, particularly if it is software (since any change requires retesting). If changes are required, then you go through a tailoring process. Normally it is the SEooC that needs tailoring and if it has been developed within a safety development process with full traceability then this can be achieved relatively efficiently. Although this is an automotive standard, I see it as a methodology that should be mappable to any other industry, particularly for software where it is the process is more comprehensive a portable than in any other standard I have seen. Although software safety standards are heavily verticalized (ISO26262 for Automotive, IEC 62304 for medical devices, DO178C for aerospace; to name a few of very many) safety software in all industries has the same basic requirements in terms of specification, design, implementation, test and most importantly traceability. It is traceability that gives you the ability to modify with confidence when there are slightly different assumptions made by the target system. For a more detailed description of how SEooCs can be used for software please try our white paper that can be downloaded from: www.hcc-embedded.com/seooc Click on picture to get a full-sized image. |
||||
Failure of the Week | ||||
An ATM in Baltimore: |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. The Definition of an Upgrade: Take old bugs out, put new ones in. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||||||||||||||||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||||||||||||||||||||
Contents | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
Editor''s Notes | ||||||||||||||||||||||||
Last issue''s articles about Knowledge Capture and Hardware, Software or Hardware/Software generated a flood of correspondence. It wasn''t possible to include all of your replies, but so many had so much to say that this issue of the Muse is focused on some of those replies. Thanks for all of the feedback, which I always appreciate. |
||||||||||||||||||||||||
Quotes and Thoughts | ||||||||||||||||||||||||
Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time. David Akin |
||||||||||||||||||||||||
Tools and Tips | ||||||||||||||||||||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Referring to a note in the last Muse, David Strip wrote:
Jerry Mulchin responded to thoughts on cheap PCBs:
And Dave Smart wrote:
Sergio Caprile responded to my thoughts about state machines:
Francois Baldassari also had a useful link for finite state machines:
|
||||||||||||||||||||||||
Freebies and Discounts | ||||||||||||||||||||||||
Dainius Stankevicius won the Firia Labs Explorer Kit in the July contest. Firia Labs is donating one of their CodeBots (a Python-enabled robot with a host of sensors) for this month''s giveaway. Enter via this link. |
||||||||||||||||||||||||
More on Knowledge Capture | ||||||||||||||||||||||||
Anton Ivanovsky was one of many responding to the article on capturing knowledge:
Ted wrote:
Eric Geller corrected my reference to OneNote:
Graham wrote:
George sent this:
Carl Palmgrenhas a couple of suggestions:
Neil Cherry is in DevOps:
Frequent contributor Luca Matteini wrote:
In Robert Lange''s submission, (DFMEA = Design Failure Mode and Effects Analysis, CAR = Corrective Action Report, typically a root cause analysis of a failure:
Daniel McBrearty likes those who can look at a problem from 10,000 meters:
Martin Glunz is a systems person:
J.G.Harston was slightly off topic but brings up an important point:
|
||||||||||||||||||||||||
More on Hardware, Software, or Hardware/Software? | ||||||||||||||||||||||||
John Sloan and many others had thoughts about this article in the last Muse:
Boi Okken wrote:
Steve Taylor made an important point about the Socratic Method::
I''m a fan of the Socratic Method, which is basically a process of helping people figure things out by asking good questions. It''s far better to mentor a young engineer by using questioning to help that person gain understanding than simply tossing off an answer. John Kougoulos wrote:
John''s comments on specialization resonated with me. My dad was a mechanical engineer who worked on Apollo at Grumman. He told me one of the engineers there was the world''s expert in designing wheels for lunar roving vehicles. I''ve always wondered what happened to that person post-Apollo? Specialization can be useful, but remember that technology moves on and that certain skill can be obsolete overnight. Francois Baldassari figures it''s all about seniority:
|
||||||||||||||||||||||||
Failure of the Week | ||||||||||||||||||||||||
S. Stewart sent this. When the Wyze watch Android app doesn''t sync on Blue Tooth it seems to fill some data fields with 72123: |
||||||||||||||||||||||||
Jobs! | ||||||||||||||||||||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||||||||||||||||||||
Joke For The Week | ||||||||||||||||||||||||
These jokes are archived here. Outage (as in Internet outage): Isn''t it interesting how close that is in spelling to "outrage"? |
||||||||||||||||||||||||
About The Embedded Muse | ||||||||||||||||||||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
Tip for sending me email: My email filters are super aggressive. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me. Jack''s latest blog: One of my favorite books: A Canticle for Leibowitz. Though 60 years old its focus on troubled times and moral issues is still relevant. |
||||
Quotes and Thoughts | ||||
Hardware works best when it matters the least. |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Tom Reaney likes vbuilder:
Tom included a sample flowchart which is much to big to include here, but is awfully impressive. Responding to Brian Cuthie''s thoughts about watchdogs, Til Stork writes:
|
||||
Freebies and Discounts | ||||
This month''s giveaway is a BattLab-One current profiler from Bluebird-Labs. A review of this unit follows. Enter via this link. |
||||
The BattLab-One Current Profiler | ||||
Battery-operated systems are the rage today, now that pretty amazing MCUs only sip at a stream of electrons. I''ve written extensively about optimizing these systems and have reviewed a number of tools to monitor power consumption. A new entrant is the BattLab-One. Bluebird-Labs sent me one to play with, and this is this month''s giveaway. The BattLab-One is in a small but robust aluminum case. Connected to a PC via USB it replaces a device under test''s (DUT) battery. A very intuitive PC application drives the unit, though it is slow to load. The user interface. I''ve added the red numbers to facilitate this discussion. Click on the image to call up a full-sized one in your browser. First, some specs:
As mentioned, the BattLab-One replaces the battery in your DUT: The UI image above shows the application after I''ve captured some DUT data in both active and sleep modes. I added the red number "1" which is an area where you set the battery parameters. I''ve selected a LiFePO4 cell; the application automatically populates the other entries like battery capacity, voltage, and the like, but these fields can be edited as needed. I collected 20 seconds worth of data, which for the DUT I used covers a wake and portions of a sleep period. The graph shows active peaks of about 175 mA and, at the end, a big drop as the DUT goes to sleep. Average active current is displayed (87.9 mA) and average sleep (165.18 µA). There are two ways to capture data: press the "Capture Active" or "Capture Sleep" buttons, or configure your DUT to assert a triggering signal that the BattLab-One uses to start acquisition. This means in some cases you''ll have to configure your system, perhaps by instrumenting the code, to assert a trigger signal to start acquisition. Or, one can tell the tool to acquire for a long time and get a representative overall view of the DUT''s operation. Sleep current is shown as an average value only (it shows up in the graph but is so much less than the active value that it''s hard to discern much quantitative data). But this is just the start. The BattLab-One''s raison-d''etre is to play with different scenarios to optimize a DUT''s energy consumption. At label "2" in the picture there are a number of parameters you can noodle with. Change some, and at label "3" the tallies will update. Perhaps a longer sleep time might be an option. In the picture I changed that from 60s to 1000s, and the "captured" battery life goes from 2.94 to 34.32 days. And that''s pretty cool. There are some nice features that the manual doesn''t address well. One is the "Persist Sense Resistor" (an undescriptive name) option. If you''re collecting sleep data you''ll probably select the 10 µA to 800 µA range. That uses a 100 ohm sense resistor; if the DUT were to come out of sleep mode it''s possible the burden current would inhibit its operation. If unchecked "Persist Sense Resistor" automatically jumps back to the high-current (800 µA to 500 mA) range. Checked, that 100 ohm resistor stays in play. The curve at the bottom right shows the characteristics of the selected battery. The red dot indicates the point where it is effectively dead, but that can be changed in the parameters at label "1". I do wish there were three, instead of two, current ranges. The low range is 10 µA to 800 µA, which is probably fine for most designs, but ultra-low power systems sometimes have sleep currents of under a µA. And it would be nice to see a graph of the sleep-mode current, though that isn''t really necessary when using the tool in its usual "what-if" mode (item "2" in the picture) to see how to optimize a system''s energy consumption. Bluebird-Labs tells me they will be adding the ability to capture and graph the sleep data. Jetperch''s Joulescope is my preferred energy monitor, but it''s nearly 10x the cost of the BattLab-One, and it doesn''t support "what-if" optimization doodling. At $99, or $79 as a bare board, the BattLab-One is a cost-effective tool for measuring and modeling a system''s ampish behavior. Recommended. |
||||
A Look Back: The In-Circuit Emulator | ||||
Several readers have written recently asking for some historical background on in-circuit emulators (ICE). These are mostly extinct debugging tools that dominated the embedded industry from the 70s till the end of the 90s. Today these have been replaced by JTAG debuggers (like SEGGER''s J-Link and IAR''s I-Jet). The first ICE was Intel''s MDS-800, aka "blue box", a physically imposing tool for developing 8080 code. Around 1975 my boss, in an unusual moment of lucidity, let me buy one for a staggering $20k ($100k in today''s dollars). It gave us most of the resources emulators provided 25 years later with the exception of source-level debugging. That was not much of a problem as all embedded work was done in Assembly language at the time. Remember ISIS? No, not that one. ISIS was the MDS-800''s operating system. The unit needed an OS as it did have mass storage: two 8" floppy disks storing around 80 KB each. An ICE physically replaced the CPU/MCU in a target system. These tools were boxes that sported a large cable going to a plug; the user pulled the CPU chip from its socket and inserted the ICE plug in its place. A processor in the tool replicated the action of the target''s CPU; substantial circuitry allowed the user to do all of the usual debugging activities like setting breakpoints, single-stepping, inspecting registers and memory, etc. Unlike today''s debuggers ICEs contained RAM that could be mapped into the address space of the target. Flash memory didn''t really show up till the end of the emulator era so it was common for firmware to reside in EPROM. It was tedious to change EPROM''s contents: one had to place the chips under a UV light for tens of minutes and then "re-burn" the code into the devices. The emulator''s RAM logically replaced the EPROM at the same addresses but allowed the developer to quickly download new code or patch changes. Decent emulators included more sophisticated features like performance analyzers that watched what the code was doing in real time to find bottlenecks, trace logic to capture execution flows, and very sophisticated breakpoints. Many of these features are now available in modern JTAG-style debuggers. While ICEs for CPUs generally ran user code on a processor identical to the one in the target board, MCUs posed special problems. With their own on-board memory it was often impossible to watch a bus to see what the core was doing. The semiconductor people understood this and made special versions of the chips available to ICE vendors. These "bond-out" parts had hundreds of pins to bring all bus activity out. Made in tiny volumes, they were a special curse to all involved. Expensive, yes. And often the silicon was a few revisions behind that which customers could buy, as there was no profit in keeping these parts up to date. Some were just sloppy. I remember working with a Toshiba bond-out part in a ceramic package where the top of the chips would just fall off! On the other hand, Intel was pretty good at keeping their bond-outs current. But even CPUs had problems. Cache made bus monitoring impossible, so ICE vendors had to tell customers to leave cache off during development. Prefetchers would fetch instructions that might later be discarded; to make trace data sensible the source debugger had to simulate the CPU''s behavior and filter out discarded instructions. And then there were parts that should never have come to market. Zilog''s Z280, for instance, was a nightmare of a chip that turned an ICE into a fabulously-complex Rube Goldberg of electronics (Heath Robinson to our British friends). This was Zilog''s last hand-laid-out chip (Xacto-knife cutouts from Rubylith), which was eventually orphaned when they lost the layout! I have to chuckle when developers today complain about a several hundred dollar debugger. For two reasons: we''re paid a lot of money, and these tools greatly speed our work. And in the ICE days an emulator could cost tens of thousands of dollars. Plug it in backwards and expensive smoke poured out. Pricing didn''t kill the emulator: technology did. As clock rates rose it became impossible to propagate signals over a cable to a CPU socket. (I found those two college courses on electromagnetics baffling but designing and supporting emulators made the subject very real and very important). Imagine the travails of sending a bus over a 30 cm cable with today''s multi-hundred MHz clocks! An in-circuit emulator for a 186 processor. The little boards plug into a target''s CPU socket. All of the bus signals are propagated to the big box over the ribbon cable, a James Clerk Maxwell nightmare as clock speeds soared. But CPU sockets went away when everyone started soldering CPUs to the board. There were some clumsy workarounds; it was possible to clip onto a PLCC package and tri-state its outputs, but a butterfly flapping its wings in Brazil could make the connection unreliable. BGA processors made any sort of connection impossible. I was doing a classified project with an oddball microprocessor and designed an emulator just for that, but slowly a light dawned that this could be a product. I re-engineered it for more mainstream 8 bitters and it sold well. With only 17 ICs (in the 80s ICs were pretty simple parts) and horribly-complex code it went for $600. All emulators at this point had just one or a few breakpoints as they used comparators to match a breakpoint address. I used a 64K x 1 RAM that watched the target''s address bus. Writing a one into any location caused a breakpoint, so the emulator had 64k breakpoints. I learned, though, that customer support was a huge issue since every target system was different: impedances and voltage levels varied and some target designs were not particularly robust. We designed a succession of much more powerful products that sold for ten times the price. Support was about the same for a $6000 product as for the $600 version. One of the fun parts of being an ICE vendors was working with semiconductor vendors as they developed new processors. We''d get early silicon which invariably had a slew of flaws; finding those was challenging and interesting. Sometimes the silicon didn''t exist and we''d get a very large board populated with lots of FPGAs programmed to act as the silicon (hopefully!) would. The emulator business imploded at the beginning of this century, and few of those vendors exist in any form today. Applied Microsystems was the biggest, selling some $40m of these tools a year. They folded. Lauterbach probably made the best ICEs and they still sell some legacy (68k and 186) products. I sold my emulator business in 1997; it prospered for a while but suffered from a new owner who didn''t understand the business. Emulators came of age when transistors were expensive, so processors had no on-board debugging resources. We''re very fortunate today that so many include so much debugging capability. The result: many vendors sell really great JTAG-style tools for a song. |
||||
Muse 408 Responses | ||||
Here are a couple of reader replies to the last Muse. Stuart Jobbins responded to Get it Wrong, Pay the Price:
Robbie Tonneberger added his story about becoming an engineer:
|
||||
Failure of the Week | ||||
Dave Smart sent in this week''s failure: -196 degrees seems to be a theme; I have a lot of these ridiculous failures where that temperature is displayed. Any ideas why? Oh, and the coldest temperature ever recorded in nature on Earth is -129 degrees at the Soviet Antarctic research station, so that might be a reasonable lower bound when deciding if a temperature is reasonable. The lesson is an old one: check your results! |
||||
This Week''s Cool Product | ||||
Ambiq has been pushing ultra-low power MCUs for some time. Their new Apollo 4 is claimed to require only 3 uA/MHz, which is about an order of magnitude less than other columb-adverse micros. Alas, the web site is pretty poor and neither datasheets nor pricing seems to be available. I assume this is a "typical" or "best case" number. However, the part does include an FPU and wide range of peripherals. Instead of flash it uses MRAM (Magnetoresistive Random-Access Memory). It will be available in a BGA, and intriguigly, an WLCSP package. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. Tim Hoerauf sent this topical joke: It may be confusing to some which holiday we''re observing, Halloween or Christmas, because OCT(31) = DEC(25)! |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||
Contents | ||||||
|
||||||
Editor''s Notes | ||||||
Tip for sending me email: My email filters are super aggressive. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me. Are you comfortable designing with FPGAs? I think this is a skill that is going to be highly marketable. This article shows these parts are becoming much more common. One note: C programmers may find Verilog or VHDL a little odd. Unlike C code, where each statement executes in succession, in general in an HDL everything is running at the same time. In fact, it often doesn''t matter which order the HDL statements are coded. |
||||||
Quotes and Thoughts | ||||||
We''re absolutely going to deliver on time on this project. We were too overconfident on the last one. |
||||||
Tools and Tips | ||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Mark Rubin has what looks like a handy utility:
Bob Paddock sent this link to the definitive computer industry glossary of terms. Phil Koopman, noted Carnegie Mellon professor, has made his embedded software course material available online. The course covers software quality, safety, and security. For those who don''t do YouTube, videos and handouts are here as well. David Thomas posed an interesting question: Does anyone have tips on keeping a workbench reasonably tidy? I find that it''s not long before scope probes and other leads are snaking all over the bench, tools scattered around, and components piled up. Much as I admired the man, I try to avoid a Jim Williams'' like bench:
|
||||||
Freebies and Discounts | ||||||
Murdo McLeod won the BattLab-One tool in last month''s contest. This month''s giveaway is a Pico 2207B 70 MHz USB scope, which I review later in this Muse. Enter via this link. |
||||||
A Buck50 Logic Analyzer | ||||||
Need a logic analyzer but Covid has depleted your cash reserves? Can you shell out $1.50? Mark Rubin has created the "buck50" logic analyzer which has a UI that runs under Linux/Unix and maybe (this is untested) a Mac. This isn''t a product that he sells. It''s completely open source. Source code and documents are here. And it is extremely well documented. The hardware is just a "Blue Pill" STM32F103 eval board, widely available for a dollar-fifty. You buy the board, download the firmware, and install the application. You''ll want to solder a header to the board for test probes. Features include:
As Mark says: "At $1.50 for the hardware plus $0.00 for the firmware and software, if there''s a competition for the world''s cheapest logic analyzer I want to enter it. Please note this is very much a beta release and bug reports are welcome." Way cool! |
||||||
Pico 2207B USB Scope Review | ||||||
Pico Technology is one of the pioneers in USB oscilloscopes. They sell a huge range of test instruments and related gear; their website, though frustratingly slow, is worth perusing. The company sent me their 2207B MSO, a 2 channel 70 MHz scope with a 64 MS buffer, and 1 GHz sample rate. It collects 80,000 waveforms per second. Though I tested this using their Windows application, they have beta versions for Linux and Macs. The unit comes nicely boxed with an excellent full color poster showing the UI, with annotations describing how each element works. It''s too big to reproduce here but I commend Pico for this "lagniappe" (a Louisiana term meaning a bonus gift). Also included is a soft carrying case, two scope probes, and digital logic probes. A quick start guide is included, but you''ll want to download the 239 page user manual from their web site. If you didn''t know anything about the company, you''d quickly infer that they''ve been in the scope business for some time. The manual, in PDF form and a help file, is extensive and very complete. And the scope simply works. There''s no fiddling with USB setups. No connection hiccups. Pico UI. Click on image for a bigger version. The UI is complete and totally intuitive. Channel control, horizontal and vertical, is on the top ribbon. Triggering and measurements on the bottom. Channel A is in blue; on the left side of the screen the voltage levels are shown. Channel B''s voltages, in red, are on the right. I''ve added an arrow to show the trigger position, denoted by a yellow dot. You can change this by simply dragging that dot to any position on the waveform. In the previous picture I added peak-to-peak and frequency measurements, which are shown on the bottom of the screen. I counted 19 of these which include two kinds of RMS and pulse counts. But those tiny numbers sure are hard to see, aren''t they? The UI, though, allows one to select any font size for these. For instance: As is common on digital scopes, there''s a zoom feature to narrow which part of the buffer is shown. Unusually, a "picture in a picture" shows a really nice image of where in the buffer the zoomed display is presented. It''s easy to grab the cursor in that small image to drag the zoomed display around. I was disappointed that you can only select vertical and horizontal ranges using the usual 1-2-5 sequence until discovering that the channel selection button lets you type any range. And in that menu for the vertical signals there''s a bandwidth limit option, which is also freely selectable - you''re not limited to a few canned bandwidths. The spectrum analyzer mode gives a remarkably accurate and clear display. The following shows a quite pure 10 MHz sine wave. Note the frequency labels below the waveform. Though at the far bottom left the scale is shown in kHz, I would prefer that the axis be labeled. Instead of the bland "1000" shown, it would be better to show "1000 kHz". 23 serial protocol decoders are included, and each can be set up using either the analog or digital channels. Also supported: mask testing, where one defines a "legal" waveform and an alarm or trigger occurs when the sampled wave falls out of the legal range. Like most scopes, the Pico will do math. For instance, one can display a waveform that represents A+B. Unlike most, you can create your own equations. This is one example: Not long ago I asked Siglent to add this feature to their scopes, which they did. I had been working on a system with rotating components. My report had screen shots showing RPM indirectly, as a frequency measurement. How much better to show actual RPM! The model tested has 16 digital channels. These are arranged in two groups, and the threshold voltages can be set to any value for each group. Finally, the unit includes an arbitrary waveform generator that will produce the usual signals up to 1 MHz with 12 bits of resolution. Nothing ground-breaking there. Want a custom wave? A single click brings up a waveform editor which lets you create anything. This is the easiest-to-use waveform creator I''ve come across... and it''s downright fun to use. The following took about three seconds to build: The 2000 series of PicoScopes, of which this unit is a member, ranges from 10 MHz, 2 analog channels, 100 MS/S sample rate and no digital channels for $139, to 100 MHz, 4 analog, 128 MS memory for $1125. The unit I tested sells for $769. More info here. Bottom line: This is the best USB scope I''ve tested. |
||||||
Failure of the Week | ||||||
From Martin Grill: |
||||||
This Week''s Cool Product | ||||||
Want to play with AI? Google is offering their "AIY" (Artificial Intelligence Yourself) kits. Currently available are kits for playing with AI for voice and for vision. Looks like fun! Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||
Jobs! | ||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||
Joke For The Week | ||||||
These jokes are archived here. TOOLS EXPLAINED DRILL PRESS : A tall upright machine useful for suddenly snatching flat metal bar stock out of your hands so that it smacks you in the chest and flings your beer across the room, denting the freshly-painted project which you had carefully set in the corner where nothing could get to it. WIRE WHEEL : Cleans paint off bolts and then throws them somewhere under the workbench with the speed of light. Also removes fingerprints and hard-earned calluses from fingers in about the time it takes you to say, ''Oh sh*t'' CHOP SAW : A portable cutting tool used to make studs too short. PLIERS : Used to round off bolt heads. Sometimes used in the creation of blood-blisters. BELT SANDER : An electric sanding tool commonly used to convert minor touch-up jobs into major refinishing jobs. HACKSAW : One of a family of cutting tools built on the Ouija board principle... It transforms human energy into a crooked, unpredictable motion, and the more you attempt to influence its course, the more dismal your future becomes. VISE-GRIPS : Generally used after pliers to completely round off bolt heads. If nothing else is available, they can also be used to transfer intense welding heat to the palm of your hand. OXYACETYLENE TORCH : Used almost entirely for lighting on fire various flammable objects in your shop. Also handy for igniting the grease inside the wheel hub out of which you want to remove a bearing race. TABLE SAW : A large stationary power tool commonly used to launch wood projectiles for testing wall integrity. HYDRAULIC FLOOR JACK : Used for lowering an automobile to the ground after you have installed your new brake shoes, trapping the jack handle firmly under the bumper. BAND SAW : A large stationary power saw primarily used by most shops to cut good aluminum sheet into smaller pieces that more easily fit into the trash can after you cut on the inside of the line instead of the outside edge. TWO-TON ENGINE HOIST : A tool for testing the maximum tensile strength of everything you forgot to disconnect. PHILLIPS SCREWDRIVER : Normally used to stab the vacuum seals under lids or for opening old-style paper-and-tin oil cans and splashing oil on your shirt; but can also be used, as the name implies, to strip out Phillips screw heads. STRAIGHT SCREWDRIVER : A tool for opening paint cans. Sometimes used to convert common slotted screws into non-removable screws and butchering your palms. PRY BAR : A tool used to crumple the metal surrounding that clip or bracket you needed to remove in order to replace a 50 cent part. HOSE CUTTER : A tool used to make hoses too short. HAMMER : Originally employed as a weapon of war, the hammer nowadays is used as a kind of divining rod to locate the most expensive parts adjacent the object we are trying to hit. UTILITY KNIFE : Used to open and slice through the contents of cardboard cartons delivered to your front door; works particularly well on contents such as seats, vinyl records, liquids in plastic bottles, collector magazines, refund checks, and rubber or plastic parts. Especially useful for slicing work clothes, but only while in use. ADJUSTABLE WRENCH: aka "Another hammer", aka "Crescent Wrench". Commonly used as a one size fits all wrench, usually results in rounding off nut heads before the use of pliers. Will randomly adjust size between bolts, resulting in busted buckles, curse words, and multiple threats to any inanimate objects within the immediate vicinity. |
||||||
About The Embedded Muse | ||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
In Muse 395 I ran a series of pictures of temperature displays showing totally absurd readings. A lot of readers responded, so with this issue I''m introducing a new section entitled "Failure of the Week." This will feature amusing, frustrating, and ridiculous embedded failures. I have a huge collection of these. Many have lessons we should learn, though too many of those are the same lesson: Check your goesintas and goesoutas. Jack''s latest blog is a guest post: Problems In Ramping Up Ventilator Production |
||||
Quotes and Thoughts | ||||
Eric Smith sent this: A Tony Hoare quote that is perhaps more applicable to embedded system programming: "Later, we asked the customers whether they wanted the option to be able turn off the type checking in production. It''s a bit like wearing a life jacket when you are practicing drills, but then taking it off the ship was sinking. The customers decided to not switch off the type checking." |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. |
||||
Freebies and Discounts | ||||
Rod Philips won last month''s micro:bit. Firia Labs is donating one of their CodeBots (a Python-enabled robot with a host of sensors) for this month''s giveaway. Enter via this link. |
||||
µC/OS Goes Open Source | ||||
Most readers probably know of Micrium, the company whose µC/OS RTOS and related products have been very popular in the industry. I''ve known Jean Labrosse, the founder, for decades and have long admired his company. And I''ve long admired the code base, which is incredibly clean. How clean? It is certifiable to numerous standards, including the rigorous avionics DO-178C. Micrium was acquired by Silicon Labs a few years ago, but very recently that company has pretty much abandoned the Micrium product line. µC/OS-II and µC/OS-III and many of the other parts of their stack are now open source. Dozens of processor families are supported. The source code is here. One of Micrium''s marketing strategies was to sell a number of well-written deeply-technical books about the products. I always liked the fact that some are tailored for particular processors, so a reader can immediately run example code on specific platforms. PDFs of these are now free. Support for the product line is now available from Weston Embedded Solutions in the USA and Embedded Office in Germany. Validated Software is one company that provides certification packages for safety-critical applications. In the avionics world that''s DO-178C, and the Micrium products are certifiable to level A, the most stringent. From their website: Ninety percent of the ?C/OS Validation Suite is "pre-existing" and has been used for "previously certified" software. I presume that as long as users don''t monkey with the code this statement will remain valid. And not monkeying with the code is a feature Weston Embedded seems to embrace. From their website: Cesium RTOS [is] a commercially licensed RTOS that is derived from Micrium''s uC/OS products and completely free from modification by open source contributors. An unusual statement in our times when open source has attained religious stature, but if certification to safety-critical standards is important, one doesn''t want every Tom, Dick and Jill changing things. Rolando Ingles of Weston Embedded told me that Cesium is the Micrium RTOS stack. The company will continue to maintain that code and extend it as needed, while maintaining the clean code standards of the predecessor company. Micrium will be honoring support agreements till the end of the year. Customers will come to Weston Embedded or Embedded Office for licenses, support and consulting (e.g., creating new BSPs, ports, device drivers and the like). Interestingly, he says some customers have bought licenses instead of getting the open source code as they feel that approach is cheaper than getting OSS through their legal department. This is a time of great change in the RTOS business. Amazon acquired FreeRTOS. Microsoft bought Express Logic (ThreadX and related components). The products are easier to use than the old days; SEGGER has a demo that can get a novice running their RTOS in under 5 minutes. Do you need an RTOS? Not all projects do. But this is an area where careful up-front design is critical. In the very early 1980s I designed an instrument that had quite a few I/Os, figuring it would be easy enough to handle everything via polling and some interrupts. A combination of requirements growth and my poor planning meant that I eventually had to shoehorn an RTOS into the (now extant) code. That was a nightmare that bloated the schedule... and taught me the importance of good design. I''m often asked how does one know when an RTOS is needed. There''s no generic answer, but if the system needs to run multiple independent activities, it''s time to consider adding one. An example: if a display needs to be updated at some rate, inputs monitored, communications is going on, an OS might be a good choice. Sure, one can handle these activities with a simple interrupt-driven design, but as the complexity grows that can get out of hand. Some engineers avoid OSes because they worry about determinism. We know that under all the wrong conditions, like a perfect storm of interrupts, preemptive multitasking can fail to schedule all of the tasks. And multitasking can create problems with locks and priority inversion. These are legitimate concerns, though there are solutions to many of them. |
||||
Salary/Coronavirus Survey Results | ||||
Last month I did a salary survey and here are the results. First, average income (estimated by respondents including benefits) by region: In the USA here''s salary by years of experience: There wasn''t enough data to create meaningful years of experience vs income for other regions. Worldwide, we''re, on average, 42 years old with 19 years of experience. What''s with the dearth of 45-49 year old engineers? The IEEE has long complained that for unknown reasons EEs leave the field mid-career, and I guess we''re seeing that effect here. Probably those that remain engineers later in life are culled because the just love the field. In fact, on a scale from 0 to 3 (from "hate it" to "love it") the average happiness with our careers is 2.35, about in line with data from previous years'' surveys. 49% of respondents expect a "Strong demand for engineers." 6% expect the demand to diminish and 43% expect the demand to remain unchanged. 54% of consultants report business is about the same as last year; only 14% report it getting better. The rest are seeing business trail off. Consultants'' average rate is $104/hour, but the range is huge: $50 to $330 with a median of $82. What about the effect of the novel coronavirus? (This data is from the first three weeks of April. As this situation is evolving rapidly the numbers may, too). 2% have lost their jobs. Another 2% are not working and not being paid. Only 1% are not working but continue to draw a salary. 13% are still going to the office every day, which leaves a whopping 82% of us working from home. We''re fortunate to have a career that allows such flexibility. Many people left comments. A few of the more interesting ones follows:
Thanks to everyone who participated. |
||||
Failure of the Week | ||||
Ed Criscuolo sent this: A man went to an ATM to withdraw some money, and found a "glitch" changed his balance from $13 to $8.2 million. The story is here. |
||||
This Week''s Cool Product | ||||
I''ve been following Eta Compute for a while. Like some other vendors, their interest is putting a little machine learning capability at the "edge" - in a microcontroller right at the sensors. What makes them a bit different is their focus on doing this at extremely low power levels. Eta''s new ECM3532 is an MCU with a Cortex M3 and DSP with dual MACs. The latter, of course, is optimized for multiply-accumulate operations, which are at the heart of inferencing. The company claims (I''ve seen their eval boards running off 1 cm2 solar cells) power consumption of under 5 µA/MHz, which is around an order of magnitude better than most ultra-low-power MCUs. Instead of dynamic voltage and frequency scaling, they tout continuous voltage and frequency scaling, with a near-threshold low-end Vdd of 0.54 V. Near- and sub-threshold operation yields very low power operation at low frequencies. Ambiq is one of the pioneers in this area. FETs can operate in three regions: subthreshold, linear, and saturated. But in the subthreshold region leakage is a problem, and temperature even more so. Transistors are not well characterized at those voltage levels, so vendors resort to clever, often secret, tricks. I''m told digital watches, at least the non-smart versions, operate in the subthreshold region giving them tremendous battery lives. For more on subthreshold voltage operation of FETs see this. One of those tricks Eta uses is a non-synchronous architecture. Though there is a clock, the logic isn''t conventionally clocked. It''s self-timed. Synchronous circuits need plenty of margin to insure all of the timing is properly closed; self-timed versions report back as soon as an operation has completed so the next can begin. Absent this, since FETs operating in or near the subthreshold region can have wildly-varying characteristics depending on temperature, huge setup and hold margins would have to be designed in. Why would anyone want an inferencing engine at the edge? Potential uses include listening for wake-up words (think "Hey Google"), sensing glass breaking, and even a bit of image recognition. Local processing means less bandwidth to the cloud, and a lot less power consumption as comm protocols can drain batteries quickly. Samples of the ECM3532 are available today. In production volumes they will be under $5. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad. |
||||
Joke For The Week | ||||
These jokes are archived here. And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies. - Linus Torvalds |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||
Contents | ||||||
|
||||||
Editor''s Notes | ||||||
It has been two years since my last salary survey. Follow this link to take the 2020 version (it''s only a dozen questions), which also has a question probing your work in these coronavirus times. I''ll publish the results in the next issue. Three copies of The Art of Designing Embedded Systems will be awarded to three randomly-selected participants. CIS has created a non-profit initiative to help companies who are developing ventilators for the coronavirus crisis. It is for companies wishing to find engineering help and engineers wishing to provide their services free of charge. More info here. Also in the Coronavirus vein, here''s an article with suggestions about working from home. I received a lot of replies to my thoughts last issue about the IEEE. With only a single exception all complained that the organization offers little for practicing engineers other than Spectrum. One interesting thought was that the standards are developed by committees of volunteers, yet the IEEE sells them for inflated prices. Many, though, feel the life insurance program is a good deal. Jack''s latest blog: Life in the Time of Coronavirus |
||||||
Quotes and Thoughts | ||||||
"The process broke down in many areas," says NASA''s spaceflight chief Douglas Loverro. "We don''t know how many software errors we have. We don''t know if we have just two or we have many hundred." From Aviation Week and Space Technology, about Boeing''s Starliner capsule meant to ferry astronauts. The same article claims the system comprises about one million lines of code. Given that best-in-class companies ship code with about one error per thousand lines of code, it wouldn''t surprise me if the Starliner has hundreds or thousands of latent bugs. |
||||||
Tools and Tips | ||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. |
||||||
Freebies and Discounts | ||||||
This month''s giveaway is a BBC Micro:bit Go Bundle. Enter via this link. |
||||||
Response to the Joel Test | ||||||
In response to last issue''s article about Joel''s rules for evaluating a software team Rob Aberg wrote:
|
||||||
Reuse | ||||||
In Enabling Reuse-Based Software Development of Large-Scale Systems by Richard Selby the author looks at reuse in 25 systems comprising 2954 modules at NASA. Some interesting factoids pop out: Unsurprisingly, error rates are somewhat inversely proportional to amount of reuse. "Slight revision" means under 25% modifications, "Major revision" is more than 25%. The curve would have been much more interesting if more divisions of reuse were sampled: In another study of the same modules by the same author (Empirically Analyzing Software Reuse in a Production Environment) the cost savings from reuse were analyzed: This graph has long fascinated me as it blows away our usual thinking that there''s an inversely-linear relationship between reuse and development cost. Instead, it seems that once one changes around 20% of the code the cost savings from reuse rapidly diminish. An interesting additional tidbit from this code base: the median and mean of the number of comments per 100 source lines was virtually the same at 57. Other data I have for a study of comments at NSA found that their very best code averages 60 comments per 100 lines of code, and avionics code certified to the exacting DO-178 standard averages 70 comments per non-blank source line. (Comments can be either a line which is a comment, or a line of code that also contains a comment). |
||||||
Temperature Anomalies | ||||||
Though it''s a few days past April Fool''s Day, here are a few fun pictures from my collection of software errors resulting is absurd temperature displays: The moral: well, it''s the same I was taught 50 years ago: Check your goesints and goesoutas. Oh, and wash your hands! |
||||||
This Week''s Cool Product | ||||||
Xilinix has come up with some pretty cool ways to package chips. Max Maxfield explains. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||
Jobs! | ||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||
Joke For The Week | ||||||
These jokes are archived here. From Dejan Durdenic: Due to Coronavirus, all TCP applications are being converted to UDP to avoid handshake. |
||||||
About The Embedded Muse | ||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
Tip for sending me email: My email filters are super aggressive. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me. Jack''s latest blog: One of my favorite books: A Canticle for Leibowitz. Though 60 years old its focus on troubled times and moral issues is still relevant. |
||||
Quotes and Thoughts | ||||
Hardware works best when it matters the least. |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Tom Reaney likes vbuilder:
Tom included a sample flowchart which is much to big to include here, but is awfully impressive. Responding to Brian Cuthie''s thoughts about watchdogs, Til Stork writes:
|
||||
Freebies and Discounts | ||||
This month''s giveaway is a BattLab-One current profiler from Bluebird-Labs. A review of this unit follows. Enter via this link. |
||||
The BattLab-One Current Profiler | ||||
Battery-operated systems are the rage today, now that pretty amazing MCUs only sip at a stream of electrons. I''ve written extensively about optimizing these systems and have reviewed a number of tools to monitor power consumption. A new entrant is the BattLab-One. Bluebird-Labs sent me one to play with, and this is this month''s giveaway. The BattLab-One is in a small but robust aluminum case. Connected to a PC via USB it replaces a device under test''s (DUT) battery. A very intuitive PC application drives the unit, though it is slow to load. The user interface. I''ve added the red numbers to facilitate this discussion. Click on the image to call up a full-sized one in your browser. First, some specs:
As mentioned, the BattLab-One replaces the battery in your DUT: The UI image above shows the application after I''ve captured some DUT data in both active and sleep modes. I added the red number "1" which is an area where you set the battery parameters. I''ve selected a LiFePO4 cell; the application automatically populates the other entries like battery capacity, voltage, and the like, but these fields can be edited as needed. I collected 20 seconds worth of data, which for the DUT I used covers a wake and portions of a sleep period. The graph shows active peaks of about 175 mA and, at the end, a big drop as the DUT goes to sleep. Average active current is displayed (87.9 mA) and average sleep (165.18 µA). There are two ways to capture data: press the "Capture Active" or "Capture Sleep" buttons, or configure your DUT to assert a triggering signal that the BattLab-One uses to start acquisition. This means in some cases you''ll have to configure your system, perhaps by instrumenting the code, to assert a trigger signal to start acquisition. Or, one can tell the tool to acquire for a long time and get a representative overall view of the DUT''s operation. Sleep current is shown as an average value only (it shows up in the graph but is so much less than the active value that it''s hard to discern much quantitative data). But this is just the start. The BattLab-One''s raison-d''etre is to play with different scenarios to optimize a DUT''s energy consumption. At label "2" in the picture there are a number of parameters you can noodle with. Change some, and at label "3" the tallies will update. Perhaps a longer sleep time might be an option. In the picture I changed that from 60s to 1000s, and the "captured" battery life goes from 2.94 to 34.32 days. And that''s pretty cool. There are some nice features that the manual doesn''t address well. One is the "Persist Sense Resistor" (an undescriptive name) option. If you''re collecting sleep data you''ll probably select the 10 µA to 800 µA range. That uses a 100 ohm sense resistor; if the DUT were to come out of sleep mode it''s possible the burden current would inhibit its operation. If unchecked "Persist Sense Resistor" automatically jumps back to the high-current (800 µA to 500 mA) range. Checked, that 100 ohm resistor stays in play. The curve at the bottom right shows the characteristics of the selected battery. The red dot indicates the point where it is effectively dead, but that can be changed in the parameters at label "1". I do wish there were three, instead of two, current ranges. The low range is 10 µA to 800 µA, which is probably fine for most designs, but ultra-low power systems sometimes have sleep currents of under a µA. And it would be nice to see a graph of the sleep-mode current, though that isn''t really necessary when using the tool in its usual "what-if" mode (item "2" in the picture) to see how to optimize a system''s energy consumption. Bluebird-Labs tells me they will be adding the ability to capture and graph the sleep data. Jetperch''s Joulescope is my preferred energy monitor, but it''s nearly 10x the cost of the BattLab-One, and it doesn''t support "what-if" optimization doodling. At $99, or $79 as a bare board, the BattLab-One is a cost-effective tool for measuring and modeling a system''s ampish behavior. Recommended. |
||||
A Look Back: The In-Circuit Emulator | ||||
Several readers have written recently asking for some historical background on in-circuit emulators (ICE). These are mostly extinct debugging tools that dominated the embedded industry from the 70s till the end of the 90s. Today these have been replaced by JTAG debuggers (like SEGGER''s J-Link and IAR''s I-Jet). The first ICE was Intel''s MDS-800, aka "blue box", a physically imposing tool for developing 8080 code. Around 1975 my boss, in an unusual moment of lucidity, let me buy one for a staggering $20k ($100k in today''s dollars). It gave us most of the resources emulators provided 25 years later with the exception of source-level debugging. That was not much of a problem as all embedded work was done in Assembly language at the time. Remember ISIS? No, not that one. ISIS was the MDS-800''s operating system. The unit needed an OS as it did have mass storage: two 8" floppy disks storing around 80 KB each. An ICE physically replaced the CPU/MCU in a target system. These tools were boxes that sported a large cable going to a plug; the user pulled the CPU chip from its socket and inserted the ICE plug in its place. A processor in the tool replicated the action of the target''s CPU; substantial circuitry allowed the user to do all of the usual debugging activities like setting breakpoints, single-stepping, inspecting registers and memory, etc. Unlike today''s debuggers ICEs contained RAM that could be mapped into the address space of the target. Flash memory didn''t really show up till the end of the emulator era so it was common for firmware to reside in EPROM. It was tedious to change EPROM''s contents: one had to place the chips under a UV light for tens of minutes and then "re-burn" the code into the devices. The emulator''s RAM logically replaced the EPROM at the same addresses but allowed the developer to quickly download new code or patch changes. Decent emulators included more sophisticated features like performance analyzers that watched what the code was doing in real time to find bottlenecks, trace logic to capture execution flows, and very sophisticated breakpoints. Many of these features are now available in modern JTAG-style debuggers. While ICEs for CPUs generally ran user code on a processor identical to the one in the target board, MCUs posed special problems. With their own on-board memory it was often impossible to watch a bus to see what the core was doing. The semiconductor people understood this and made special versions of the chips available to ICE vendors. These "bond-out" parts had hundreds of pins to bring all bus activity out. Made in tiny volumes, they were a special curse to all involved. Expensive, yes. And often the silicon was a few revisions behind that which customers could buy, as there was no profit in keeping these parts up to date. Some were just sloppy. I remember working with a Toshiba bond-out part in a ceramic package where the top of the chips would just fall off! On the other hand, Intel was pretty good at keeping their bond-outs current. But even CPUs had problems. Cache made bus monitoring impossible, so ICE vendors had to tell customers to leave cache off during development. Prefetchers would fetch instructions that might later be discarded; to make trace data sensible the source debugger had to simulate the CPU''s behavior and filter out discarded instructions. And then there were parts that should never have come to market. Zilog''s Z280, for instance, was a nightmare of a chip that turned an ICE into a fabulously-complex Rube Goldberg of electronics (Heath Robinson to our British friends). This was Zilog''s last hand-laid-out chip (Xacto-knife cutouts from Rubylith), which was eventually orphaned when they lost the layout! I have to chuckle when developers today complain about a several hundred dollar debugger. For two reasons: we''re paid a lot of money, and these tools greatly speed our work. And in the ICE days an emulator could cost tens of thousands of dollars. Plug it in backwards and expensive smoke poured out. Pricing didn''t kill the emulator: technology did. As clock rates rose it became impossible to propagate signals over a cable to a CPU socket. (I found those two college courses on electromagnetics baffling but designing and supporting emulators made the subject very real and very important). Imagine the travails of sending a bus over a 30 cm cable with today''s multi-hundred MHz clocks! An in-circuit emulator for a 186 processor. The little boards plug into a target''s CPU socket. All of the bus signals are propagated to the big box over the ribbon cable, a James Clerk Maxwell nightmare as clock speeds soared. But CPU sockets went away when everyone started soldering CPUs to the board. There were some clumsy workarounds; it was possible to clip onto a PLCC package and tri-state its outputs, but a butterfly flapping its wings in Brazil could make the connection unreliable. BGA processors made any sort of connection impossible. I was doing a classified project with an oddball microprocessor and designed an emulator just for that, but slowly a light dawned that this could be a product. I re-engineered it for more mainstream 8 bitters and it sold well. With only 17 ICs (in the 80s ICs were pretty simple parts) and horribly-complex code it went for $600. All emulators at this point had just one or a few breakpoints as they used comparators to match a breakpoint address. I used a 64K x 1 RAM that watched the target''s address bus. Writing a one into any location caused a breakpoint, so the emulator had 64k breakpoints. I learned, though, that customer support was a huge issue since every target system was different: impedances and voltage levels varied and some target designs were not particularly robust. We designed a succession of much more powerful products that sold for ten times the price. Support was about the same for a $6000 product as for the $600 version. One of the fun parts of being an ICE vendors was working with semiconductor vendors as they developed new processors. We''d get early silicon which invariably had a slew of flaws; finding those was challenging and interesting. Sometimes the silicon didn''t exist and we''d get a very large board populated with lots of FPGAs programmed to act as the silicon (hopefully!) would. The emulator business imploded at the beginning of this century, and few of those vendors exist in any form today. Applied Microsystems was the biggest, selling some $40m of these tools a year. They folded. Lauterbach probably made the best ICEs and they still sell some legacy (68k and 186) products. I sold my emulator business in 1997; it prospered for a while but suffered from a new owner who didn''t understand the business. Emulators came of age when transistors were expensive, so processors had no on-board debugging resources. We''re very fortunate today that so many include so much debugging capability. The result: many vendors sell really great JTAG-style tools for a song. |
||||
Muse 408 Responses | ||||
Here are a couple of reader replies to the last Muse. Stuart Jobbins responded to Get it Wrong, Pay the Price:
Robbie Tonneberger added his story about becoming an engineer:
|
||||
Failure of the Week | ||||
Dave Smart sent in this week''s failure: -196 degrees seems to be a theme; I have a lot of these ridiculous failures where that temperature is displayed. Any ideas why? Oh, and the coldest temperature ever recorded in nature on Earth is -129 degrees at the Soviet Antarctic research station, so that might be a reasonable lower bound when deciding if a temperature is reasonable. The lesson is an old one: check your results! |
||||
This Week''s Cool Product | ||||
Ambiq has been pushing ultra-low power MCUs for some time. Their new Apollo 4 is claimed to require only 3 uA/MHz, which is about an order of magnitude less than other columb-adverse micros. Alas, the web site is pretty poor and neither datasheets nor pricing seems to be available. I assume this is a "typical" or "best case" number. However, the part does include an FPU and wide range of peripherals. Instead of flash it uses MRAM (Magnetoresistive Random-Access Memory). It will be available in a BGA, and intriguigly, an WLCSP package. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. Tim Hoerauf sent this topical joke: It may be confusing to some which holiday we''re observing, Halloween or Christmas, because OCT(31) = DEC(25)! |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
Jack''s latest blog: Superintelligence |
||||
Quotes and Thoughts | ||||
Everything is linear if plotted log-log with a fat magic marker. Mar''s Law |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Aleksandar Atanasovski sent the following. The tool does look pretty nice, and is reasonably priced:
|
||||
Freebies and Discounts | ||||
This month''s giveaway is a FRDM-KL25Z eval board based on the Cortex-M0+ microcontroller. The board is supported by mbed.org, which means you can do development without an IDE; the web site has an on-line compiler. The board appears as a disk drive on your PC. Compile the code with mbed''s on-line tool, copy the resulting file to the board, and the code runs. I wouldn''t build a real product with mbed, but it''s great for playing around and building experimental code. Enter via this link. |
||||
More Fast Trig | ||||
Harjit Singh sent another trig approximation:
This reminded me of an experiment I did a while ago with a 96 MHz Cortex M3 device and the mbed.org compiler. Using a lookup table of 256 entries, the MCU was able to generate a 10 KHz sine wave using 100% of the CPU cycles. The code looks like this: int i; for(;;) { for(i = 0; i < 256; i++)Aout.write_u16(sine[i]); } That''s 390 ns per table entry. I suspect most of that time is spent in mbed''s Aout.write_u16() function. |
||||
The Joel Test | ||||
Joel Spolsky has a long-running blog that has undergone several incarnations. I feel it is much less interesting than in years past when his focus was truly on software engineering. Today, the blog more often reflects his evolving interests in managing companies. In a 20-year-old posting, Joel lists his 12 rules for evaluating a software team:
The posting contains Joel''s rationale for each of these. A partial example about why using the best tools is important: "Top notch development teams don''t torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer." It''s hard to argue with that. My take on Joel''s rules is this:
|
||||
On Professional Organizations | ||||
A very long time ago, back when dinosaurs roamed the Earth, I was a student member of the IEEE. The cost was ridiculously low, the fellowship with other student members in our school''s engineering lounge irresistible, and the lure of being part of the larger community of professional engineers ineffably compelling. But the IEEE was a political mess. Over the objections of many of its members, IEEE officers, who were largely seen as academics and researchers with few ties to working engineers, campaigned vigorously for pro-immigration policies at a time with far too many native engineers were without a job. Gadfly Irwin Feerst (if you remember Irwin you''re, well, old!) was a colorful figure who opposed these and many other policies. Though he was never one to be politically correct or even careful in his speech he came within a few hundred votes of becoming president at one point. Many claimed the top brass changed the rules to keep him at bay. He took on the Institute''s publications, saying: "The IT Transactions are indeed full of crap. Most of the papers are written by academics and foreigners. There is nothing in there for working engineers like me. In fact, I can''t even tell if I''ve got it right side up or upside down." Today, half a century later, I still recall his comments when I see papers with titles like the following in IEEE Transactions on Software Engineering:
Feerst''s battles with the IEEE ended a long time ago and are no longer important. In my opinion some of the publications, like Spectrum, are now packed with information engineers find interesting. IEEE Computer is also pretty good, though it rarely addresses embedded issues. It does have some thought-provoking articles from time to time about ethics and the like, an increasingly important problem with software in control of dangerous equipment, like automobiles. The many Transactions publications are still for academics. Maybe age has brought me a less radical perspective, and I understand the need for some sort of balance between those of us who actually build products, and those seeking grants for conducting basic research. No doubt any professional organization has multiple and conflicting missions, satisfying no one entirely. The IEEE, IEEE Computer Society, and the ACM, are professional organizations targeted at us. Membership is expensive. Unforgivably so, if you select options like access to digital libraries. The ACM''s annual bill even has a bit of trickery designed to snare the unwary into giving extra donations to their foundations. But these groups offer value to us. It''s unaffordable for most engineers to belong to more than a single professional organization, which is a real shame. I remain conflicted about these groups, and sure wish the embedded world got more coverage. But they do offer value, if only in some of the resources offered via magazines and past publications stored on the web. What do you think? Are these sorts of professional organizations worthwhile? |
||||
This Week''s Cool Product | ||||
Though not cheap ($25k/year) zGlue has a technology called "ChipBuilder"tm that greatly simplifies building custom chips. They have a library of some 1500 "chiplets" (IP designs of assets that go on an IC) which can be connected via an interposer. I think Xilinx pioneered the interposer concept, which is a silicon interconnect that provides the "wiring" needed between chips on a single substrate. The interposer eliminates the delays and power requirements needed when sending signals off-chip using conventional connections. zGlue claims that their technology shrinks IC design times to minutes and manufacturing to weeks. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||
Joke For The Week | ||||
These jokes are archived here. And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies. -- Linus Torvalds |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||
Contents | ||||||
|
||||||
Editor''s Notes | ||||||
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes. Attendees have blogged about the seminar, for example, here, here and here. A couple of recent articles bring up some interesting ethical issues of tech in cars. Bob Paddock sent a link to this article where a dealer sold a second-hand Tesla to a new owner... and Tesla disabled the "full self-driving mode" feature via an over-the-air update because the new owner didn''t "pay" for the feature, even though the original owner did. Then there''s Bryon Moyer''s article where he describes a technology that allows automakers to verify that repairs only use OEM parts. Potentially, replacing something with an unauthorized widget could brick the car. |
||||||
Quotes and Thoughts | ||||||
Ways to detect or prevent software errors should be designed in from the beginning. If written first, error-handling routines will get the most exercise. Many (and perhaps most) errors in operational software lie in the error-handling routines themselves. Nancy Leveson |
||||||
Tools and Tips | ||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. William Grauer sent this:
Yigal Ben-Zeev likes VSC:
|
||||||
Freebies and Discounts | ||||||
This month''s giveaway is a FRDM-KL25Z eval board based on the Cortex-M0+ microcontroller. The board is supported by mbed.org, which means you can do development without an IDE; the web site has an on-line compiler. The board appears as a disk drive on your PC. Compile the code with mbed''s on-line tool, copy the resulting file to the board, and the code runs. I wouldn''t build a real product with mbed, but it''s great for playing around and building experimental code. Enter via this link. |
||||||
On Management, Redux | ||||||
In the last issue I took management to task for often not understanding the realities behind engineering and engineers. Now I''d like to discuss some truths about management that many engineers don''t grok. Dilbert consistently depicts managers as clueless morons untethered to the real world. I''ve run into some of those. Yet most are decent folks who are trying to do a good job, caught between the CEO''s needs and quite differing realities on the ground. Unfortunately, mid-level bosses are often promoted from technical work without being given any sort of management training. In engineering it works, or it doesn''t. If it doesn''t, it''s usually possible to figure out why. Management is much different. If you perturb an electronic system five times the same way, you''ll generally get five identical responses. Yet if you do the same to a person, you''ll get five different reactions. The science we prize just doesn''t work with people. Challenging? You bet. In many ways great management is more difficult than engineering. When things are working well, the boss is fending off a blizzard of requests for changes and features from his or her boss, sales, marketing, and more. Or at least filtering these to a reasonable few. Those people have very real needs, too, but those are often divorced from the company''s requirements. How often have you heard a sales person say "I can''t sell this piece of crap without ?X, Y and Z"? Sometimes this is really "I can''t sell." It''s easy to demand goodies, but hard to figure out real needs. Your boss is caught between the team and these shrill calls. Then there''s arbitrary and capricious schedules. "It''s gotta be done by March 1!" How annoying! What reality does this stem from? To us these mandates are insane, driven by no technical basis. Those in charge must be morons! Or maybe not. There may be other realities we don''t understand. In the engineering group I ran in the 70s schedules always came down from on high. This was a chronically undercapitalized company, and I''ll never forget an effort to go public. One auditor, shaking his head in dismay, told me "I''ve seen every financial trick this outfit has used. But never all in one company." Years later the president told me that for 69 consecutive weeks Thursday nights there wasn''t enough money to meet Friday''s payroll. Can you imagine the stress? Product simply had to get out the door. Once I gave my boss a schedule and he said we needed to shave it by a third. I protested; he replied that if we missed his deadline I''d have to let three of my people go. What would you do? I shamefacedly agreed. I don''t remember what happened, other than there was no layoff. Money is the grease of business. Without it the company goes under. My point is that management is often under pressure we don''t see. I believe that in many companies there is, and always will be, an essential disconnect between management and engineering. The boss is being squeezed by forces that have nothing to do with our work. Investors want shareholder equity. The bank wants profits, today. In an ideal world if we could deliver a perfect product with a million lines of code in a month, the competition will soon follow. Management will then want to trim that to two weeks. What''s the answer to this disconnect? I have no idea, but one element is regular open and frank discussions. And mutual respect between all participants. Management is hard, and we need to recognize those trials just as the boss has to acknowledge our real issues. |
||||||
Working Overtime | ||||||
Though we all have a gut-sense that working too many hours is counterproductive, a short paper by John Nevison called Overtime Hours: The Rule of Fifty cites data from four studies conducted over a half century to show how productivity drops as overtime increases. The studies'' results vary quite a bit. One shows that at 50 hours/week workers do about 37 hours work, dropping to just over 30 once the workweek increases to 55. The "best," if you can call it that, results were from a 1997 survey showed wielding the whip can yield increasing productivity, edging up to about 52 useful hours for a 70 hour week. But they all show a nearly impenetrable barrier of around 50 productive hours or less, regardless of time shackled to the desk. Unsurprisingly the data shows a sharp drop in results for those working excessive OT for weeks on end, averaging around a 20% drop after 12 weeks of servitude. That means, as the author concludes, the Rule of Fifty is a best-case estimate. The 2005 Circadian Technologies Shiftware Practices survey showed that productivity can decrease by as much as 25% for a 60 hour workweek, which jibes pretty well with Nevison''s data. Circadian''s results also demonstrate that turnover is nearly three times higher among workers putting in a lot of OT, and absenteeism is twice the national average. I''m not sure what that result means, since it''s awfully hard for an absent worker to be putting in overtime. Fred Brooks claims that the average software engineer devotes about 55% of his week to project work. The rest goes to overhead activities, responding to HR, meetings about the health insurance plan, and supporting other activities. The German government claims that the nominal workweek in Germany is 37.5 hours because "The original reason for introducing this system was to combat rush-hour traffic congestion, but among the more direct gains are an improvement in employee morale, greater productivity, significant decreases in absenteeism, greater flexibility for women who juggle the demands of work, home and children, and the increased sense of individual dignity that the employees get from having a greater say in organizing their own time." The last phrase may be true but seems awfully hard to measure. However, their conclusions about morale, absenteeism and productivity parallel the survey results quoted above. One of ?eXtreme Programming''s practices is to never work two weeks of overtime in a row. This graph, from "Laws of Productivity" shows that short sprints can be effective. After a few weeks the benefits disappear: Here are some more data:
What''s your take? When does overtime become counterproductive? |
||||||
Cortex M4F Trig Performance v. Custom Algorithm | ||||||
But how does the Cortex M4F''s performance compare to writing custom versions of the cos() function? (The sin() function will be almost the same as cos() because sin() is just a 90 degree shift of cosine). The M4F has a speedy single-precision floating point unit (FPU). The M4 FPU has no ability to compute trig functions. The compiler''s math library uses some sort of approximation. There are many approximations that compute trig functions. I chose three from the book Computer Approximations, by John Hart. These have different accuracies; if you can stand less accuracy the trig function will be computed faster. More information about these approximations is here. The approximation code is here. My experimental setup is:
Here are the results: A few observations:
An alternative to cos_32() is a lookup table, given a few hundred entries in the table. That would scream. Only a handful of instructions would be needed, and at these clock rates the CPU is executing instructions in a matter of a few tens of ns or less (depending on wait states, etc.). To ensure cos_72()''s accuracy wouldn''t be degraded by the resolution of a float, I coded it using doubles for all constants and calculations. Changing all of those to floats gave almost an order of magnitude improvement in speed. But how much accuracy was lost? Running that algorithm in Visual Studio against the double-precision cos() from the math library gives this: "Cos_73 single precision error" is the error when all of the variables and constants in the algorithm are floats. "Cos_73 double precision error" reflects errors when everything is declared double. Other than some quantization noise there''s not a lot of difference, which means most of the inaccuracy stems from the algorithm itself. The book I referenced, "Computer Approximations", has many higher-precision options, some of which are implemented in C in the code mentioned earlier. These errors are a combination of the errors implicit in the approximation algorithm, along with the effect of using floats rather than doubles. The worst error was 0.0003%, with an average error of 5.8E-05%. |
||||||
This Week''s Cool Product | ||||||
EMA Design Automation has a new free guide titled "The Hitchiker''s Guide to PCB Design." It''s a 100-page document with a lot of good advice on designing printed-circuit boards. If you''re a Hitchikers fan, well, there are a lot of fun references to Adams'' wonderful series. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||
Jobs! | ||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||
Joke For The Week | ||||||
These jokes are archived here. If it aint broke, fix it till it is broken. |
||||||
About The Embedded Muse | ||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
In Muse 395 I ran a series of pictures of temperature displays showing totally absurd readings. A lot of readers responded, so with this issue I''m introducing a new section entitled "Failure of the Week." This will feature amusing, frustrating, and ridiculous embedded failures. I have a huge collection of these. Many have lessons we should learn, though too many of those are the same lesson: Check your goesintas and goesoutas. Jack''s latest blog is a guest post: Problems In Ramping Up Ventilator Production |
||||
Quotes and Thoughts | ||||
Eric Smith sent this: A Tony Hoare quote that is perhaps more applicable to embedded system programming: "Later, we asked the customers whether they wanted the option to be able turn off the type checking in production. It''s a bit like wearing a life jacket when you are practicing drills, but then taking it off the ship was sinking. The customers decided to not switch off the type checking." |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. |
||||
Freebies and Discounts | ||||
Rod Philips won last month''s micro:bit. Firia Labs is donating one of their CodeBots (a Python-enabled robot with a host of sensors) for this month''s giveaway. Enter via this link. |
||||
µC/OS Goes Open Source | ||||
Most readers probably know of Micrium, the company whose µC/OS RTOS and related products have been very popular in the industry. I''ve known Jean Labrosse, the founder, for decades and have long admired his company. And I''ve long admired the code base, which is incredibly clean. How clean? It is certifiable to numerous standards, including the rigorous avionics DO-178C. Micrium was acquired by Silicon Labs a few years ago, but very recently that company has pretty much abandoned the Micrium product line. µC/OS-II and µC/OS-III and many of the other parts of their stack are now open source. Dozens of processor families are supported. The source code is here. One of Micrium''s marketing strategies was to sell a number of well-written deeply-technical books about the products. I always liked the fact that some are tailored for particular processors, so a reader can immediately run example code on specific platforms. PDFs of these are now free. Support for the product line is now available from Weston Embedded Solutions in the USA and Embedded Office in Germany. Validated Software is one company that provides certification packages for safety-critical applications. In the avionics world that''s DO-178C, and the Micrium products are certifiable to level A, the most stringent. From their website: Ninety percent of the ?C/OS Validation Suite is "pre-existing" and has been used for "previously certified" software. I presume that as long as users don''t monkey with the code this statement will remain valid. And not monkeying with the code is a feature Weston Embedded seems to embrace. From their website: Cesium RTOS [is] a commercially licensed RTOS that is derived from Micrium''s uC/OS products and completely free from modification by open source contributors. An unusual statement in our times when open source has attained religious stature, but if certification to safety-critical standards is important, one doesn''t want every Tom, Dick and Jill changing things. Rolando Ingles of Weston Embedded told me that Cesium is the Micrium RTOS stack. The company will continue to maintain that code and extend it as needed, while maintaining the clean code standards of the predecessor company. Micrium will be honoring support agreements till the end of the year. Customers will come to Weston Embedded or Embedded Office for licenses, support and consulting (e.g., creating new BSPs, ports, device drivers and the like). Interestingly, he says some customers have bought licenses instead of getting the open source code as they feel that approach is cheaper than getting OSS through their legal department. This is a time of great change in the RTOS business. Amazon acquired FreeRTOS. Microsoft bought Express Logic (ThreadX and related components). The products are easier to use than the old days; SEGGER has a demo that can get a novice running their RTOS in under 5 minutes. Do you need an RTOS? Not all projects do. But this is an area where careful up-front design is critical. In the very early 1980s I designed an instrument that had quite a few I/Os, figuring it would be easy enough to handle everything via polling and some interrupts. A combination of requirements growth and my poor planning meant that I eventually had to shoehorn an RTOS into the (now extant) code. That was a nightmare that bloated the schedule... and taught me the importance of good design. I''m often asked how does one know when an RTOS is needed. There''s no generic answer, but if the system needs to run multiple independent activities, it''s time to consider adding one. An example: if a display needs to be updated at some rate, inputs monitored, communications is going on, an OS might be a good choice. Sure, one can handle these activities with a simple interrupt-driven design, but as the complexity grows that can get out of hand. Some engineers avoid OSes because they worry about determinism. We know that under all the wrong conditions, like a perfect storm of interrupts, preemptive multitasking can fail to schedule all of the tasks. And multitasking can create problems with locks and priority inversion. These are legitimate concerns, though there are solutions to many of them. |
||||
Salary/Coronavirus Survey Results | ||||
Last month I did a salary survey and here are the results. First, average income (estimated by respondents including benefits) by region: In the USA here''s salary by years of experience: There wasn''t enough data to create meaningful years of experience vs income for other regions. Worldwide, we''re, on average, 42 years old with 19 years of experience. What''s with the dearth of 45-49 year old engineers? The IEEE has long complained that for unknown reasons EEs leave the field mid-career, and I guess we''re seeing that effect here. Probably those that remain engineers later in life are culled because the just love the field. In fact, on a scale from 0 to 3 (from "hate it" to "love it") the average happiness with our careers is 2.35, about in line with data from previous years'' surveys. 49% of respondents expect a "Strong demand for engineers." 6% expect the demand to diminish and 43% expect the demand to remain unchanged. 54% of consultants report business is about the same as last year; only 14% report it getting better. The rest are seeing business trail off. Consultants'' average rate is $104/hour, but the range is huge: $50 to $330 with a median of $82. What about the effect of the novel coronavirus? (This data is from the first three weeks of April. As this situation is evolving rapidly the numbers may, too). 2% have lost their jobs. Another 2% are not working and not being paid. Only 1% are not working but continue to draw a salary. 13% are still going to the office every day, which leaves a whopping 82% of us working from home. We''re fortunate to have a career that allows such flexibility. Many people left comments. A few of the more interesting ones follows:
Thanks to everyone who participated. |
||||
Failure of the Week | ||||
Ed Criscuolo sent this: A man went to an ATM to withdraw some money, and found a "glitch" changed his balance from $13 to $8.2 million. The story is here. |
||||
This Week''s Cool Product | ||||
I''ve been following Eta Compute for a while. Like some other vendors, their interest is putting a little machine learning capability at the "edge" - in a microcontroller right at the sensors. What makes them a bit different is their focus on doing this at extremely low power levels. Eta''s new ECM3532 is an MCU with a Cortex M3 and DSP with dual MACs. The latter, of course, is optimized for multiply-accumulate operations, which are at the heart of inferencing. The company claims (I''ve seen their eval boards running off 1 cm2 solar cells) power consumption of under 5 µA/MHz, which is around an order of magnitude better than most ultra-low-power MCUs. Instead of dynamic voltage and frequency scaling, they tout continuous voltage and frequency scaling, with a near-threshold low-end Vdd of 0.54 V. Near- and sub-threshold operation yields very low power operation at low frequencies. Ambiq is one of the pioneers in this area. FETs can operate in three regions: subthreshold, linear, and saturated. But in the subthreshold region leakage is a problem, and temperature even more so. Transistors are not well characterized at those voltage levels, so vendors resort to clever, often secret, tricks. I''m told digital watches, at least the non-smart versions, operate in the subthreshold region giving them tremendous battery lives. For more on subthreshold voltage operation of FETs see this. One of those tricks Eta uses is a non-synchronous architecture. Though there is a clock, the logic isn''t conventionally clocked. It''s self-timed. Synchronous circuits need plenty of margin to insure all of the timing is properly closed; self-timed versions report back as soon as an operation has completed so the next can begin. Absent this, since FETs operating in or near the subthreshold region can have wildly-varying characteristics depending on temperature, huge setup and hold margins would have to be designed in. Why would anyone want an inferencing engine at the edge? Potential uses include listening for wake-up words (think "Hey Google"), sensing glass breaking, and even a bit of image recognition. Local processing means less bandwidth to the cloud, and a lot less power consumption as comm protocols can drain batteries quickly. Samples of the ECM3532 are available today. In production volumes they will be under $5. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad. |
||||
Joke For The Week | ||||
These jokes are archived here. And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies. - Linus Torvalds |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||
Contents | ||||||
|
||||||
Editor''s Notes | ||||||
A recent EEWorldonline article states "TIRIAS Research forecasts that 98% of all edge devices will use some form of machine learning/artificial intelligence by 2025." In my opinion, this AIn''t gonna happen anytime soon. A long but fascinating history of the transistor is here. Jack''s latest blog: Networking Did Not Start With the IoT |
||||||
Quotes and Thoughts | ||||||
58% of innovations fail, except for those originated by top management, which fails at a rate of 74%. - The Economist |
||||||
Tools and Tips | ||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Recent Muses have had comments about using state machines. But what about tools? I have heard good things about IAR''s Visual State. Michele Corradin wrote that they are using Yakindu. I had not heard of it but he says they''ve had great success with it and the web site looks interesting. Does anyone have any experience with either of these tools? |
||||||
Freebies and Discounts | ||||||
Firia Labs is donating one of their CodeBots (a Python-enabled robot with a host of sensors) for this month''s giveaway. Enter via this link. |
||||||
Knowledge Capture | ||||||
In Knowledge Capture and Management for Space Flight Systems author John Goodman argues that, particularly in aerospace projects, much vital project knowledge exists only in engineers'' heads. Imperfect memories, career changes and retirement means this information goes missing, often to the detriment of a current program, or a future one that could have drawn on what might have been painfully-acquired experience. Goodman relates that early space efforts took just a few years to complete; Project Mercury ran just over four years from contract award till final flight, Gemini took 5 years. The Shuttle program spanned 38 years, an engineer''s entire career. How many original engineers were associated with that system over the entire program? Just two years after contract award the P-38 fighter had made its first flight, and was introduced to the service two years later. The F-4 flew three years after the contract. But the F-22, despite the contractor having built a flying prototype before winning the competition, required an additional six years for the first flight of the contracted aircraft, and a further eight before the first production model made it to the Air Force. The F-35''s schedule appears unbounded. These are more ambitions projects than the primitive, by today''s standards, P-38 and F-4, so comparisons are not completely fair. But it''s clear that both the complexity of the programs and the engineering duration means preserving design decisions is increasingly important. In the commercial world the problems are little different. I''ve often wondered how the automotive companies preserve corporate knowledge. Ford learned at great expense how to position gas tanks due to the Pinto fiasco, but do young engineers who weren''t even alive at the time know those lessons learned so painfully, so long ago? Middle-aged readers who can''t find their keys understand that even a single person''s memory is pretty unreliable. I figure the brain is a FIFO queue. When it fills, around age 50, something has to go when one learns something new. So how do we preserve knowledge? Traditional tools aren''t up to snuff. Goodman suggests the use of "Brain Books," more or less engineering notebooks used by developers to record design decisions, test results, and the like. He cites a case where a Brain Book saved a project. But hardcopy is tough to search and poor penmanship hinders understanding. I keep a notebook in my woodworking shop to record things I learn that I''ll surely forget. There''s no computer in that room and the volume of data is very low, so that works well. A variety of pretty organized files on my PCs keep resource notes, interesting quotes, facts and the like. But perhaps a wiki is the ultimate Brain Book repository, and reading Goodman''s article has given me motivation to set up a personal Brain Book on a wiki. We''re drowning in information and, unless preserved and categorized, an excess of data is the same as no data. Microsoft Notes is an interesting system for recording ideas. I''ve had pretty good success with it. But not trusting any cloud provider to be around forever I do download the data from time to time as a backup. How do you preserve your design notes and other important bits of information that exist outside of normal tool flow? |
||||||
Efficacy of Bug-Finding Tools | ||||||
I stumbled across a 2005 paper by Stefan WagnerJan J?rjensClaudia KollerPeter Trischberger called Comparing Bug Finding Tools with Reviews and Now, the study was about Java code and the bug-finding tools were open source, not the commercial versions now available. Here are their conclusions: Interestingly, code reviews were much more effective at finding the worst bugs than bug-finding tools. Tests were not as good as reviews, but were far better than the tools for these impactful bugs. The tools shine at detecting the least consequential errors. Tests found none of these. My takeaway: use the tools to cheaply find some errors. Apply reviews, and then tests. Think in terms of a series of filters, as no one approach will give quality code. |
||||||
Hardware, Software or Hardware/Software? | ||||||
When the embedded field was young most developers wore at least two hats, that of firmware and hardware designer. Some also came up with analog, power and maybe even RF circuits. A single engineer might be responsible for most of the electronics in a product. Sometimes the same person would even lay out the PCB and assemble prototypes. That was a lot of fun! But systems were simpler back then. 8 KB of code was a lot, and SMT hadn''t turned board assembly into an art practiced only by the caffeine-deprived. 12 bit A/D converters were expensive, which meant those of us working in the analog domain had, in general, smaller noise issues than today''s systems that measure femtoamps. Low clock rates dodged Maxwell''s Laws and programmable logic was merely a dream. Though a huge number of embedded systems are still small, often containing a bare sliver of silicon embodied in a small PIC or other minimal MCU, big applications are common. Firmware can consume hundreds of thousands or even millions of lines of code. Hardware people design with multi-hundred pin chips running with tiny noise margins, while wrestling with EMI and ESD requirements that were unheard-of decades ago. It''s natural that engineers started to specialize, at first to divide the work into manageable chunks, and later because of the specialized knowledge required to deal with advancing technology and requirements. Today an increasing number of embedded systems developers live in their own domain, with little knowledge of other aspects of the system they''re building. That''s a natural part of the progression of knowledge: as a technology or science advances people''s expertise at their own arcane area grows while their breadth narrows. But it''s interesting how that, in a single generation, we''ve progressed to the point where many firmware developers can''t answer simple questions about their hardware platform. In casual discussions with engineers I''ll often ask about their system''s clock rate, or supply voltage, or any of a number of hardware issues. Quite a few can''t answer; in some cases the software people don''t know what the target processor is. The reverse is often true as well: ask a hardware developer about the firmware''s data structures or which RTOS is used and you might get a blank look. The FPGA whizzes are sometimes clueless about classes and analog gurus can be completely ignorant about PWM control. I''ve worked with groups that use embedded Windows or Linux simply to minimize their need for firmware people, who can be hard to find and a lot more expensive than Visual Studio programmers. These folks may have little idea about the physical instantiation of their product. This natural and necessary specialization has created a new job category, which I call the systems person. The person who does have a deep understanding of all of these interrelated issues, who can sling some VHDL and C while probing a low-noise preamp. Sometimes they''re the computer experts who can tie together the digital hardware and code to interface with the RF crowd to help the entire team solve a challenging multipath problem. These systems people are invaluable and increasingly hard to find. At times I wonder if they are a vanishing breed. But other fields have managed to keep systems folks with armies of specialists. Medical GPs, for instance, look at the whole body. What is your experience? Are systems folks a dying breed? |
||||||
Failure of the Week | ||||||
I took this picture at an airport in Norway. The word "Bug" plastered on the plane didn''t leave a feeling of confidence: |
||||||
This Week''s Cool Product | ||||||
Need a custom PCB? Here''s a site that will quote boards instantly. Change a parameter (say from 2 layer to 4 layer) and the price comes up in under a second. And, small boards are dirt cheap. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||
Jobs! | ||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||
Joke For The Week | ||||||
These jokes are archived here. From Dan Daly, who writes: Seen in Silicon Valley, at a park along a bicycling/hiking trail. There were many casts in the pond, but the most visible, for obvious reasons, were (float). (The jokes section of my website now has 200 computer-related bits of humor.) |
||||||
About The Embedded Muse | ||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
Jack''s latest blog: Does Anyone Remember In-Circuit Emulators? |
||||
Quotes and Thoughts | ||||
When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along. David L. Akin. |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Though I''m hesitant to enter the editor wars, I''ve been using Ultraedit for many, many years and it is my preferred editor on Windows. They''re up to version 27; I''m using 24 as I just can''t think of any additional features I''d need or want. The Ultraedit folks do sell a file compare, but I''m addicted to Beyond Compare from the oddly-named Scooter Software. It''s fast and it shows deltas brilliantly. Bob Paddock wrote:
|
||||
Freebies and Discounts | ||||
July''s giveaway, courtesy of Firia Labs, is one of their Explorer Kits, which includes 2 micro:bit circuit board computers and associated components for experimenting. Enter via this link. |
||||
Microcontroller Basics with PIC | ||||
What, another book about the Microchip PIC? Aren''t there shelves groaning under the weight of these tomes? Well, yes, but Tam Hanna''s new book Microcontroller Basics with PIC is a bit different. It''s aimed at students and embedded wanna-bees rather than practitioners. This is a hands-on book that teaches both hardware and software design in a manner analogous to how practicing engineers work. Many simple projects are introduced and explained. The wise reader will build and test the projects. However, unlike every other hands-on book, there is no specified evaluation or demo board used. He recommends using a PIC16F18877 with a solderless breadboard like this: Then, each of the projects is built simply by plugging in a few parts on the board. This is an excellent approach as demo boards come and go; if gone, so would the value of the book be. (Alas, Tam doesn''t use the word "solderless breadboard" and I''m afraid a novice wouldn''t know how to go about obtaining this item). The book starts with the basics and begins with assembly language (another nit: it doesn''t explain what assembly is or why it''s important). MPLAB is the IDE used, and Tam gives a great overview of installing and using that product. Hardware and software are presented as a unified gestalt, as is proper in the embedded world. Code to toggle a pin is accompanied with oscilloscope screen shots showing the result. Even better, drawings annotated with events show what''s happening when, such as: Assembly instructions are presented with example usage and resulting scope outputs. I''d recommend that a reader have a scope handy to follow along; even a low-bandwidth USB scope would suffice. Sometimes blinking an LED is that "ah-ha" moment that turns people on to embedded systems. I think the real exciting bit from the book is a table-driven sine wave generator and the accompanying scope shot. The second half of the book is about using C. As the author notes, it''s not a C text and assumes the reader has some familiarity with the language. But it does dig into using interrupts and various serial protocols. The book is chatty, perhaps too much so with many references to the author. But it is a great introduction to embedded systems and I recommend it. I''d pair this book with Alex Dean''s Embedded Systems Fundamentals with ARM Cortex-M based Microcontrollers as two works, taken together, which would give a decent foundation to this field. Tam''s will get you going in the 8-bit world; Alex pushes that to 32 bits and more complex subjects. Both are eminently practical and readable. |
||||
Requirements Traceability | ||||
Responding to last issue''s article about Software Elements Out Of Context, Harold Kraus wrote:
|
||||
Failure of the Week | ||||
From Scott Sweeting: |
||||
This Week''s Cool Product | ||||
Not quite a product, but researchers have a way of creating short pulses. How short? On the order of 5 ps. There''s more here. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad. |
||||
Joke For The Week | ||||
These jokes are archived here. From Clive Souter: I''ll never forget the first time I saw a universal remote. I thought, "This changes everything!" |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||||||
Contents | ||||||||||
|
||||||||||
Editor''s Notes | ||||||||||
Dear readers: I truly enjoy and encourage your emails. Please understand that this week (and hopefully only this week) due to a detached retina I will likely be very slow in responding. Keep ''em coming! But please be patient. Jack''s latest blog: Humility |
||||||||||
Quotes and Thoughts | ||||||||||
Software is free! But, correctly placing all the ones and zeros is priceless. Ron Brombach |
||||||||||
Tools and Tips | ||||||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. Fran?ois Baldassari wrote:
|
||||||||||
Freebies and Discounts | ||||||||||
Cy Clarke won the CodeBot in last month''s contest. This month''s giveaway is one of Zeroplus''s new Logic Cube Pro logic analyzers which I reviewed here. This is their top-of-the-line unit with 32 channels, 256 Msa/channel memory, and 2 GHz sample rate. It lists for $3500. Enter via this link. |
||||||||||
What Does Firmware Cost? | ||||||||||
I''ve been collecting this data for some years, and my numbers peg the cost of firmware at $20 to $40 per line of code (LOC). That''s not just coding; this includes the entire life-cycle, from requirements elicitation to final delivery. And that does not include costs like certification when required for avionics or medical devices. It''s pretty astonishing to interview developers and hear about their code production rates. Typically they tell me they can crank 100 to 300 LOC/day. That may be true in the pure coding phase, but is simply not relevant. The real question is: what does it cost to build a product? That includes requirements, design, coding, debug, test, integration, documentation, and release. These are all real costs that must be accounted for. In a 1996 paper by Thomas Drake (Measuring Software Quality: A Case Study, IEEE Computer Nov, 1996) NSA (you know, those folks who are listening to you at this very minute) figures they pay $70/LOC. That''s $116/LOC in today''s deflated greenbacks. The Space Shuttle code cost $1000/LOC. Now, this was the best code ever written, with but a single bug per 400,000 lines of code. VDC''s 2017 Embedded Engineer Survey Results, once you boil down all of their data, suggests the number is about $43/LOC. Toyota has the coveted "most expensive code every written" award. Their engine control code caused the Feds to hit them with a $1.2 billion fine, which works out to over $1200/LOC. Oh, and then you have to add in those pesky actual engineering costs. Rockwell Collins, in a 2009 report ( Certification Cost Estimates for Future Communication Radio Platforms) figures for low-assurance levels (Design Assurance Level D), an experienced engineer produces 65 LOC/day: Now, that''s just for documentation, production and validation - these figures do not include the other aspects of building a product. Still, it''s instructive to play with the numbers. An experienced developer in the USA will cost around $150k to $200k/year (including overhead). At 65 LOC/day that''s $12/LOC, or probably twice that once all of the other, required, engineering activities are included. At 12 LOC/day for great code (DAL-A), figure on five times the price. Though inexperienced developers are a bit cheaper than old salts they are considerably less productive. Here''s some more data from NASA''s Software Manager''s Handbook: Now, the costs cited above assume one is working 40 hours per week on the code. An article in the May/June 2014 issue of Crosstalk claims the average developer is 50% utilized on the project at hand; other sources cite 55%. So the real costs are twice what they''ve cited. I recently blogged about a complaint we constantly hear: Why Does Software Cost So Much? A better question might be: Who would have imagined what a steal software is? Consider Microsoft Excel. I bet that cost billions. But what would it cost if implemented with gears and cams? Trillions? Quadrillions? |
||||||||||
More on State Machines v. RTOSes | ||||||||||
Peter Mueler wrote two interesting articles about state machines and RTOSes:
Luca Matteini also sent some very useful article links:
Stephen Adels adds:
Fran?ois Baldassari wrote:
|
||||||||||
Free Micros - Pretty Much | ||||||||||
"There is no reason anyone would want a computer in their home." Ken Olsen, founder of Digital Equipment Corporation, in 1977 I sure wanted a computer in my home in 1977, though "home" was a sailboat at the time. Though the word "computer" invoked an image of a massive building-sized machine in most peoples'' minds, the little-known technology of embedded systems was emerging. In 1974 an 8 bit processor chip cost about $2k in today''s dollars. A complete, working computer was out of reach for most people. Today, not so much. A desktop or laptop is cheap. And embedded microcontrollers are in some cases so cheap as to be virtually free. Looking at Digi-Key''s website Rochester Electronics (though the datasheet says "Renesas") sells a handful of parts for under a dime, in small quantities. You won''t get much memory, but timers and an ADC are included. If you can spring for two bits ($0.25 - my dad used the term "two bits" a lot, but I wonder if anyone does anymore) more parts from other vendors are available. For a pair of quarters ($0.50) there''s quite a selection of 32-bit MCUs available. In singles. But these are incredibly pricey parts compared the three-cent MCUs from Padauk. Yep, $0.03 for an 8-bit MCU. Apparently these even have hardware instructions to wait and delay a specified number of cycles. Ever build a bit-banging UART? It''s not much fun as you''ve got to pick instructions based on the number of t-states they require. An interrupt or DMA request would corrupt comm. The Padauk''s wait and delay would make this pretty trivial, even more so because they have a tool that will write all of that code for you. C support is minimal, but with just 1KB of ROM and 64 bytes of RAM most of us would stick with assembly. At these prices the parts could compete with a variety of I/O devices. Need a not-blazing-fast USB chip? Save a few bucks using one of Padauk''s parts. Need a UART? The cheapest one listed on Digi-Key''s site is $0.76. You could implement 25 using the Padauk for the same price. There''s an excellent and detailed write-up here. I don''t know where the company''s name came from but padauk is a species of beautiful bright red hardwood that turns disappointingly brown with exposure to light. At $11/board-foot this 12" x 6" x 1" padauk board costs almost 200 times more than a Padauk MCU Who would have thought an MCU would be cheaper than wood? It''s hard to guess where the semiconductor industry will go in a few years. But of one thing I''m sure: In 1977 none of us would have dreamed of a $0.03 computer. |
||||||||||
Failure of the Week | ||||||||||
730488 days is two thousand years! |
||||||||||
This Week''s Cool Product | ||||||||||
Attila Kalinka sent a link to TI''s TPS546D24A is a 2.95-V to 16-V input, 40-A synchronous buck converter. That''s right, 40A, and without external transistors. 40A in a 5 x 7 mm package. And you can parallel four of them to get 160A from a single output. I didn''t find anything in the 175 page (!) datasheet about heat sink requirements, but the FETs are spec''d at 4.5mΩ. There''s a thermal pad on the bottom of the device that must be soldered to the PCB. I count 20 capacitors in this typical application from the datasheet: Note that five pins carry the 40A out of the device. That''s 8A per pin, each of which is pretty tiny on an LQFN. Ten bucks in singles. Half that in quantity. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||||||
Jobs! | ||||||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||||||
Joke For The Week | ||||||||||
These jokes are archived here. From Jon Titus an oldy but goody: Definition of recursion: Recursion (n), see recursion |
||||||||||
About The Embedded Muse | ||||||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||||||
Contents | ||||||||
|
||||||||
Editor''s Notes | ||||||||
Tip for sending me email: My email filters are super aggressive. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me. |
||||||||
Quotes and Thoughts | ||||||||
Any problem in computer science can be solved with another layer of indirection, except of course for the problem of too many indirections. Bjarne Stroustrup |
||||||||
Tools and Tips | ||||||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. In response to the buck50 logic analyzer in the last Muse, Stephen Green sent in a link to a £6.80 version. Also in reference to the buck50 LA, Paul Brower warned there are a lot of fake Blue Pill boards around. As he wrote: "Wouldn''t want to see a reader frustrated and beating their head against an O-scope trying to figure out why it isn''t working as expected. " More info here and here. Gary Maxwell sent this (college professors please note well!):
That is a great thought. Test equipment has historically been too expensive for education and hobbyists. Sure, there are some nice inexpensive USB scopes around, but the buck50 technology could literally be a giveaway. Buy a book on digital logic and an LA is included! And it does include a dual-channel oscilloscope. Jan Ciger has an alternative to regbits, which I mentioned in the last issue:
|
||||||||
Freebies and Discounts | ||||||||
This month''s giveaway is a Pico 2207B 70 MHz USB scope. Enter via this link. |
||||||||
Tidy Benches | ||||||||
In the last issue a reader asked for tips on keeping a lab bench from becoming a mess. Greg Nelson wrote:
Dale Chayes had an interesting story with a picture of his bench. I suspect decluttering guru Marie Kondo would not approve:
Rob Fries has a comment on storing parts:
Mark Peterson wrote:
|
||||||||
A Risky RISC-V Bet... or Our Future? | ||||||||
RISC-V is an open standard instruction set architecture that is gaining a lot of traction. The Wikipedia entry gives a good overview. In the embedded world I see this as an effort to deal with the Arm tax, where licensees pay Arm a small amount for each processor they sell. For us, this means RISC-V parts could be a bit cheaper than Cortex devices. Yet these are generally already so inexpensive that it would seem to be an issue only in very high-volume applications. Given that RISC-V is an open architecture it''s possible to build a customized processor. Add your own instructions or tune others. That could be important in some limited circumstances, though going from an ISA to silicon is not cheap. An FPGA implementation saves foundry costs, though FPGAs will never be a price match for an off-the-shelf MCU. An old argument we hardly ever hear anymore is that the Intel/AMD ISA is a problem since most of the world runs their PCs with these parts, giving a broad attack surface for bad guys. Arm is so ubiquitous that it is an attractive attack target. Diversity is good. The Wikipedia article states that, for the embedded version, "Floating-point instructions should not be supported (the specification forbids it as uneconomical)" which strikes me as rather silly. Cortex M parts are quintessential embedded devices, yet it wasn''t long before FPUs became common as floats are the leitmotiv of instrumentation and many other embedded applications. I don''t see many embedded systems using RISC-V parts, but these are early days and that could change. IAR and SEGGER both have tool chains; IAR sent me a board with this processor which I haven''t had a chance to fiddle with yet. Charles Manning has been thinking about this:
What do you think? |
||||||||
Design Margins | ||||||||
A recent article in Embedded Computing Design titled "Undervolting for Embedded Systems to Improve Energy-Efficiency" does a real disservice to the EE community. It describes successful efforts to run FPGAs at voltages lower than those specified by the vendors. The probable takeaway, especially for younger engineers not yet seared by the slings and arrows of real world experience, is that one can get some goodies (lower power) by neglecting the datasheet. To be fair, the IEEE article from which this is derived does state "The aim of this paper is to experimentally understand the power and reliability trade-off of commercial FPGAs under aggressive low-voltage operations and its impacts on a FPGA based NN accelerator." Running experiments to increase understanding is admirable. But to take that research and promote it as a possible solution to an engineering problem in a trade magazine strikes me as a disservice to the engineering community. When I went to college we learned that there were equations one used to, for instance, bias a transistor. Run the numbers, and then buy a 2.894k resistor and voila! The circuit will work. The professors never addressed other aspects, like you can''t buy that part. Or that the gain of particular transistor''s part number can vary by insane amounts. Nor did they talk about design margins, possibly one of the most important aspects of all engineering. What happens if that 3.0V supply is actually 2.9V? Or that 10K resistor is at the end of its tolerance band? Oh, and do the students even learn that a gold band means 5%? My dad, a mechanical engineer, told me that in the 1950s he was working on the F-11F at Grumman. In a test they could not break the tail section. The Navy was upset as the extra strength meant extra weight. When a tail antenna finally snapped the government acquiesced. The tail had, in this case, too much design margin. Would you want to fly on a plane with too little? One of the FPGAs the authors investigated has a Vcc spec of 1.0 V +/- 0.05. The study ran it successfully at two-thirds of that. Interesting? You bet. A good idea? Not for most designs. In my opinion, a fundamental sin in this field is running a part outside of the rated specifications. Yeah, a gamer might immerse a CPU in liquid helium to run it at crazy clock rates, but do that in a real product and you can expect howls of anger from your (former) customers. As a young engineer a mentor drove me mad questioning all of my design decisions. Why did I specify a 1K pullup? Did I consider the gain-bandwidth product of that op amp when the input frequency is near max? What happens to my PID loop if interrupts happen? But he was right, and his incessant badgering made me a better engineer. A friend recently sent me an interesting circuit from a hacker forum. I guess it worked, more or less. Probably some enthusiastic high school kid came up with it. But it was riddled with flaws. On a bench it probably functioned. Make 10,000 copies deployed in the arctic and at the equator, probably not. Hacking is not engineering, whether we''re talking about software or hardware design. Engineering is about making something that will work reliably. That includes following the datasheet specifications to the letter, and then adding more margin when possible. For you older folks, perhaps one of the best things you can do as a mentor is to be that nag. Politely, of course, but insistently. |
||||||||
Failure of the Week | ||||||||
From Nathan Menhorn: |
||||||||
This Week''s Cool Product | ||||||||
I''m not sure how cool this is, but the big semiconductor vendors are planning to integrate Microsoft''s ridiculously-named Pluton chip into their CPUs. From the article: "Microsoft said that the Pluton chip would be integrated as a secure subsystem inside the SoC, adding another layer of protection on top of the internal defenses designed by Intel, AMD, and Qualcomm. The chip establishes a protected area that is physically secluded from the CPU, acting as a vault in charge of protecting secret keys and other information in the PC." Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||||||
Jobs! | ||||||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|
||||||||
Joke For The Week | ||||||||
These jokes are archived here. In the last issue the joke section had definitions of various tools. J.G. Harston sent in this alternative one for "hammer": a Birmingham screwdriver: |
||||||||
About The Embedded Muse | ||||||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
|
||||
You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email. |
||||
Contents | ||||
|
||||
Editor''s Notes | ||||
Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me. Old-timers might remember Heathkit. Electronic Design recently published an interview with two of the company''s employees that''s pretty interesting. Many of us built these kits, which were unusually-well documented and very complete. Dejan Durdenic sent a link to this page, which has a lot of teardowns of old, old, ICs. Quite fascinating. Included is an attempt to mine bitcoin on an ancient IBM 1401 mainframe. It worked, but "so slowly it would take more than the lifetime of the universe to successfully mine a block". Welcome to 2021! The first commercial microprocessor was introduced in 1971, a half-century ago. To mark this occasion the two January Muses will cover the history of that crucial invention. This is an updated version of a piece I wrote a decade ago. |
||||
Quotes and Thoughts | ||||
"Facts are stubborn things." John Adams, 1770 |
||||
Tools and Tips | ||||
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past. The folks at Memfault publish an often-interesting blog. A recent post Defensive Programming - Friend or Foe? promotes offensive programming and is worth reading. |
||||
Freebies and Discounts | ||||
Given the mention of Heathkit above (and this issue''s history theme), this month''s giveaway is a circa 1949 VTVM from Heathkit. What''s a VTVM? These used to be ubiquitous in labs but are unknown today. It''s a vacuum tube voltmeter. Maybe you have one of those cheap Radio Shack volt-ohmmeters (VOMs). They typically have a terrible input impedance so will load circuits, sometimes giving erroneous readings. A VTVM feeds the input to the grid of a vacuum tube ("valve" to our British friends), giving the meter a very high (on the order of 10 MΩ) impedance. The meter doesn''t work. I took it apart and found the power-supply capacitor is bad; probably the others need replacing, too. Surprisingly, the selenium rectifier works, but I''d replace it with a silicon diode. This would be a fun repair project. A manual with schematics is here. Enter via this link. |
||||
The Story of the Microprocessor - Part 1 | ||||
We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Bill Gates. Fifty years ago, Intel placed an ad in Electronic News introducing the 4004, the first commercial microprocessor. "A micro-programmable computer on a chip!" the headline shouted. None of the engineers I worked with at the time believed the hype. At the time Intel''s best effort had resulted in the 1103 DRAM, which stored just 1k bits of data. The leap to a computer on a chip seemed impossible. And so it turned out, as the 4004 needed a lot of extra components before it could actually do anything. But the 4004 heralded a new day in both computers and electronics. The 4004''s legacy wasn''t that of a single-chip computer, though that came within a few years. Rather, it spawned the age of ubiquitous and cheap computing. Yes, the era of the personal computer came a decade later and entirely as a result of the microprocessor, but the 4004 immediately ushered in the age of embedded systems. In the decade between the micro''s invention and the first IBM PC thousands, perhaps millions, of products hit the market with embedded intelligence. Fifty years ago few people had actually seen a computer; today, no one can see one, to a first approximation, as the devices have become so small. A typical embedded microprocessor today. The history of the micro is really the story of electronics, which is the use of active elements (transistors, tubes, diodes, etc.) to transform signals. And the microprocessor is all about using massive quantities of active elements. But electrical devices - even radios and TV - existed long before electronics. Mother Nature was the original progenitor of electrical systems. Lightning is merely a return path in a circuit composed by clouds and the atmosphere. Some think that bit of natural wiring may have created life on this planet. Miller and Urey created amino acids in 1952 using simulated high-energy discharges. But it took four billion years after Earth formed before Homo sapiens arrived, and then a little longer until Ben Franklin and others in France found, in 1752, that lightning and sparks are the same stuff. Hundreds of years later kids repeat this fundamental experiment when they shuffle across a carpet and zap their unsuspecting friends and parents (the latter are usually holding something expensive and fragile at the time). Other natural circuits include the electrocytes found in electric eels. Somewhat battery-like, they are composed of thousands of individual "cells," each of which produces 0.15 volts. It''s striking how the word "cell" is shared by biology and electronics, unified with particular emphasis in the electrocyte. Alessandro Volta was probably the first to understand that these organic circuits used electricity. Others, notably Luigi Galvani (after whom the galvanic cell is named) mistakenly thought there was some sort of biological fluid involved. Volta produced the first artificial battery, though some scholars think that the Persians may have invented one thousands of years earlier. About the same time others had built Leyden jars, which were early capacitors. A Leyden jar is a glass bottle with foil on the surface and an inner rod. I suspect it wasn''t long before natural philosophers (proto-scientists) learned to charge the jar and zap their kids. Polymath Ben Franklin, before he got busy with forming a new country and all that, wired jars in series and called the result a "battery," from the military term, which is the first use of that word in the electrical arena. Many others contributed to the understanding of the strange effects of electricity. Joseph Henry showed that wire coiled tightly around an iron core greatly improved the electromagnet. That required insulated wire long before Digikey existed, so he reputedly wrapped silk ripped from his long-suffering wife''s wedding dress around the bare copper. This led directly to the invention of the telegraph. Wives weren''t the only ones to suffer in the long quest to understand electricity. In 1746 Jean-Antoine Nollet wired 200 monks in a mile-long circle and zapped them with a battery of Leyden jars. One can only imagine the reaction of the circuit of clerics, but their simultaneous jerking and no doubt not-terribly pious exclamations demonstrated that electricity moved very quickly indeed. It''s hard to pin down the history of the resistor, but Georg Ohm published his findings that we now understand as Ohm''s Law in 1827. So the three basic passive elements - resistor, capacitor and inductor - were understood at least in general form in the early 19th century. Amazingly it wasn''t until 1971 that Leon Chua realized a fourth device, the memresistor, was needed to have a complete set of components, and another four decades elapsed before one was realized. Michael Faraday built the first motors in 1821, but another four decades elapsed before James Maxwell figured out the details of the relationship between electricity and magnetism; 150 years later his formulas still torment electrical engineering students. Faraday''s investigations into induction also resulted in his creation of the dynamo. It''s somehow satisfying that this genius completed the loop, building both power consumers and power producers. None of these inventions and discoveries affected the common person until the commercialization of the telegraph. Many people contributed to that device, but Samuel Morse is the most well-known. He and Alfred Vail also critically developed a coding scheme - Morse Code - that allowed long messages to be transmitted over a single circuit, rather like modern serial data transmission. Today''s Morse code resembles the original version but there are substantial differences. SOS was "... .. ..." instead of today''s "... --- ...". The telegraph may have been the first killer app. Within a decade of its commercialization over 20k miles of telegraph wire had been strung in the US, and the cost to send messages followed a Moore''s Law-like curve. The oceans were great barriers in these pre-radio days, but through truly heroic efforts Cyrus Field and his associates laid the first transatlantic cable in 1857. Consider the problems faced: with neither active elements nor amplifiers a wire 2000 miles long, submerged thousands of feet below the surface, had to faithfully transmit a signal. Two ships set out and met mid-ocean to splice their respective ends together. Sans GPS they relied on celestial sights to find each other. Without radio-supplied time ticks those sights were suspect (four seconds of error in time can introduce a mile of error in the position). William Thomson, later Lord Kelvin, was the technical brains behind the cable. He invented a mirror galvanometer to sense the minuscule signals originating so far away. Thomson was no ivory-tower intellect. He was an engineer who got his hands dirty, sailing on the cable-laying expeditions and innovating solutions to problems as they were encountered. While at a party celebrating the success, Field was notified that the cable had failed. He didn''t spoil the fun with that bit of bad news. It seems a zealous engineer thought if a little voltage was good, 2000 would be better. The cable fried. This was not the first nor the last time an engineer destroyed a perfectly functional piece of equipment in an effort to "improve" it. (Excellent history of the cable: A Thread Across the Ocean by John Steele Gordon). Amazingly, radio existed before electronics. The Titanic''s radio operators sent their SOS with a spark gap transmitter, a very simple design that used arcing contacts to stimulate a resonant circuit. The analogy to a modern AM transmitter isn''t too strained: today, we''d use a transistor switching rapidly to excite an LC network. The Titanic''s LC components resonated as the spark rapidly formed, creating a low-impedance conductive path, and extinguished. The resulting emission is not much different from the EMI caused by lightning. The result was a very ugly wide-bandwidth signal, and the legacy of calling shipboard radio operators "sparks." The next killer app was the telephone, another invention with a complex and checkered history. But wait - there''s a common theme here, or even two. What moved these proto-electronic products from curiosity to wide acceptance was the notion of communications. Today it''s texting and social networking; in the 19th century it was the telegraph and telephone. It seems that as soon as any sort of communications tech was invented, from smoke signals to the Internet, people were immediately as enamored with it as any of today''s cell-phone obsessed teenagers. The other theme is that each of these technologies suffered from signal losses and noise. They all cried out for some new discovery that should amplify, shape and improve the flow of electrons. Happily, in the last couple of decades of the 1800s inventors were scrambling to perfect such a device. They just didn''t know it. From Light Bulbs to ComputersWhere a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and perhaps weigh 1-1/2 tons. Popular Mechanics, 1949 Thomas Edison raced other inventors to develop the first practical electric light bulb, a rather bold undertaking considering there were neither power plants nor electrical wiring to support lighting. In the early 1880s his bulbs glowed, but the glass quickly blackened. Trying to understand the effect, he inserted a third element and found that current flowed in the space between the filament and the electrode. It stopped when he reversed the polarity. Though he was clueless about what was going on - it wasn''t until 1897 that J. J. Thomson discovered the electron - he filed for a patent and set the idea aside. Patent 307,031 was for the first electronic device in the United States. Edison had invented the diode. From Edison''s patent - the first electronic device. Which lay dormant for decades. True, Ambrose Fleming did revive the idea and found applications for it, but no market appeared. In the first decade of the new century Lee de Forest inserted a grid between the anode and cathode, creating what he called an Audion. With this new control element a circuit could amplify, oscillate and switch, the basic operations of electronics. Now engineers could create radios of fantastic sensitivity, send voices over tens of thousands of miles of cable, and switch ones and zeroes in microseconds. The vacuum tube was the first active element, and its invention was the beginning of electronics. Active elements are the core technology of every electronic product. The tube, the transistor, and, I believe, now the microprocessor are the active elements that transformed the world over the last century. Though the tube was a stunning achievement, it was useless in isolation. De Forest did create amplifiers and other circuits using tubes. But the brilliant Edwin Armstrong was probably the most seminal early inventor of electronic circuits. Though many of his patents were challenged and credit was often given to others, Armstrong was the most prolific of the early radio designers. His inventions included both the regenerative and super-regenerative receivers, the superhetrodyne (a truly innovative approach used to this day), and FM. Tragically, never-ending patent disputes drained him. He committed suicide. As radio was yet another communications technology, not unlike text messaging today, demand soared as it always does for these killer apps. Western Union made the VT1, one of the first commercial tubes. In today''s dollars they were a hundred bucks a pop. But war is good for technology; in the four years of World War I Western Electric alone produced a half million tubes for the US Army. By 1918 over a million a year were being made in the US, more than fifty times the pre-conflict numbers, and prices quickly fell. Just as cheaper semiconductors always open new markets, falling tube prices meant radios became practical consumer devices. (Saga of the Vacuum Tube by Gerald Tyne is an overlooked but excellent history). The VT-1 vacuum tube. Start an Internet publication and no one will read it until there''s "content." This is hardly a new concept; radio had little appeal to consumers until there were radio shows. The first regularly-scheduled broadcasts started in 1919. There were few listeners, but with the growth of broadcasters demand soared. RCA sold the earliest consumer superhetrodyne radio in 1924; 148,000 flew off the shelves in the very first year. By the crash in 1929 radios were common fixtures in American households, and were often the center of evening life for the family, rather like TV is today. (Many good books about early radio; I especially like Empire of the Air by Tom Lewis). Nearly until the start of World War II radios were about the most complex pieces of electronics available. An example is RCA''s superb RBC-1 single-conversion receiver which had all of 19 tubes. But tubes wore out, they could break when subjected to a little physical stress, and they ran hot. It was felt that a system with more than a few dozen would be impractically unreliable. In the 1930s it became apparent that conflict was inevitable. Governments drove research into war needs, resulting in what I believe is one of the most important contributions to electronic digital computers, and a natural extension of radio technology: RADAR. The US Army fielded its first RADAR apparatus in 1940. The SCR-268 had 110 tubes... and it worked. At the time tubes had a lifetime of a year or so, so one would fail every few days in each set. ("Set" is perhaps the wrong word for a system that weighed 40,000 Kg and that required 6 operators). Over 3000 SCR-268s were produced. (A very comprehensive history of RADAR is Robert Buderi''s The Invention That Changed the World). The SCR-268 at work. Ironically, Sir Henry Tizard arrived in the US from Brittan with the first useful cavity magnetron the same year the SCR-268 went into production. That tube revolutionized RADAR. By war''s end the 10 cm wavelength SCR-584 was in production (1700 we manufactured) using 400 vacuum tubes. The engineers at MIT''s Rad Lab had shown that large electronic circuits were not only practical, they could be manufactured in quantity and survive combat conditions. (Maybe the best book about this is The Tizard Mission, by Stephen Phelps). Like all major inventions computers had many fathers - and some mothers. Rooms packed with men manually performed calculations in lockstep to produce ballistics tables and the like; these gentlemen were known as "computers." But WWI pushed most of them into uniform, so women were recruited to perform the calculations. (See When Computers Were Human by David Alan Grier for a fascinating history of this). Many mechanical calculators were created by all sorts of inventive people like Babbage and Konrad Zuse to speed the computers'' work. But about the same time the Rad Lab was doing its magnetron magic, what was probably the first electronic digital computer was built. The Atanasoff-Berry computer was fired up in 1942, used about 300 tubes, was not programmable, and though it did function, was quickly discarded. (See The Man Who Invented the Computer, by Jane Smiley, for much more about Atanasoff). Meanwhile the Germans were sinking ships faster than the allies could build replacements, in the single month of June, 1942 sending 800,000 tons to the sea floor. Britain was starving and looked doomed. The allies were intercepting much of the Wehrmacht''s signal traffic, but it was encrypted using a variety of cryptography machines, the Enigma being the most famous. The story of the breaking of these codes is very long and fascinating, and owes much to pre-war work done by Polish mathematicians as well as captured secret material from two U-boats. The British set up a code-breaking operation at Bletchley Park where they built a variety of machines to aid their efforts. An electro-mechanical machine called the Heath Robinson (named after a cartoonist who drew very complex devices meant to accomplish simple tasks, a la Rube Goldberg) helped break the "Tunny" code produced by the German Lorenz ciphering machine. But the Heath Robinson was slow and cranky. Tommy Flowers realized that a fully electronic machine would be both faster and more reliable. He figured the machine would have between 1,000 and 2,000 tubes, and despite the advances being made in large electronic RADAR systems few thought such a massive machine could work. But Flowers realized that a big cause of failures was the thermal shock tubes encountered on power cycles, so planned to leave his machine on all of the time. The result was Colossus, a 1,600 tube behemoth that immediately doubled the code breakers'' speed. It was delivered in January of 1944. Those who were formerly hostile to Flower''s idea were so astonished they ordered four more in March. A month later they were demanding a dozen. Colossus didn''t break the code; instead it compared the encrypted message with another data stream to find likely settings of the encoding machine. It was probably the first programmable electronic computer. Programmable by patch cables and switches, it didn''t bear much resemblance to today''s stored program machines. Unlike the Atanasoff-Berry machine the Colossi were useful, and were essential to the winning of the war. The Bletchley Park Colossus reproduction. Churchill strove to keep the Colossus secret and ordered that all be destroyed into pieces no bigger than a man''s hand, so nearly 30 years slipped by before its story came out. Despite a dearth of drawings, though, a working replica has been constructed and is on display at the National Museum of Computing at Bletchley Park, a site on the "must visit" list for any engineer. A rope barrier isolates visitors from the machine''s internals, but it''s not hard to chat up the staff and get invited to walk inside the machine. That''s right - inside. These old systems were huge. (There are many books about this; two I like are Enigma by Hugh Sebag-Montefiore and Battle of Wits by Stephen Budiaksky). Meanwhile, here in the colonies John Mauchly and J. Presper Eckert were building the ENIAC, a general-purpose monster of a machine containing nearly 18,000 vacuum tubes. It weighed 30 tons, consumed 150 KW of electricity, and had five million hand-soldered joints. ENIAC''s purpose was to compute artillery firing tables, which it accelerated by three orders of magnitude over other contemporary approaches. ENIAC didn''t come on line until the year after the war, but due to the secrecy surrounding Colossus ENIAC long held the title of the first programmable electronic computer. It, too, used patch panels rather than a stored program, though later improvements gave it a ROM-like store. One source complained it could take "as long as three weeks to reprogram and debug a program." Those were the good old days. Despite the vast number of tubes, according to Eckert the machine suffered a failure only once every two days. During construction of the ENIAC Mauchly and Eckert proposed a more advanced machine, the EDVAC. It had a von Neumann architecture (stored program), called that because John von Neumann, a consultant to the Moore school where the ENIAC was built, had written a report about EDVAC summarizing its design, and hadn''t bothered to credit Mauchly or Eckert for the idea. Whether this was deliberate or a mistake (the report was never completed, and may have been circulated without von Neumann''s knowledge) remains unknown, though much bitterness resulted. (In an eerily parallel case the ENIAC was the source of a patent battle. Mauchly and Eckert had filed for a patent for the machine in 1947, but in the late 1960s Honeywell sued over its validity. John Atanasoff testified that Mauchly had appropriated ideas from the Atanasoff-Berry machine. Ultimately the court ruled that the ENIAC patent was invalid. Computer historians still debate the verdict.) Meanwhile British engineers Freddie Williams and Tom Kilburn developed a CRT that could store data. The Williams tube they built was the first random access digital memory device. But how does one test such a product? The answer: build a computer around it. In 1948 the Small Scale Experimental Machine, nicknamed "The Baby," went into operation. It used three Williams tubes, one being the main store (32 words of 32 bits each) and two for registers. Though not meant as a production machine, the Baby was the first stored program electronic digital computer. It is sometimes called the Mark 1 Prototype, as the ideas were quickly folded into the Manchester Mark 1, the first practical stored-program machine. That morphed into the Ferranti Mark 1, which was the first commercial digital computer. I''d argue that the circa 1951 Whirlwind computer was the next critical development. Whirlwind was a parallel machine in a day where most computers operated in bit-serial mode to reduce the number of active elements. Though it originally used Williams tubes, these were slow, so the Whirlwind was converted to use core memory, the first time core was incorporated into a computer. Core dominated the memory industry until large semiconductor devices became available in the 1970s. The Whirlwind computer. Core plane from the Whirlwind computer. Whirlwind''s other important legacy is that it was a real-time machine, and it demonstrated that a computer could handle RADAR data. Whirlwind''s tests convinced the Air Force that computers could be used to track and intercept cold-war enemy bombers. The government, never loathe to start huge projects, contracted with IBM and MIT to build the Semi-Automatic Ground Environment (SAGE), based on the 32 bit AN/FSQ-7 computer. SAGE was the largest computer ever constructed, each installation using over 100,000 vacuum tubes and a half acre of floor space. 26 such systems were built, and unlike so many huge government programs, SAGE was delivered and used until 1983. The irony is that by the time SAGE came on-line in 1963 the Soviets'' new ICBM fleet made the system mostly useless. For billions of years Mother Nature plied her electrical wiles. A couple of thousand years ago the Greeks developed theories about electricity, most of which were wrong. With the Enlightenment natural philosophers generated solid reasoning, backed up by experimental results, that exposed the true nature of electrons and their behavior. In only the last flicker of human existence has that knowledge been translated into the electronics revolution, possibly the defining characteristic of the 20th century. But electronics was about to undergo another fundamental transformation. Stay tuned to the next Muse for the conclusion of this story. |
||||
Failure of the Week | ||||
From Tim Flynn: |
||||
This Week''s Cool Product | ||||
The folks at PragmatIC (a great name!) have a technology to make flexible ICs. Why would anyone want such a thing? Perhaps for electronically labeling vials, like those used for blood draws. The company''s web site is pretty devoid of information, but Max Maxfield has a good column about this. Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors. |
||||
Jobs! | ||||
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad. |
||||
Joke For The Week | ||||
These jokes are archived here. From Charlie Moher: Went to pick up an item I won at auction today. As there are Covid delays everywhere, I always bring along something to read. Today it was O''reilly''s Python Cookbook, which I had on my dash as I approached the gate keeper. Seeing the book he asked if it was any good. Me wearing a mask and he deaf and only able to read lips, hard to do when we are all wearing masks, I gave him my OK hand gesture. He then went on with a fairly long story of the different snake dishes he had eaten in Florida. I listened with interest until he had finished with the "Soupa Serpente" (Snake Soup) he had in Mexico and for him to ask if there were any favorite python recipes in my book. I finally pulled down my mask and mouthed "No, Computers" and mimicked me typing on a keyboard. He replied that he''d search the internet when he got home for recipes and waved me through. |
||||
About The Embedded Muse | ||||
The Embedded Muse is Jack Ganssle''s newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. |
Click here to unsubscribe from the Embedded Muse, or drop Jack an email.
Data Name | Data Type | Options |
---|---|---|
![]() |