Perpetual motion controller

Vince: What are your definitions of TRUE and FALSE?

Are your explicit use of TRUE and FALSE in every test and assign a result of TRUE and FALSE having very specific values, possibly completely different from the "normal" true/false of the C compiler? Such that for example hardening the code from having a single bit error of a false/cleared variable giving a 100% conversion to true/set? Something like having

enum {
    FALSE = 0x5a,
    TRUE = 0xa5
};

If that is the case, then I would prefer the last if statement to be changed from:

if( lock_complete != FALSE )
 {
    Enable( BAD_THINGS );
    ...
 }
 else
   ...

to

if( lock_complete == TRUE )
 {
    Enable( BAD_THINGS );
    ...
 }
 else
 ...

to make sure that all bits of the lock_enable variable has the expected state - unless the product had been self-defense and multi-shot like a stun gun in which case it might be preferred to defend one time too much.

"I'm not going to vouch for some 'Biafra Airlines' plane though."

Don't worry. Your guys fathers or grandfathers probably built those planes too. Just that the DC3 passed its best-before date somewhere when the ancients on this forum were still not born.

I'm not going to vouch for some "Biafra Airlines" plane though.

If I interpret the preliminary results of the board of investigation correctly, it was a software failure that killed 9 people in the Turkish Airlines crash in Amsterdam about 3 weeks ago. A faulty radar altimeter made the autopilot (that was landing the plane) think it was much closer to the ground (and to the runway) than it actually was. hence, the throttles were retracted reducing thrust to minimum. The plane stalled before the pilots could correct the situation, fell from an altitude of 500 meters. it was simply a miracle that the wreckage did not catch fire.

This thread has descended into total nonsense!

I wish civilian pilots would be a bit more distrusting.

It's one thing to rely on the autopilot at 30,000 feet, but during a landing it would be a lot better to keep the hands on the controls, while watching the ILS and ground, all the time prepared. There are so many other things the automatic landing systems can't detect - even if they have go-around quick-buttons for automatic automatically aborting a landing.

Having made a mental decision where the power should be reduced, the pilot would not need any extra response time if the automated landing system tries to reduce the power long before the pilots decided point.

But this problem exists everywhere. A lot of car companies have very advanced solutions to predict and automatically break before you run into stopped cars in front of you. But they are very scared of releasing the systems since they know that people will rely on them instead of using them as an extra guard. If professionals relaxes and puts all trust in automatic systems, how can a normal user be assumed to be better?

We already have a generation of people assuming that ABS breaks will guarantee the ability to break with maintained steering. The anti-skid systems of most newer (at least premium) cars will make people assume that they can't loose control of the car as long as they just hold the allowed speed limit.

"This thread has descended into total nonsense!"

Safety issues with embedded systems may actually be more on-topic for this forum than perpetual motion, even if safety issues may not win a Nobel price in physics.

What do you mean, "descended"?

A Perpetual Motion Machine is total nonsense!

en.wikipedia.org/.../Perpetual_motion_machine

Per,

Excellent catch:

to make sure that all bits of the lock_enable variable has the expected state - unless the product had been self-defense and multi-shot like a stun gun in which case it might be preferred to defend one time too much.

It was just an example, and the code review guys might have caught me on that one. The use of the '!=' versus the '==' operator is something I practice and/or is a habit. At least one in which I would like to impart to others.

My defines for TRUE and FALSE are not the simple 0 and 1, or 0 and !0. if it is #defined, it usually contains 'many bits' (like your example of 0x5A/0xA5... or like 0xAAC3/0x553A, but it will also depend upon the processor architecture, instruction-set, etc. It is in a separate 'logic.h' or 'logic.inc' file.

And sometimes it is also #define TRUE (!FALSE) where FALSE = 0. Which I find 'lame.' Most of the time FALSE should be zero though, while TRUE is not simply a simple 1 or all 1 value:

0x0000 - 1 = 0xFFFF
0xFFFF + 1 = 0x0000

So you're only one bit away from a state change. (I'm sure there are many articles about this somewhere in the www).

