1. Home
  2. Electronics Design
  3. work, life
  4. Page 6

work, life

What is more distressing is the Blind Faith people put in some of these concepts: "Oh, we'll just use floats/doubles/long doubles/etc." as if this magically absolves them from having to understand how the data types *behave*.

"Gee, how did *that* happen?"

The flipside is also true. If you write *expecting* to port, you tend to think ahead (if you are prudent) to the stuff that *will* go wrong -- and not make those mistakes in the first place!

"Gee, aren't ALL ints (at least) 32 bits??" "What do you mean, *signed* chars???"

Then you find yourself grumbling because it's hard to interface to the hardware or write the scheduler or... Tricks have merit! :>

You would think things like buffer overruns would be the first thing folks would check! I.e., once you start rewiring a light fixture and discover the power is NOT off, you PERMANENTLY learn not to make that mistake again!

Oh, I misread your comment. I thought you were claiming the XP machines more *resistant* to this problem (and the obsolescence of XP meaning we'd be left with *newer* LESS RESISTANT machines)

What's his incentive to perform better? (rhetorical question) You've got everyone running around *believing* that "software (always) has bugs". So, it becomes a self-fulfilling prophesy!

"We don't need to test it -- we'll let the USERS do that!" (modern programming practice)

Do you ever *notice* when you encounter something bug-free? When was the last time your microwave oven turned itself on spontaneously? Or, ran for 3 hours instead of 3 minutes?

That is how it was sold to us (dawn of practical embedded systems) in the 70's! "Just change some code and you've got a new product!" Now, it seems the *hardware* is cheaper to change thna the software (assuming a "software issue" *could* be alleviated with hardware)

Ha! Yes. "Should have been 1.2K.... but, 1.0K *seems* to work!"

Reply to
Don Y
Loading thread data ...

line numbers.

language.

if you

write flat

global.

frequently

state

For a single state machine, this may be true; some state machines have asynchronous inputs as well. You inserted the word synchronous.

If you have multiple interacting state machines they could each have asynchronous inputs as well as their own clock. GPIB certainly has been designed that way.

loop that

in

they

Reply to
josephkk

Seems

float, any

pointers are

What

think it

subscripts,

Again, Ada does have pointers. Read what i sent.

?-/

Reply to
josephkk

Just to pick the nit; there once was a "standard" BASIC. It was the original developed by Kemeny and Kurtz. That was a pretty decent language. The demons are all the lame interpreters written to fit in 8 k on an 8 bit uP (or 16 bit, from Mr. Gates).

I once had to hack one of those 8 bit uP versions to extend it. That was gruesome.

?-/

Reply to
josephkk

Exactly. I wonder how many successful hardware projects would make it to market with the sort of skimpy specifications most

*software* projects are driven by!

"We want a power supply!"

(some time later, *a* power supply is delivered)

"No, the output voltage is all wrong! We (now) know that we want a

712V supply! Can't you just change a resistor value somewhere?" (can't you just change a line of code somewhere? why do you have to rewrite big portions of the implementation? Didn't you ANTICIPATE this?)

(another iteration)

"No, the output current is insufficient! We need 2.5A! Can't you just put in a bigger FUSE??" (yes, doesn't this sound ludicrous? As if the fuse *sets* the capability of the power supply! Yet, the same sorts of ludicrous comments are made regarding software "fixes")

"Oh, but it's too tall! Can't you cut those big 'can-shaped things' down a quarter of an inch?"

"It weighs too much..."

"It's too expensive..."

"It's too yellow..."

"We're late to market -- can't we fix it AFTER its sold??" (unheard of for hardware -- yet *expected* for software!)

It's real easy to tell the boss "we don't yet have the components for the boards" -- and get him to believe you! A lot harder when he sees a piece of code that *sort of* works that you are claiming needs to be *reworked* to do what it needs to do!

"Why didn't you do it RIGHT in the first place?"

I had an office mate who took that approach with a motor driver he was charged with designing. "Poof!" Back to the bench. This went on almost daily! I sat at my desk all this time working with a pencil. Brought *my* design into the lab, waited three days for it to be fabricated. Powered it up and was *done*.

"Smell".

How many people write code with instrumentation in mind? You can add a testpoint pretty near *anywhere* on a PCB -- during the design process or *after*. Not quite as easy when crafting software! Esp if you don't think hard about your interfaces (logical places for "test points")

ROTFLMAO! Or, the schematic capture, PCB layout, BoM, inventory control, payroll, accounting, etc. tools. The software that ensures you get the proper change when you deposit your coins in the vending machine, or that ensures your car's brakes don't "lock up", or that gives you accurate directions from your home to some other place on the globe -- in a handful of seconds!

We remember the bugs but rarely the "bug free"! I can tell you all the devices I've had blown power supplies, "bad caps", fried FETs, etc. But I'll forget to mention all those that *haven't*!

Reply to
Don Y

Utter non-sense. Before i could blink i thought of two things more buggy than software, Legislation and Regulation; with Jurispridence only moderately worse than software. Hmm that is three already.

Just think how bad it would be if they were as bad as legislation.

No, C enforces discipline in a different way, by letting you fail. Think about raising children, they must have the opportunity to fail and pick up the pieces or they never grow up.

--

Without the possibility of failure there is no possibility of success. 

-- someone famous 

?-)
Reply to
josephkk

+42

I make extensive use of pointers -- so much that it scares folks who look at my code! But, don't have any problem with them.

I've also learned how to run with scissors/knife/hatchet in my hands...

Reply to
Don Y

rely

programmers.

That indicts the programmers, not the language. Do keep that straight, please.

?-)

