Last month I covered Susan Cain's GroupThink, where we covered that many of us are more productive when working alone, than in a sea of cubicles or 'open spaces'.
Now Ms. Cain has released her book: Quiet: The Power of Introverts in a World That Can't Stop Talking
Recently I picked up the book Design Patterns for Embedded Systems in C: An Embedded Software Engineering Toolkit
The queue design pattern is the classic first-in/first-out single writer, single reader queue. This 'Design Pattern' has been around for decades. I first used it on a Motorola/Hitachi 6301 in assembly language. Today I use Dave Hylands 'cbuf.h' to implement my queues.
Typically such queses are used where the writer is inside an interrupt routine receiving data from an external process, via something like a UART, Ethernet etc. and the reader is outside of the interrupt. Such a queue allows for the data to be received when presented from an asynchronous source, so it is not lost, rather than processing the data in the interrupt, which would length its run time (always a bad thing). The reader of the queue processes the data when it has the time and resources to do so, outside of the interrupt.
So what is this nasty queue bug? It is the asynchronous usage of the 'size' counter both inside, and outside of the interrupt routine without any type of protection:
#define QUE_SIZE (512U)
uint16_t size_u16;
void que_write( uint8_t const data_u8 )
{
...
++size_u16;
...
}
uint8_t que_read( void )
{
...
--size_u16;
...
}
On parts where 'size' is incremented atomically, say as a 16 or 32 bit indivisible operation there is no problem at all. Our nasty race condition bug will show itself at apparently completely random times on 8-bit machines.
Jack Ganssle went into the gory details of this class of race condition in his article on Asynchronicity (Also take a look at Herb Sutter's multi-part article on Lock-Free Code: A False Sense of Security), so I'll just summarize the problem here. Which is, if the que_write() interrupt happens just as que_read() runs, while the queue size count is 0x00FF, the size will end up wrong. que_read() reads the value of 0x00FF which is interrupted by que_write() that increments the value to 0x0100. que_read() not knowing this happened decrements the 'size' count and saves it as 0x1FE or 0x00FE depending on the implementation. A byte has been lost, or 256 have been gained, in the 'size' count. Things could deteriorate farther when the head/tail full/empty flags no longer end up matching the 'size' count.
Also, properly sizing a queue can be tricky. If it is to small, the queue will overflow and data will be lost. To large and memory space is wasted.
In the case of 'cbuf.h' the size must always be a power of two. As I've covered before I like to use compile time assertions to keep from shooting myself in the foot. I use the following to make sure a non-power-of-two will fail to compile:
#define UART0_RX_BUFFER_SIZE (128U) /* Size of receive buffer [Defined in my project file] */
/* Make sure buffer is sized to be a power of two [In my actual code, in different file]: */
#define UART0_RX_BUFFER_MASK ( UART0_RX_BUFFER_SIZE - 1U )
#if ( UART0_RX_BUFFER_SIZE & UART0_RX_BUFFER_MASK )
#error RX buffer size is not a power of 2
#endif
Something else that really bugs me about the book is that I ordered it in eBook format rather paper format. Elsevier eBook format is some creation of theirs that can not be read outside of their special reader for Windows or the Mac. So if you want to read on Linux, xBSD or a tablet, your just out of luck. Also as an anti-piracy measure if you print out anything, it comes out fuzzy. To make matters even worse I found they charged my credit card $1.19 for a fright charge! A freight charge for an eBook?? You'll be far better off to buy the real paper book, take a band-saw to the binding and scan it yourself that use this eBook carp. Maybe you'll want to join the Elsevier Boycott as well...
One year ago this week, Jan/19/2011, the board house Philway burned to the ground. Philway was the oldest continually operating board house in the US. It was also my preferred PCB vendor, sharp people and good quality for the rugged environments I deal with.
At the time Philway burned down, they were not sure if they were going to rebuild. Over the last year I'd kept in touch with Doug Clark at Philway. Seemed the biggest hold up was that their insurance company, which he never named, would not let them back on the grounds for almost four months! So its time for all of us to go check with our insurance agents what kind of treatment we'd get in a similar situation.
As time passed, Doug stopped answer emails, then stopped answering the phone, and in the end the phone was disconnected.
Last week my curiosity drove me to contact Evan S. at the Ashland Area Council for Economic Development, to see what happened. Seems the owner of Philway now lives in Akron and did not want to rebuild in Ashland, despite generous tax rebates etc. and did not want to commute to Ashland anymore. The owner also indicated that they could not find "good managers" in Ashland. I took that more to mean people with good technical management backgrounds from the context of our conversation. A new board house may arise like a Phoenix in Akron someday, but it won't be the same Philway without the same institutional knowledge that made it a great place to do business with.
The lesson here for all of us, is disasters do happen to good places and good people at any time. Do you have a workable recovery plan in place in case one hits you and yours? Will your insurance company help you out, or help you go under faster?
To be clear I'm not talking about developing a game, I'm talking about development being the game. This week Microsoft released their Visual Studio Achievements plug-in. The plug in 'scores' a number of things such as the number of curse words in a file, and goes down hill from there.
I do not believe that competition belongs in the development process, it should remain in the arena of sports (Being the classic Nerd, I don't think there should be sports, but that is a topic for an other time...). In my view any manager that promotes composition between teams or people, is doing a disservice to everyone from the people competing to the shareholders. How is it a good use of energy and resources?
I find this concept so abhorrent to the development of quality bug free systems, delivered on time, that I don't even know what to say about it. What are your thoughts? Here are a couple of mine:
If you score bug fixes, does someone that fixes ten simple bugs (why are they there at all if they are simple? Put deliberately so they could be 'found' to raise their score??), do they get a higher score than some one that fixed the single bug that has been there since the beginning of time that no one else could find?
What do you put down on your Time-Card for the time you spent "playing" development?
Is "Reached Level 256 in Visual Studio Achievements" really going to be a good thing on a resume?
In a different, but related mater, what I'd like to know is when did IDEs switched from being tools to improve productivity, to crutches that people do not how to program without using? For example you ask someone what "compiler are you using?" and they reply Code::Blocks.
The best 10xers in productivity are going to develop their own tools, frequently, and not be part of the herd worrying about out scoring anyone in a commodity IDE.
Most of these problems come down to our broken concept of education, and that many places already consider developers and engineers nothing but replaceable bags of meat. Companies try to get their proprietary development environments inflicted on the young and impressionable, with a bit of interest to learn, to capitalize on the Baby Duck Syndrome (You'll like environments that are similar to your first, and dislike others).
To much time is spent teaching the tools and language of the day, rather than teaching concepts and how to learn. Someone with a good understanding of the fundamentals can pickup any language quickly, from 'BF' (this is a family friendly blog), the hardest language I every toyed with, to Zonnon, in the list for 428 computer languages.
I don't know what the full solution to creating better embedded systems might be, however I'm sure it is not making it in to a game with scores...
Back in August of 2011 I covered The current Temporal War on planet Earth. Which documented the factions that wanted to keep Leap Seconds as used today, and those that wanted to abolish Leap Seconds.
In our current methodology of keeping time, an extra second is inserted or removed in the Clock-On-The-Wall-Time to keep it in sync with the Look-Out-The-Window-At-The-Sun-Dial-Time (the distinction between Synodic, Solar, Sidereal, Stardates, UTC, UT1 and the myriad of other time scales would make for a much longer blog entry). Those against Leap Seconds say they are to hard to deal with over long spans of time where accuracy and precision are required. The people on the other side of the temporal war want to look out the window and have the clock-on-the-wall agree with what they see out the window. You see that if Leap Seconds are removed the two time scales drift apart. Someday High-Noon Wall-Clock-Time, would be the middle of the night Sun-Dial-Time.
This week the body that governs the time scales was set to vote on keeping or eliminating Leap Seconds. Seems there is no agreement on how to 'fix' the Leap Second 'problem' so the vote has been moved to 2015:
ITU Radiocommunication Assembly defers decision to eliminate the leap second Geneva, 19 January 2012 – The ITU Radiocommunication Assembly has reached an important decision to defer the development of a continuous time standard in order to address the concerns of countries that use the current system of the leap second in Coordinated Universal Time (UTC).
The decision has been reached to ensure that all the technical options have been fully addressed in further studies related to the issue. These studies will involve further discussions within the ITU membership and with other organizations that have an interest in this matter and will be referred to the next Radiocommunication Assembly and World Radiocommunication Conference scheduled for 2015.
Adjustments made in one second steps, known as ‘leap seconds’, have been implemented since 1972 to compensate for variations in the speed of the earth’s rotation within the framework of Coordinated Universal Time (UTC).
UTC is defined by ITU’s Radiocommunication Sector and is maintained by the International Bureau of Weights and Measures (BIPM) in cooperation with the International Earth Rotation and Reference Systems Service (IERS). Measurements from timing centres around the world are used in the determination of UTC, which is adjusted to within 0.9 seconds of Earth rotation time (UT1) by IERS-determined values of the Earth’s rotation.
The suppression of the leap second would make continuous time scale available for all the modern electronic navigation and computerized systems to operate with and eliminate the need for specialized ad hoc time systems. This however may have social and legal consequences when the accumulated difference between UT1 – Earth rotation time – would reach a perceivable level (2 to 3 minutes in 2100 and about 30 minutes in 2700).
ITU Secretary-General Hamadoun Touré considered the decision taken by the Radiocommunication Assembly will ensure that all stakeholders have been adequately associated with a step which will clearly influence our future.
So we tick on with the Status Quo in our Embedded Systems...
Susan Cain has written an interesting piece for the New York Times: The Rise of the New Groupthink. That backs up what many of us know instinctively, we are more creative when we work alone, and not forced into Anti-Productivity-Pods, better know as Cubicle Farms or Open Work Spaces.
Ms. Cain's article updates, and reinforces, what we have known since DeMarco and Lister published their book Peopleware: Productive Projects and Teams (Second Edition)
Solitude does not necessary mean you are you are working alone all of the time. We've all been stuck staring at a problem for longer than we should, not seeing the obvious. We ask a colleague to take a look over our shoulder, when it is of no interruption to them, and they immediately say "Why did you do *that*?". Each person has their strengths and it is important to capitalize on them, then leave them alone to get the job done.
John Fischer wrote an interesting article "Two Years Gone, Two Million More Accidents...When Will We Realize Cell Phones Need Safety Valves?" over at the Injury Board. Mr. Fischer explains why bans don't work, due to a Cell Phone causing a neuro-chemical addiction in the brain [1]. The above article then leads us to his own site Try Safety First, where we find a more data on how bans don't work, well worth your time to read, then purposes a solution.
The purposed solution is to standardize a protocol that disables the cell phone when it receives a transmission from a local low power transmitter. Such transmitters are placed in class rooms, prisons, automobiles etc. The publicly available "White Paper" marked "CONFIDENTIAL", seems rather odd to me, describes the bases of the system. No link here, because after all the paper is marked "CONFIDENTIAL"...
Personally, what seems disingenuous to me is that the "White Paper" wants to charge a dollar per Cell Phone per month for this "safety" function. Not clear where this money actually goes, tho the web site does have a section seeking "investors". They also claim to have filled 17 patents on this technology. My altruistic view of the world would not lock up safety functions behind patents and fees.
I'm sure you have been in places where you wish Cell Phones were not allowed, just as I have. Alas Cell Phone Jammers are illegal. The above proposed protocol does mention security being important to prevent the technology from being circumvented. What I didn't see was anything that said there was something that prevented the local transmitter from being overridden, other than laws, so the Cell Phone would not be able to receive the lockout protocol message...
[1] What I find interesting was the drawing Ben Tannenbaum, The Value of Mobile Phones and the Uberconnected Individual had on his site. We've now come exactly to the point predicted by futurist Alvin Toffler in his 1970 book Future Shock
I've covered various distractions before:
Posts
All Comments
The prevailing attitude that "Memory is Cheap" doesn't cut it in the world of Embedded Systems. I get code to fit into parts (others have picked), that are too small. I translate code between different micros and compilers. Besides the software aspects of things I also do micro design, analog design, power supply design, and board layout.
During the heyday of the Dot Com boom I was the lead author of Circuit
Cellar Online's Resource Links. Steve Ciarcia said I set the standard by which
other link sites were judged, at that time.
I was also a paid member of the Circuit Cellar AskUs staff.
From the final "Connect Time" in Circuit Cellar Issue #80, March 1997:
"I do want to thank a few individuals who have contributed above and
beyond the call over the last 10 years (and, I'm hopeful, for years to
come). Specifically, **Bob Paddock**, Pellervo Kaskinen, George Novacek,
Jim Meyer, and Ed Nisley. I could always count on one of these sharp
guys to have an intelligent, well-thought-out answer to some of the most
off-the-wall questions I've ever seen." - Ken Davidson former SYSOP/Editor-In-Chief Circuit Cellar
Magazine
