Government releases Phase-I Anti-Distraction Guidelines. What will Phase-II do to your Embedded Design?

Do Not Text & Drive Public Service Ad Campaign by, regional Emmy award wining, Punch Films:

Mom:

Teen:

Guy:

Clearly as the above videos show texting while driving kills. I was almost in a head on collision myself when a texting teen was drifting into my lane of traffic. I've covered distracted Drivers, Doctors and Pilots in the past.

This week I'm covering U.S. Transportation Secretary Ray LaHood announcement, on Thursday [February 16, 2012], that the U.S. Department of Transportation (DOT) and the National Highway Traffic Safety Administration (NHTSA) announced their Proposes 'Distraction' Guidelines for Automakers. The official, unoffical, PDF document: Anti-Distraction Guidelines (It is not official until it is published in the Federal Register).

The Phase-I guidelines give members of the public the opportunity to comment on the proposal for 60 days, from the date of publication in the Federal Register. Final guidelines will be issued after the agency reviews and analyzes and responds to public input. If you are concerned about how these rules will impact your Embedded Widget design, now is the time to speak up. You may submit comments by referencing docket number NHTSA-2010-0053 at the Federal eRulemaking Portal.

NHTSA will also hold public hearings on the proposed guidelines to solicit public comment. The hearings will take place in March and will be held in Los Angeles, Chicago, and Washington D.C.

The proposed Phase-I distraction guidelines include recommendations to:

• Reduce complexity and task length required by the device;
• Limit device operation to one hand only (leaving the other hand to remain on the steering wheel to control the vehicle);
• Limit individual off-road glances required for device operation to no more than two seconds in duration;
• Limit unnecessary visual information in the driver's field of view;
• Limit the amount of manual inputs required for device operation.

The proposed guidelines would also recommend the disabling of the following operations by in-vehicle electronic devices while driving, unless the devices are intended for use by passengers and cannot reasonably be accessed or seen by the driver, or unless the vehicle is stopped and the transmission shift lever is in park.

• Visual-manual text messaging;
• Visual-manual Internet browsing;
• Visual-manual social media browsing;
• Visual-manual navigation system destination entry by address;
• Visual-manual 10-digit phone dialing;
• Displaying to the driver more than 30 characters of text unrelated to the driving task.

NHTSA is also considering future, Phase-II proposed guidelines that might address devices or systems that are not built into the vehicle but are brought into the vehicle and used while driving, including aftermarket and portable personal electronic devices such as navigation systems, smart phones, electronic tablets and pads, and other mobile communications devices. A third set of proposed guidelines (Phase-III) may address voice-activated controls to further minimize distraction in factory-installed, aftermarket, and portable devices.

The problem with any 'Guideline' is that if you don't follow it, when the Lawyers show up, if they ask "Did you follow the industries best practice guidelines?" and you say 'No', you lose. So it saves 'Them' all of the hassle writing the laws. Clearly Phase-II will impact our Embedded System designs.

Is regulating behavior with technology really the slippery slope that we want to start down?

Quite, Please: The Power of Introverts in a World That Can't Stop Talking

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, on how today's workplaces are designed for extroverts with open plan cubical farms, at the expense of the creative introverts. Rarely are the loudest ideas, the best ideas. Take the Are You an Introvert or an Extrovert? quiz and listen to her interview at NPR. I'll give a full review after I've finished reading the book...

Even "Design Patterns" still have bugs. A common Queue bug.

Recently I picked up the book Design Patterns for Embedded Systems in C: An Embedded Software Engineering Toolkit by Bruce Powel Douglass. I thought I might pick up some new techniques by reading this book. Always looking for that non-existent magic bullet for creating bug free code all of the time. Alas I was disappointed at the very first Design Pattern, the Queue. The queue design pattern as implemented in the book has a significant bug. The second queue design pattern, will show the bug even faster.

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...