You may redistribute this newsletter for non-commercial purposes. For commercial use contact firstname.lastname@example.org. To subscribe or unsubscribe go here or drop Jack an email.
On-site Seminars: Have a dozen or more engineers? Bring this seminar to your facility. More info here.
Latest blog: My review of the movie First Man.
|Quotes and Thoughts|
"Testing shows the presence, not the absence of bugs." Edsger Dijkstra
|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.
Chris Hinds sent a link to a paper he and William Hohl wrote about fixed point math. That may be paywalled, though. Another probably-paywalled paper is an excellent analysis of a fixed-point library for 8-bit AVR parts.
Michelle Corradin wrote:
Ian likes SystemC:
|Freebies and Discounts|
This month we're giving away an Owon oscilloscope. See a review later in this issue.
The contest closes at the end of October, 2018.
Enter via this link.
This week's quote ("Testing shows the presence, not the absence of bugs" ) should shape our understanding of writing error-free code. Testing is hugely important. But it simply isn't enough.
If you've been to my seminar you know I'm passionate about this. You can't test quality into the code, or any other sort of product.
Lots of research shows that most test regimes only exercise half the code. Some teams use code coverage, which proves that every line, and in some cases, even every possible condition/decision is tested. Coverage will greatly improve the quality of a product, but generally at considerable cost. Do realize, though, that coverage by itself will not insure the product is working correctly. A tested line of code is not necessarily a correct line of code.
I ran an experiment with LDRA's Unit, which is a product that automatically generates unit tests. Fed a 10 KLOC program, Unit generated 50 KLOC lines of unit tests. And that's just unit tests; system and integration testing would be extra.
How many of us generate 5 lines of test code for every line of shippable firmware? The truth is it's extraordinarily difficult to create a comprehensive test suite.
I like to think about software development as a continuous process where debugging, or better, de-erroring, takes place during coding and even design; where we're using as many "filters" as possible to insure defects don't get delivered.
Capers Jones' and Olivier Bonsignour's book The Economics of Software Quality lists 65 software defect prevention methods. 65. Not all are useful for embedded firmware, and some conflict with others. But the sheer quantity of methods is both mind-boggling and hopeful; hopeful, in that we do have a body of knowledge of ways to drastically reduce errors.
The authors list the efficacy of each. Number one: Reuse using certified sources, which is 85% effective in limiting defects. Number two: formal inspections, which eliminate 60% of all defects before testing even starts. Where do these numbers come from? Not those academic studies where a half-dozen sophomores participate in some experiment which generates a few hundred lines of code. It's from Jones' database of tens of thousands of real projects.
I think that a minimal set of filters for use in firmware development would include:
I'll present my Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here.
Many readers responded to the article in the last Muse about developing embedded systems in the 70s. Luca Matteini wrote:
My first very professional experience with development systems dates back to the 80s. Before of that I have been just a home computer user with some preference for Z80, that I used also at school with the then ubiquitous CPM/80, plus some 8048 evaluation boards in small projects.
By then I started working in the industrial division of a company very active in the military/aerospace, so they had quite enough resources to invest in development.
In our lab we had a couple of very expensive HP64000 development systems, and in that year I spent in a windowless shielded environment with green monitors I lost my better than 20/20 vision!
In the following years I had mixed experiences with more or less advanced development tools. The main company I worked for in the 90s didn't have many resources for embedded designs, we had a good IAR compiler for MC68HC11, so that's it: the preference was to use this only processor.
Without any debugger! So we had to burn EPROMs or windowed MCUs, with some smart debugging monitor, that I added to some serial interfacing, as it was common with evaluation board of the time.
We had a "rich" customer who hired us for some Z180 development, where we could initially employ a "primitive" ICE -- at least for me, that I was used to the slow but efficient HP64000.
When we switched to an MC68000 variant (an MC68302) we had a luxury high-end Lauterbach Trace-32 ICE, with dedicated fiber optic connection.
I still remember the company CEO when we started a second very challenging MC68302 project, he said "We can't wait because the emulator is busy on another board, let's buy a second one!"
I recall that by then each of them costed as much as a luxury German car!
Working with the Trace-32 was wonderful, we had any feature we desired by those times. Again, thanks to the important business of our customer.
After those happier times, I mostly had to battle with small budgets.
For some years I had to develop really with near zero costs, beside some customer that I advised again to turn to IAR compilers, for a few processors -- but still no ICE!
Luckily I found some accessible USB protocol analyzer when standard
v.2.0 was out, as we had to iron out some pesky controllers.
Time has changed a lot. By the end of the 80s I had marvelous Tek storage scopes in the best labs, while with smaller customers it's been tiring convincing to put a storage scope in the budget. Today you can spend much more for a mobile phone than for an acceptably good storage scope.
Even cheaper is getting a basic logic analyzer, compared to the features of the HP and Tek units of the 80s or 90s.
I agree with you on reliability, dependability, and more on the need of tools to ease and accelerate development. It's crucial.
However I had to struggle for so long with tight budgets, great projects and smart ideas born in a technical or financial poverty.
I really think that sometimes I've been heroic just bringing projects to an happy ending, without being a super smart developer. I just did a good work with what were very suboptimal resources. That falsely lead someone into thinking I was "great", while it should have been read "reckless".
I think that many developers know exactly what they would need to make a faster and better work -- even though someone still wants to believe a ten bucks multimeter is "nearly as good" as a two hundreds unit: we know the former gives some numbers, while the latter gives significant digits. And we know the difference between the two.
The main issue is in convincing the very heart of the companies. It's who's deciding for expenses and investments that needs to be educated.
I had a customer that couldn't (or better, won't) understand why a powerful RaspberryPi board costed so much less than their custom designed 8-bit board produced in 100 units every six months... Just go figure how I could justify a good debugger or compiler.
I'm very critical on open source products. Some of them are highly valuable, others look more inflated by their fan than productive. Plus the licensing schemes, in my opinion, risk to give you a false sense of freedom (when they're not as simple as BSD/MIT). Moreover: the freedom to intervene yourself in your code doesn't give you the mastery to do it. I still happily use many open source tools. I just keep the eyes wide open.
Tools developed by professionals, who make a living on that, normally give you much more support when really needed.
I'm fascinated by that 110 GHz scope, to me it would be a dream. Then I am realistic, nobody would buy me one, as much as I won't get a Ferrari or a Bugatti, but hey: I wouldn't even be able to drive any of them. My problem is on a smaller scale, when I'd like to have a few grands scope, and still can't go for it :)
The specs are modest:
- Two channels
- 25 MHz bandwidth
- 5K sample record length
- 100 M samples per second
- Triggers: edge, video, slope, pulse, alternate
Other models are available with better features, up to $425 for four channels and 100 MHz bandwidth.
I don't know much about Owon, but their website lists some interesting instruments, including these USB scopes as well as bench models.
The unit comes nicely packaged in protective foam. Its case is metal with rubber bumpers protecting each end. It weighs nothing but seems reasonably solid.
It comes with two probes, rated 60 MHz, with a switch to select X1 or X10 attenuation. They're cheaply made, hardly surprising for this $106 (from Amazon) scope. I'll have more to say on this class of probes in the next issue of the Muse. Yet I found the probes behaved better than expected.
Documentation is minimal. There's an 18 page quick-start guide that includes no information whatever about using the product. There's some safety info and tips about compensating the probes. That's about it. The supplied CD has a PDF of the same doc, and no other useful guides. But it does have an 11 page manual about installing the USB driver, a tedious process that requires three reboots of the PC. Those instructions will lead a non-expert astray, at least for the version of Windows 10 I'm using, but anyone with lots of Microsoft experience will be able to successfully load the driver. Installation of the application itself isn't covered but is trivial.
There's one catch: the name of the app isn't "Owon" or "scope" or anything meaningful. I had to navigate to the "program files\owon" directory and hunt around for "launcher.exe" which is the program.
Turns out, there's no need for a user manual. I have never used scope software that is so intuitive. I have to credit the designers for an extremely clean, simple layout. Unlike some scopes, the app doesn't want to take over your entire screen; it can be parked in a corner, perhaps leaving plenty of room for other virtual instruments' applications.
To set vertical gain one clicks on the channel 1 or 2 box on the V/div words. A slider opens and allows selection using the usual 1-2-5 sequence. Under that selection, on channel 1, note the "0.84divs" - that sets the vertical offset from the center. A scroll bar appears, but the feature is all but worthless, as there's considerable delay between scrolling and the trace moving to its new spot. However, an alternative is to click on the "1" or "2" to the left of each trace and drag those, which incurs no delay.
The last item in those vertical boxes is the frequency of the signal, which is extremely accurate. That's measured for the triggering channel only.
In the vertical box towards the right side of the screen, selection of the time base is exactly like setting the vertical gain, with options ranging from 5 ns/div to 100 s/div. The "T" is the trigger offset from center, which calls up a scroll bar. That suffers from the same ills as the vertical position control, but grabbing the red arrow at the top of the screen and dragging that is quite responsive.
"D" is the buffer length, and "S" is the sampling rate. These can only be controlled indirectly by setting the time base.
Click on the "Trigger" button and a whole new world pops up:
The vertical bar icons select pretty much all operating modes. For instance, click on the sine wave with arrows and a cursor menu appears. The button below that sets display parameters, like persistence, XY mode (for fun with Lissajous figures), vector/dot mode, and brightness.
FFTs are faster than any other scope I've used, and seem accurate - the sine peak was just where it was supposed to be.
Plenty of measurements are available, and they are updated instantly:
Note that under the waveforms the selected measurements are shown for each channel.
Updates are fast. Really fast. Check out this video which shows a sine wave on channel 1 triggering the scope. Channel two is measuring a signal asynchronous to channel 1, so it just blows all over the screen:
Communications was very reliable; left running all night it never experienced a comm glitch.
Interestingly, the unit supports mask testing, something I hadn't seen in a low-cost USB scope before. I wrote about this in Muse 358.
The scope's -3 dB point was at 33 MHz, better than the advertised 25 MHz, though above 25 MHz the sine wave starts bouncing around a little.
Despite the painful installation, I'm impressed by the scope. The $106 version, at 25 MHz, won't get a pro all fired up, but the feature set, and especially the really nice application, outshine the other USB scopes I've used. For work on MCUs at low frequencies I'd snap up one of these in a heartbeat.
I wasn't sure if this should be in the Joke For the Week section or not, but it's a real thing. Analog Device's LTC7840 regulator has a problem with hiccups. Well, maybe not a problem, but there's a hiccup mode, which apparently protects the device from over-current conditions.
I sure hope no one comes out with a belch-mode device!
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.
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.
Note: These jokes are archived here.
How to debug a "C" program:
1) If at all possible, don't; let someone else do it.
2) Change majors.
3) Insert/remove blank lines at random spots, re-compile, and execute.
4) Throw holy water on the terminal.
5) Dial 911 and scream.
6) There is a rumor that "printf" is useful, but this is probably unfounded.
7) Port everything to CP/M.
8) If it still doesn't work, re-write it in assembler. This won't fix the bug, but it will make sure no one else finds it and makes you look bad.
Advertise in The Embedded Muse! Over 28,000 embedded developers get this twice-monthly publication. For more information email us at email@example.com.
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at firstname.lastname@example.org.
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 email@example.com for more information.