It is a better construct to use a typedef/enum for flags (Boolean states) like TRUE & FALSE (where it is also assigned a value in the enum, and then actually declare the data-store as that type for your code.

// you pick your favorite name and/or 0 versus !0 thing
typedef enum {FALSE = 0x00, TRUE = !FALSE } boolean_typedef_name;

// not 1 bit away from state change on a 16-bit system
typedef enum {FALSE = 0x0000, TRUE = 0xC3A5 } Flag_Type;

// an 8-bitter: 8051
typedef enum {FALSE = 0x00, TRUE = 0xCA } Flag_Type;

Flag_Type Add_New_Code_Monkey( u8 *name )
{
    Flag_Type hired;

    hired = Check_Name( name, "Per" )

    return( hired );
}

But my point is, that Per is keenly aware of the potential to 'prefer' one state versus the other. Unfortunately, most 'bosses' are unaware of the difference between catching that and the code-monkey who can't. Thus during your performance review, you'll get chided over how many Post-It notes are on your monitor while Curious George in the cube next to you gets the kudos for 'neatness.' [If you're working at a place where the boss is that clueless, leave as soon as you can].

As far as my Biafra Airlines (Biafra == a country that existed from May of 1967 to January of 1970) comment, and the whole thing about flying is that although 'we' know how things can go wrong on very complex systems, when I fly, I don't get freaked out over it.

My wife on the other hand is very nervous when flying. Yet I have more of a reason that her to be nervous as I know more about the plane than she does. (While in flight, various noises that 'freak' passengers out, but they don't bother me at all since I have a clue on what that 'noise' means... and my wife knows that I know: she hates it when I used to say "Oh my! What was that noise?" just to get a rise out of her---I stopped doing that a long time ago).

And yes, the thread name is so very apt for the topic of the pursuit of Safety Related Issues of the non-Nobel Prize winning type.

(Funny how 'Nobel Prize' came up, as a coworker here knows, personally, several people who have received them. But, I'm starting keep my eye on *that* person though; 'cuz I'm just not sure about this one's 'stability' yet: a "Change" type personality).

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I used to think that I was a fairly competent programmer.

However ... after noticing some of the responses on this thread I'm starting to wonder if I've got sufficient experience to even attempt to read them. I won't even pretend to say I can understand what it's all about!

Safety is a critical issue; quality and reliability are also important issues. From a technique perspective, everything does depend on how to qualify an engineer, and the sense of responsibility of the engineer itself. But there is something more than technique, I would say that, the golden age had been gone, and the human society is getting weaker and weaker. When the whole industry, decides to reduce the standard of acceptance, so to increase the production output, or to increase the business profit, there is not much things an individual can do.

It takes me almost more than ten years to learn that, "why so serious?", "people do things this way, so follow it."

For most people who are not very intellectual (like me), it is a career, not the whole life. But sure, good guys bear burdens; this is why good guys are good guys.

Finally and eventually, I become the person whom I dislike.

When I was going through flight training, my instructor and I were looking at the weather, trying to make the go/no-go decision. After a while of me trying to convince him that I should go fly, he turned to me and said "What am I going to tell the accident investigator?" Huh? What investigator?
"If you ball it in in this weather," he said, "they are going to come to me and ask why I let you fly. What am I going to tell them?"

I've tried to carry this idea into my software engineering career. We have all sorts of process, we have to meet the objectives of DO-178B, some days it seems like there's nothing but roadblocks keeping me from getting things done.

Every time I start getting frustrated at the burden of the process, I try to remind myself what my instructor said...If somebody turns a perfectly good airplane into a smoldering hole in the ground, and the NTSB comes to my door and wants to look at my software and my process, what am I going to tell them when they find that I skipped the re-verification after a minor change?

Just my $.02, and how I try to keep the process in perspective.

It takes me almost more than ten years to learn that, "why so serious?", "people do things this way, so follow it."

Any beginner should heed those words "so follow it" *if* the and only if 'it' is a Standard and not the perpetuation of bad practices that *your* company has generated... know them both.

Know What and Why the Standards are the way they are... I stopped reading the standards a long time ago because I thought I knew them well enough---my mistake, I should do that C99 refresher re-read because of my surprise over the [ill-conceived] '\' continuation spec:
http://www.keil.com/forum/docs/thread14467.asp

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

Nathan. Bingo!

That $0.02 of advice will either be picked up and cherished, or left on the ground.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

Unfortunately, the ones most likely to leave it on the ground are usually the ones who need it most...

:-(