You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/onsite.htm.
We had a number of submissions for the contest for a FRDM-KL25Z development board. The winners, picked using neither scientific methods nor discernable methodology, are Bryan Murdock and Claude Galinsky.
Claude was one of several with solutions for cat-induced tribulations:
|Quotes and Thoughts|
"Science may be the theater, but engineering is the action on the stage." -
|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.
Michael Vowles suggested this Android app:
|Google Protocol Buffers|
Martin Szinger had some first-hand information on Protobufs:
Jon Titus suggested CAN:
Why not try the CAN (Controller Area Network) protocol? Many MCUs include a built-in CAN controller, and CAN libraries make it easy to create code to send data back and forth over long or short distances. As data rates increase, maximum specified bus length decreases. I'm running a CAN bus between an mbed board and a Cypress PSoC-5LP development board. A couple of TI chips provide the interface between the differential CAN bus and the MCU CAN hardware. CAN has built-in error detection, timing-error detection, CRC, device addressing, and a lot more. Worth a look.
Cypress Semiconductor, Microchip Technology, Texas Instruments, NXP and others have MCUs with one or more CAN ports. If someone needs a CAN port but their MCU lacks one, the Microchip MCP2515 stand-alone controller, with SPI interface to a host, would do the job. I'm just getting started with CAN, and it looks good for many applications. Microchip has an inexpensive ($US 99) CAN Bus analysis tool. Other commercial tools--albeit with more sophisticated software--cost thousands.
Luke Peterson wrote:
I saw the note from Jonathan Seidmann in the tools & tips section today. I used NanoPB and Google Protocol buffers for two projects, one was my PhD research (robotic bicycle) and the other was at a company in SF working on an electric 2 wheeled self-balancing vehicle. NanoPB works great on the embedded side and is super simple to get set up. On the desktop/laptop side it is pretty easy to read the files and visualize/analyze with tools in C++/Java/Python. My basic setup for the robot bicycle was that I was logging time series data on an embedded system to a micro sd card and wanted to look at that data later. The other project used GPB to encode data before sending it out on our CAN network.
GPB does add add a bit of overhead (floats take 6 bytes instead of 4), but for many integers it will effectively compress the data. There are also the CPU cycles taken to encode/decode messages. If network bandwidth and/or CPU cycles are at absolute premium, I would look into what is used in the auto industry: DBC files. There are some free editors out there and tools like Matlab have Simulink blocks to read/write these files and they are about as space & time efficient as you can hope for. A free DBC file editor is available from KVaser,[Note from Jack: this is an .exe and I have not checked it for threats] and there are paid versions available from Vector that allow fancier functionality.
A simple example of how I used NanoPB is here.
Richard Donkin had some advice:
Jonathan mentioned the possibility of using Google's Protocol Buffers on embedded devices. While I have not used them myself, I have two cautions regarding using them over the serial port. The Protocol Buffers describe only a data encoding format, but this is not enough by itself when you are using a raw serial port.
Firstly, you will need a framing protocol (i.e. delimiting protocol) at the lowest level to determine where one message ends and the other begins. I have found SLIP to be reliable and quite efficient for this (see http://www.ietf.org/rfc/rfc1055.txt).
Secondly, you will need a mechanism to check for dropped or corrupted bytes; which occur easily if your microcontroller is too late in servicing an interrupt, or if your endpoints' baud rates are not well matched. I typically use a basic 16-bit cyclic redundancy check (CRC16) over the whole packet. If the CRC fails I drop the packet, and it is possible to request it to be re-sent if you cannot tolerate a dropped packet.
Nick P, Security Engineer, responded to last issue's article about one-instruction processors:
There is in fact an architecture with only one or two instructions that can do arbitrary computation: LISP processors . Primitive old LISP's were just little memory cells linked together in tree's with an evaluator that walked the tree performing computation on it. A whole interpreter can be described in a page and a half plus implemented in hardware. The EVAL instruction was called to walk the tree. Also had garbage collector built-into memory hardware subsystem IIRC.
Another interesting design came from research into software vs FPGA's vs ASIC hardware. The No Instruction Set Architecture eliminates instructions and instruction decoding altogether while keeping the parts of the pipeline that do work. You code in an imperative language (C), the application is compiled into low-level form, a datapath appropriate to it is generated, and the result integrated into something you can run on an FPGA. I'd like to see some embedded engineers play with it or combine it with real-time C tech to see how it might benefit them.
This started out as "a quick comment" about the reaction that happened between your report on the mbed IDE and my prejudices. It turned into a rant. At any rate, here it is:
Some of the worst problems that I've had to solve in the embedded space have been involved with trying to reconstruct old code, for the purpose of updating or fixing bugs in an existing software base.
As such, I've gotten very paranoid about making sure that the entire software build process is under my control (or, by extension, my team).
So I tend to view any IDE that wants to hide any detail of the build process with loathing. I want a build process that starts with me checking files out of version control, then has me typing "make" at a command line, and ends -- without further input from me -- at finished software. I want this build process to include no windowed or GUI-based software AT ALL (well, except for the window holding the command line).
I'm happy to use an IDE like Eclipse or Brief (remember that one?) that runs make in a captive command line -- but that's the highest level of integration that I'll accept for serious work.
Why? Because any other process puts me at the mercy of the IDE vendor.
At best, the IDE will remain stable, but I will have a great deal of trouble figuring out which IDE-generated files are "true" source files, which files simply reflect the user's preferences, and which are temporary files that the IDE generates but does not erase when it closes. I'm sure that there are IDEs written to behave this way, but I have yet to get my hands on one that comes with a clear and simple document that explains what to archive and why.
Worse, the IDE will mix essential project-build information in the same configuration file with user preferences. If someone wants blue 'for' statements and pink integer variables that's their choice -- but I don't want to have to archive that choice forever in the version control system, and I _really_ don't want to lose whatever mangled and ill-formed excuse for a makefile the IDE needs to build the code again.
Worst of all is an IDE that "improves" things on updates by changing the formats of files, so that you lose all previous work if you want to use the latest and greatest. I understand that this happens with tool chain changes, too -- but it's a lot easier to archive an old tool chain, and an older all-command-line tool chain is a lot more likely to work on the latest version of your OS than some creaky and ancient GUI-based system.
So you can imagine the degree of welcome I want to extend to an IDE that not only hides the build process from me, but that requires me to use a tool chain that is absolutely, positively, outside of my control, and that may disappear at any time on some corporate whim.
At the bottom line, an IDE may be a nice toy for a baby software engineer to use as they learn to walk. It may even be a serious tool for a team that needs to churn out some consumer-oriented software base in less than a year and never ever use it again. But for serious software that needs to have a productive lifetime measured in years, the typical tightly integrated IDE is just product death in a pretty wrapper.
Nick P, in addition to his comments above, had this to say about IDEs:
The most interesting IDE concept I've discovered is 001 Toolkit. I started reading this extremely fascinating paper  where they independently re-invent much of Comp Sci and eventually developed their "Universal System Language." The big claim is you can use it to model about anything, it semi-automates the design, totally automates code generation, automates most testing, can automate integration, supports legacy, full traceability, and so on. Many big claims setting off my snake oil alarm. Yet, the testimonials are just as big and from diverse people/applications . Main site here .
So, I'm trying to get people with stronger background in abstract thinking, mathematics, and engineering than me to review it to see if USL is the silver bullet it claims to be. If they do, then someone can finally send Fred Brooks the rebuttal many dreamed of and new work in high assurance embedded field can build on USL. If not, the reviewers saved us a lot of time and we can put it on something better. Much thanks for anyone that takes up the challenge.
John Canosa had a warning about mbed's IDE, which I covered in issue 276:
Just thought I would give one important caveat to your readers regarding the mBed tools (which I think are great). If you are in business you need to pay very strict attention to the Terms and Conditions on the site:
* You will be responsible for notifying to us and other users of the terms upon which you are permitting use of material that you have uploaded; such terms will always be subject to our rights to use the Data under the Agreement.
The Data Usage Policy allows using Technical Data which is defined as:
And the Usage of that Technical Data Allows (emphasis mine):
So essentially you are giving away the keys to any of your source code to ARM. That's a show stopper for many businesses that might want to fully develop proprietary applications and trade secrets using those tools.
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 intents of this newsletter. Please keep it to 100 words. There is no charge for job ads.
Note: These jokes are archived at www.ganssle.com/jokes.htm.
Charles Kwiatkowski sent this story:
This actually happened in my PC repair class. In PC Repair, computer fluency is a must, but there is no pre-requisite for the class. So, on the first day of class, we go over the syllabus, and practice logging in. After going to the wrong room, complaining to the dean no-one was there, "Melvin" arrived late. After lecture we headed to the lab to log in and get signed up in Blackboard, our course management system.
Walking students through logging in isn't usually a big deal, except for Melvin who had steam coming out of his ears as he kept trying and failing to log in. To keep the class moving along, I asked the lab assistant, Andy, to help him out.
Andy: What are you using as your username?
Melvin: My K-number. (which is correct)
Andy: What are you using as your password?
Melvin: My student ID (which is correct)
Andy: Are you typing in your password correctly?
Melvin: Yeah... but it keeps putting these darn asterisks in!
Thankfully, Melvin dropped the class after a week.
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at firstname.lastname@example.org.
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at email@example.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 firstname.lastname@example.org for more information.