cool article, interesting quote

In article , Marco wrote: [....]

Yes, its like teaching new drivers. We always make them wear seat belts in the classroom. When they get out on the freeway, thry don't need them.

I hope you were tongue-in-cheek when you said that!

Those to. In theory you could account for them piece-by-piece, and only put in checks for ones known to be troublesome. I find it easier to just throw in a library that does universal run-time checking.

And yes, if I'm doing anything even remotely life critical (or even limb critical) I'll treat things with much more care!

In article , John Larkin wrote: [....]

Data types just say how many bytes you play with at once and what meaning you assign to them.

You could write, for example, code that ran on a CDP1802 that emulated the instruction set of a pentium[1]. The 1802 code could be written without any pointers at all. You could run Windows on the emulated pentium and it could still crash due to pointer problems[2]. Even though code that only worked with a large array was actually running, the "pointer problem" program design will still get you.

Ah yes, the Hollywood-favorite slow-motion crash.

John

On Sat, 22 Apr 2006 20:24:22 +0000, Ken Smith wrote: ...

LOL!

Thanks! Rich

Particularly in the control path, I try to keep things simple, uncouple them from other less critical things that may be going on. Keep everything periodic, avoid stack usage that depends on input conditions (!), etc. etc. And I don't modify it without a lot of thought and regression testing.It's no harder to create a few thousand lines of error-free code than a few thousand solder joints (easier, perhaps, because you can test the heck out of the code). But it's easier to get the solder joints right the first time.

Yes, a feel for, and responsiblity for fixing, the consequences of a latent problem are great motivators.

Best regards, Spehro Pefhany

The good news is that there's a dedicated processor for each pin. The bad news is that all 354 of them are low end PICs.

Best regards, Spehro Pefhany

One person, working carefully, can write zero-bug embedded code, in less time than it takes to write and debug sloppy code. I'm not sure if two or more programmers can.

Ice is too hard. Snow is much nicer to fall on.

John

again.

oh-i-don't-know-let's-just-make-it-a-blob-for-now-and-worry-about-details-later

Or knowing how to change a tire, or check their vehicle's oil & other fluid levels.

Amen.

I agree completely. But when programmers >1: - Define interfaces first and foremost. - Be a really in-yer-face manager. Don't assume anything. If you don't like confrontation, you're in the wrong job. - Enforce best practices. If they're won't comply, fry their asses.

Works for me ;).

Steve

When working in assembler and fixed-point, I do the same.

Steve

Bullet time....

Steve

In article , Steve at fivetrees wrote: [...]

I tend to use powers of 10 for the fixed point. Using 0.001 as the LSB, for example means that I just have to stick a dot into the number when printing it. The downside is that the constants you have in the equations are harder to calculate.

BTW: The fastest way to get 1/X on an 8 bit machine with a multiply instruction works on the observation that:

where A = N / (2^-M)

A few applications of this will bring the denom to some thing easy to invert. Then you just have to multiply by the same factors again.

I've had an urge for a long time to build a board with a 12x12 or 16x16 grid of 8 pin PIC or AVR controllers. :)

I just don't know what I would do with it afterwards.

There was an interesting project presented by Steve Ciarcia in Byte over a period of the last half of 1988, I think, for a similar system using 8051s. I think he put Mandelbrot set calculations to work on it.

Jon

When I was in school, I used to fight one of the lab techs (who'd retired from Hughs) for the cast-off T*M gear. He was fun to hang out with; he had a full Rad Lab set.

I have the full RadLab set, but some are the ugly grey reprints. On the other hand, I have some dups of the maroon ones. If anybody else is in the same boat, maybe we could arrange some swaps.

John

One could only hope

Those s/w engg working for Space programe, rarely fails. One of the reason i can cite is they are one of the best (may be not in programming but) ( Pls note i m not tell that other people are not having good skills. but this is compare to normal sw engg to those grads working for those gr8 org such as nasa, airbus, arian, .... so on )

- having havey mathematics

- management skills

- communications skills

- i havent seen ego (most imp) amongest them

- they stay for long hrs.... may be for days in lab with stress still keep there mind focused.

- normally they dont change job as fast as other normal sw engg change

- stick to bottom rules.

.... any one would like to defeat this ?