We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I have this design for a controller but i dont know the program for it?
Where can I find the code for it? I tried google coding but cannot find it. I normally write Pascal(Delphi) but this needs to be in Keil C for a 8051.
I need to get it working quickly. Who will help?
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.
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.
Unfortunately, the ones most likely to leave it on the ground are usually the ones who need it most...
:-(
I'm glad I helped the community by starting such a productive thread ;)
Andy,
Do sardines have hands? (I've noticed very little fish activity: had he been terminally 'smoked' or not?)
The one place where you might truly get perpetual "motion"...
(or, at least, going around in circles forever)
How nice of you to think of me, Vince. I'm afraid I don't tend to bother reading your longer posts as they have a rather poor ramble-to-content ratio, but I do notice that your fantasy world is coming along nicely.
Keep up the good work!
Ouch, that hurt.
I'll agree the ratio isn't stellar, but I'm nearly complete with my world. I just need to add in some final touches, and I'll be set.
And of course I think of you: I'm sure we all do.
good work? Its "bullet-proof" (at least in my world it is)
How nice of you to think of me, Vince. I'm afraid I don't tend to bother reading your longer posts as they have a rather poor ramble-to-content ratio,
Ho, yeah. Maybe you should - you may learn something (I do).
One big problem with quality and reliability is that the people requesting the product so often don't know what they want, and often don't want to make decisions or spend time finding someone else to take the decisions.
- What should I do if x happens? - Do what you feel is best...
It is so common that the specifications contains the main requirements, but never ever once mentions any error handling. What to do if there is no phone number? No phone line? Phone line but no dial tone? The line is busy? No answer? Call is forwarded multiple times? Number of retry attempts? Delay between attempts? The supply voltage is dropping during the call? There is an error updating an EEPROM with current state? What restart state to use in case of unexpected watchdog reset? What abilities for a service technician to deduce an installation error? Regulatory requirements for permanent logs? ... In the end, even trivial things like having an equipment make a call quickly results in huge lists of "what if".
As a developer, you would like the bulk of the requirements to specify all these expected or unexpected cases. How can it be possible to do tests against a test specification if 95% of the conditionals in the code isn't anchored to any requirement? Getting the customer or project manager to back-patch the specification to ten times the original volume?
One product I worked with was a complete "regeneration" of an older product. The hardware was obsolete, the software written without a real specification, the developer just out-of-school and with hardly any management or other developers to request feedback from. In short, a good case for restarting from zero. I did track all conditional decisions in the sw against a requirements specification - posting additions where specification leaks was found. A couple of months later, I found that I wasn't in the send list for specification updates - it was management only. I got one update. Management got five. And the specifications (that I didn't get) had several times been totally renumbered and without any change history. I should have seen this comming since the time plan (which I got to see about 50% into the project) specified that the test specification should be written in a single week, starting after the development phase was done. By me. I can't see DO-178B accept that the developer ends the delivery cycle by writing the test specification for qualifying his own code. After first having realized that the specification wasn't even valid.
The above was basically caused by a single individual without any experience with software development at a company I worked for. But I expect that most people have seen management problems now and then in both big and small companies. Don't accept them. You will neither be productive nor feel satisfied with your work.
I prefer to have the design rights to figure out the best way to solve a problem, but there is no joy if I don't from the start know what is required to get acceptance on the final product. And throwing away tested and documented code because the requirements specification was written on a whim is no fun.
I think its time to bring an end to this thread.
Most of you have provided useful information.
Well done!
Only Keil staff or time (that perpetual enemy to man) can put a stop to a thread living its own life.
As a spin-off from previous discussions, these photos has got me inspired to take a closer look at some microsecond moments:
www.telegraph.co.uk/.../High-speed-photographs-by-Alan-Sailer-capture-the-moment-a-pellet-fired-from-an-air-rifle-hits-an-object.html