|
You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. |
| Contents |
|
| Editor's Notes |
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. More info here.
Last month was the 45th anniversary of the first commercially-successful microprocessor. From the Wikipedia article: "In mid-November of the same year [1971], with the prophetic ad "Announcing a new era in integrated electronics", the 4004 was made commercially available to the general market."
And on Nov 20, 1985, Microsoft introduced Windows 1.0. It needed at least, gasp, 256 KB of RAM!
|
| Quotes and Thoughts |
"If the code and the comments disagree, both are probably wrong." - Unknown |
| 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.
Kjeld Petersen found some nice bit twiddling hacks:
|
I have some links about bit twiddling hacks that I also find very interesting.
In particular the 7 low level bit instructions for finding next k bits set number. This can be used for finding all combinations of k bits set in a bit pattern.http://realtimecollisiondetection.net/blog/?p=78.
I must say that the author : Christer Ericson has a very high bit manipulation-fu skill |
Stephen Forrest suggests a converter:
|
I am a simple H/W engineer often working with FPGAs & VHDL. Two's complement fixed point arithmetic sometimes does my head in! Often I want to take a logged value, reported in hex, representing a fixed point binary and turn this into something that makes sense. Most online converters/calculators don't do this properly – either no fractional part or no negatives/two's complement. Adjusting for leading zero's and placing a point are also hardly catered for.
For quick conversions, http://baseconvert.com/ to the rescue! Dan Wolff (http://danwolff.se) has provided an excellent tool for doing all this. It is NOT a calculator - you can't do sums with this - but you can do some great conversions. Try finding -pi in Q2.13 with anything else! |
|
| Freebies and Discounts |
Patrick Mulder and Kelsey Breseman wrote the just-released book Node.js for Embedded Systems (Using Web Technologies to Build Connected Devices. I have not had a chance to read it yet but it looks like a nice introduction to using any of a large number of commercially-available boards and sensors for the Maker scene. The authors generously sent two copies for readers of the Embedded Muse. Enter the contest to be one of two lucky winners of a copy of the book!
Enter via this link. |
| Schiaparelli Crash |
Steve Leibson sent a link to an article about the failure of the ESA's Mars lander. From the article:
|
The European Space Agency on Nov. 23 said its Schiaparelli lander's crash landing on Mars on Oct. 19 followed an unexplained saturation of its inertial measurement unit, which delivered bad data to the lander's computer and forced a premature release of its parachute.
Polluted by the IMU data, the lander's computer apparently thought it had either already landed or was just about to land. The parachute system was released, the braking thrusters were fired only briefly and the on-ground systems were activated.
Instead of being on the ground, Schiaparelli was still 3.7 kilometers above the Mars surface. It crashed, but not before delivering what ESA officials say is a wealth of data on entry into the Mars atmosphere, the functioning and release of the heat shield and the deployment of the parachute — all of which went according to plan.
|
And:
|
In its Nov. 23 statement, ESA said the saturation reading from Schiaparelli's inertial measurement unit lasted only a second, but was enough to play havoc with the navigation system.
"[T]he erroneous information generated an estimated altitude that was negative," ESA said. "That is, below ground level. This in turn successively triggered a premature release of the parachute and the back shell, a brief firing of the braking thrusters and finally activation of the on-ground systems as if Schiaparelli had already landed.
"In reality, the vehicle was still at an altitude of around 3.7 kilometers."
ESA said the sequence of events "has been clearly reproduced in computer simulations of the control system's response to the erroneous information."
|
|
| An Early MMU |
John Hartman recalls an early (very early) MMU:
|
Your article on stack overflows mentioned a desire for an MMU in small embedded micros.
Back in the early 80s, we (Trane) had a 6809-based product that used the Motorola 6829 Memory Management unit. It was pretty simple: it divided the 65536-byte address space into 32 2048-byte pages. You could map each page to an arbitrary 11-bit space, giving 22 bits of physical addressing.
Our hardware engineer used two of the bits to select one of four states for the page
- Read/write
- Read-only (attempt to write caused a non-maskable interrupt)
- I/O
- No access (read or write caused a non-maskable interrupt)
A 2K page was bigger than our stack budget back in those days of assembly, but the protections were wonderful for other reasons: Any attempt to write into EPROM space got trapped as a probable bug. But we also used them to grant read-only access to areas of our "file system", which we could guarantee safe from accidental meddling. And we restricted I/O access to our OS, so bugs in user threads couldn't color on peripherals directly.
Memory access traps went to our debug monitor, which would show the program counter of the offending code. REALLY nice, especially back in the days when our PC developers were working in DOS with NO memory protection.
The chip had four sets of mapping registers. We reserved one for our OS and interrupt handlers, and used the others for application threads. Since we had more than 3 application threads, there was a fair bit of overhead involved in saving and restoring the 32 MMU registers (we gave each thread its own map, since each was likely to have its "read only file window" mapped to a different physical address).
The part had a "fuse" register that you used in code that changed between mapping sets: you set it to the number of cycles taken by your last few OS instructions, usually a store followed by an interrupt return.
We sold the product for years, and eventually did a last time buy of the part when Motorola shut down production.
There is a datasheet at http://bitsavers.trailing-edge.com/pdf/motorola/_dataSheets/6829.pdf |
The datasheet claims the part could dissipate 800 mW. That's about the same power needed by almost 300 of Ambiq's ultra-low power Cortex M4F processors running at full speed! |
| On Stack Usage |
Rod Chapman mentioned a tool that will evaluate stack usage in C and Ada programs:
|
Did you know that AdaCore produce GNATStack - a fully static worst-case stack usage analysis tool. It works with Ada and C rather well. Unfortunately, it doesn't ship as standard in the GPL releases of GNAT, but can be built from the GCC sources. The documentation is at: http://docs.adacore.com/gnatstack-docs/ug/_build/html/index.html |
From the description of the tool:
|
Apart from the computation of worst-case stack requirements, GNATstack can also perform four additional types of analysis:
- Indirect (including dispatching) calls. The tool indicates the number of indirect calls made from any subprogram.
- External calls. The tool displays all subprograms that are reachable from any entry point for which we do not have any stack or call graph information.
- Unbounded frames. The tool displays all subprograms that are reachable from any entry point with unbounded stack requirements. The required stack size depends on the arguments passed to the subprogram.
- Cycles. The tool can detect all cycles in the call graph. These cycles represent potential recursion and hence potentially unbounded stack consumption.
|
|
| 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 |
Note: These jokes are archived at www.ganssle.com/jokes.htm.
Jagmeet Singh Hanspal sent this:
|
A real incident with me while interviewing a candidate...
Interviewer: Can you write a C program that will print a random number?
Candidate: Tell me which one and I'll print it...
*** flabbergasted *** |
|
| Advertise With Us |
Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. . |
| 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.
|