Reply to
josephkk

Ok, just how many software projects are as complex as a modern CPU. How about the common support chips for one? What about FPGAs? Oh gosh, most of these are designed, supported and used with equally complex software. Ok there are more (quantitatively? qualitatively?) hellishly complex software products than hardware products, or are there? How many VHDL / Verilog like products are there? Spice does nearly all of the very complex analog ICs. Why can't accounting get equivalent quality software? Just some things i just thought about.

?-)

Reply to
josephkk

Yes. The process encouraged care.

When I program, I print the source (carefully paged) on fanfold paper, put it in a listing binder, assemble chocolate and water supplies, and go to bed and READ it, and tune it, before I try to run it. Reading finds bugs that testing can't.

I do the same with schematics: print, read, re-check, tweak. Most boards work first time.

Most programmers can't do much math, either.

--

John Larkin                  Highland Technology Inc 
www.highlandtechnology.com   jlarkin at highlandtechnology dot com    

Precision electronic instrumentation 
Picosecond-resolution Digital Delay and Pulse generators 
Custom timing and laser controllers 
Photonics and fiberoptic TTL data links 
VME  analog, thermocouple, LVDT, synchro, tachometer 
Multichannel arbitrary waveform generators
Reply to
John Larkin

Those things have no standards for correctness.

--

John Larkin                  Highland Technology Inc 
www.highlandtechnology.com   jlarkin at highlandtechnology dot com    

Precision electronic instrumentation 
Picosecond-resolution Digital Delay and Pulse generators 
Custom timing and laser controllers 
Photonics and fiberoptic TTL data links 
VME  analog, thermocouple, LVDT, synchro, tachometer 
Multichannel arbitrary waveform generators
Reply to
John Larkin

Typed, bounds-checked subscripts are much safer.

Most code is buggy and insecure. Do keep that fact in mind.

--

John Larkin                  Highland Technology Inc 
www.highlandtechnology.com   jlarkin at highlandtechnology dot com    

Precision electronic instrumentation 
Picosecond-resolution Digital Delay and Pulse generators 
Custom timing and laser controllers 
Photonics and fiberoptic TTL data links 
VME  analog, thermocouple, LVDT, synchro, tachometer 
Multichannel arbitrary waveform generators
Reply to
John Larkin

It may have to do with states. An FPGA is full of smallish state machines that are (usually) synchronously clocked. And the designers plan and understand the states. A program has states, but the number is essentially uncountable and the states are not generally visible or controlled.

The software problem is of course cultural. Anybody can program, there is no real theory, and there is no drive, in academia or most industry, for software quality.

We really need something sort of like LabView for application programming, a graphical, state-driven way to make things happen in a controlled order. Most people aren't very good with procedural languages.

--

John Larkin                  Highland Technology Inc 
www.highlandtechnology.com   jlarkin at highlandtechnology dot com    

Precision electronic instrumentation 
Picosecond-resolution Digital Delay and Pulse generators 
Custom timing and laser controllers 
Photonics and fiberoptic TTL data links 
VME  analog, thermocouple, LVDT, synchro, tachometer 
Multichannel arbitrary waveform generators
Reply to
John Larkin

sounds a bit like Scratch.

"Most people" shouldn't be programming

--
For a good time: install ntp 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply to
Jasen Betts

Too many people do bad thing with guns too.

not all interpreters are well designed, eg PHP is pretty terrible.

Which is only a little younger than BASIC. So what?

--
For a good time: install ntp
Reply to
Jasen Betts

macs were objective C, which is not real C :) also your experience with 68K macs was a lot better than mine.

68K SUN3s on the other hand did'nt reqire me to defensively save my work every 15 minutes. their OS was written in real C. 
--
For a good time: install ntp 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply to
Jasen Betts

Most programmers shouldn't be programming.

--

John Larkin                  Highland Technology Inc 
www.highlandtechnology.com   jlarkin at highlandtechnology dot com    

Precision electronic instrumentation 
Picosecond-resolution Digital Delay and Pulse generators 
Custom timing and laser controllers 
Photonics and fiberoptic TTL data links 
VME  analog, thermocouple, LVDT, synchro, tachometer 
Multichannel arbitrary waveform generators
Reply to
John Larkin

LabView! Augh! AUGHHH!! AAAAAAAUUUUUUUGGGGGGGGHHHHHHH! NOOOOOOOOOOO!!

I feel better now.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net
Reply to
Phil Hobbs

You really are naive if you think hardware is any different.

That sounds *exactly* like my PPoE! The difference is that they get what they got or wait another few months to get something different.

Well, there's the difference. He didn't have his fabricated! ;-)

You've never heard of a debugger? Breakpoints are even easer to install in software. ...and yes, when I did write software, instrumentation was part of it.

We rarely remember "bug free" because we see it so rarely.

Reply to
krw

I would argue that a modern CPU design *IS* a software project. In at least three ways, first, it's all done on a computer (the designers never see real hardware). Second, all the tools are the same as those a software engineer would use. Third, the simulators and verification are a larger tasks than the hardware design itself.

Reply to
krw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.