student project

Nov 17, 2010 239 Replies

pants

It's complex and messy because of the way processor port bits and analog multiplexers are shared, and because of fundamental interactions in the system being thrashed. We design the hardware first, and while the boards are being made we do the code. So often the hardware isn't optimized for programming.

They would wreck the formatting! And they are explained in detail, both where they ate drfined and here, where they are used. And it's all correct.

John

..

I disagree.

The "art" of connecting pipes rarely changes and is trivially predicted and estimated. The very same processes, parts and supplies are used every day.

Software projects OTOH are one of the worst areas for getting accurate estimates.

There is a reason for that.

Only if they've ingested too much lead...

a risk also for those using a soldering iron for electronics purposes.

Warren

pants

--- Perhaps you misunderstood me or my analogy was bad, but this snippet is more like what I had in mind:

;***** Legal ;This file contains intellectual property which is proprietary to ;Austin Instruments, Inc. and may not be divulged or reproduced in any ;manner without the prior written consent of Austin Instruments, Inc.

;***** Title ;LBJ Library CD Controller ;L2.ASM V1.1, 02 April 1995 ;(C) 1995, Austin Instruments, Inc. ;Austin, TX

;***** History ;V1.0 Initial release ;V1.1 Added bit switching for Cherry pushwheel switches

;***** set up housekeeping ;***** define vectors org $03f8 ;start of interrupt vectors dw rtisr ;there ** is ** a timer isr dw $0200 ;there is no external isr dw $0200 ;there is no sw isr dw start ;reset vector

;***** allocate ram tempa equ $00e0 ;temp acca storage tempx equ $00e1 ;temp accx storage stmin equ $00e2 ;ten minutes switch input register smin equ $00e3 ;minutes switch input register stsec equ $00e4 ;ten seconds switch input register ssec equ $00e5 ;unit seconds switch input register rtmin equ $00e6 ;ten minutes count register rmin equ $00e7 ;minutes count register rtsec equ $00e8 ;ten seconds count register rsec equ $00e9 ;unit seconds count register creg equ $00ea ;comparison register t1s equ $00eb ;1 second timer reg

;***** program starts here org $0200

;***** more housekeeping... ;***** initialize ram start: clr tempa ;clear temp acca clr tempx ;clear temp accx clr rsec ;clear unit seconds count register clr rtsec ;clear ten seconds count register clr rmin ;clear unit minutes count register clr rtmin ;clear ten minutes count register clr creg ;clear comparison register clr t1s ;clear 1 second timer register

;****** set up port b i/o's clr $11 ;turn on port b pull-down resistors clr prtb ;set port b data to zeroes clr ddrb ;make port b all ins

;***** set up port a i/o's lda #$02 ;0000 0010 sta prta ;k1 off, s/l- high, srck low lda #$ff ;1111 1111 sta ddra ;to make port a all outs

;***** set up interrupt regs lda #$10 ;enable RTI, dT = 8.192 ms (4MHz Fosc) sta $08 ;timer status and control reg

;***** finally, here we go!!! ;***** check for motion irdet: brset 0,prtb,dbounce ;check for IR motion detect bra irdet ;and loop until motion occurs

;***** debounce IR detector contacts dbounce: jsr t100 ;wait 100 ms brclr 0,prtb,irdet ;then go back if not still active

;***** hit play once bset 2,prta ;turn the relay on jsr t100 ;100 millisecond delay bclr 2,prta ;turn the relay off

;***** get thumbwheel switch data ;***** gen shift register load pulse bclr 1,prta ;generate sr load pulse bset 1,prta ;end sr load pulse

. . .

--- JF

If you are lucky. Sometimes I need to make some modifications in the Linux kernel. Small pieces are easy to follow despite lack of essential comments. The audio part of the Linux kernel is still a complete mistery to me after spending two weeks trying to figure it out.

I like commented code. I usually write a lot of comments, describe what a function does, what variables are for and what the idea behind complicated math is. I never get questions on how my code works or what it does.

Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------

Yeah, the PBCC version was what I had in mind. Thanks.

John Larkin expounded in news: snipped-for-privacy@4ax.com: ..

That is a loaded discussion because the success of COBOL is at least partly due to the stability of the IBM mainframe.

This is one thing MickeySoft doesn't understand. Businesses don't want to invest millions every year in migrating to the next new platform. IBM OTOH, has made some quiet changes over the decades, but seemingly careful enough not to require business to make major app changes.

I know that where I work, we've gone through number of OS and toolchain upgrades over the years. AFAIK, all of them were "transparent". Compare this to the leased HP Unix servers, where we were forced to recompile and consequently re-test everything. It would be better IMO, to buy the servers and then at least pick your upgrade dates.

MS platforms are horrific in this regard. Thankfully, AFAIk we only have shrink wrapped apps running on those (and none of my involvement).

I wish we had Object Oriented COBOL though. It would fix a couple of evils inherent in the traditional flavour: stack based variables and the potential to use "objects". In regular COBOL every variable is global unless hidden in a CALLed module. Worse, you cannot pass open file descriptors, which would sometimes be useful.

But every tool in the drawer, even the not so sharp ones, have a purpose. Even REXX, dare I say it. ;-)

Warren

Joel Koltner expounded in news:TpzFo.418489$ snipped-for-privacy@en-nntp-15.dc.easynews.com:

All of them are band-aid measures, often not used, and when used, not fully exploited. Usually, they only get used as a last resort.

You can't depend upon policy adherence. If you're going to fly me on software, I need something more reliable than policy compliance. Human nature sets this up for failure.

It _is_ -

It is the difference between working near machinery with a safety guard over the motor pulley and belts and working near machinery where that is left _open_ where hair, hands and clothing can go crunch..

It's a code safety issue. Don't take the ostrich way out "no, it's not my dear C's fault".

But I know... programmers like anarchy, freedom, and ammunition!

Warren

snipped-for-privacy@fonz.dk expounded in news: snipped-for-privacy@v19g2000yqa.googlegroups.com:

..

Yes, that _is_ worse than no comments in my opinion. If you hastely review the code, there's a danger you only ingested the now inaccurate comments.

Agreed - simply hinders comprehension.

We had a summer student do some work for us once. His comments were stupid like:

  • The next line increments J by one.

I hated cleaning up his code. Tell me about what J represents and why we're incrementing. Stupid fart- Did he think we wouldn't understand the statement?

Another bad habit in the mainframe world is the overabundance of asterisks and asterisk & blank lines in JCL or COBOL programs. If I have to make a change, the first thing I do is strip out all the useless ineffective crap.

The other thing I clean up is commented out code. In these days of version control, there is seldom any excuse to leave that in. There are exceptions, but few.

Warren

petrus bitbyter expounded in news:4ce5bb46$0$9499$ snipped-for-privacy@dreader25.news.xs4all.nl:

When you get still older, you might have the time and the money, but you can't see what you're doing, let alone remember where you left your glasses.

"Now, get off of my lawn!!"

Warren

Experienced in that department, are we?

With some programmers, sure...

I guess that's what it really boils down to: Are your programmers serious about quality or not? If not then various tools can still help some, and you could get me to agree that such folks perhaps shouldn't have as "open" of a language as C/C++.

The last place I worked, while it might not have been formal policy, the C++ programmers I knew kept the compiler's warning level setting on the highest available, always compiled to optimized code unless there were actually debugging (as unoptimized code sometimes "just works" even when your code is definitely buggy), and checked the option for "consider compiler warnings as errors."

When we're talking safety-critical code, yeah, I agree. But when it's just the code for a DVD player or TV or similar, with the right people I'd rather take the productivity gain over the *potential* (no guarantee) of a bit less risk.

It's the balancing act of the inconvenience of the guard vs. the additional safety. With things like air compressors, other than a very small cost, there's no inconenience. On the other hand, with metal grinders, many guys routinely remove the guard because they do make things quite inconvenient and the additional safety risk isn't perceived to be that high.

This is true...

---Joel

One of my favorites from a former place of employment was:

int main() // The code starts here

Why, yes, yes it does!

Jamie expounded in news:dfBFo.18581$ snipped-for-privacy@newsfe09.iad:

..

Definitely.

Warren

Joel Koltner expounded in news:9tBFo.448608$ snipped-for-privacy@en-nntp-06.dc.easynews.com:

This is no different that enforcing policy.

..

But I still want my overpriced TV appliance to work. Not like my flippen cable DVR that frequently crashes.

My DVR is one of many modern examples that says that this is ineffective. And we're not talking about hardware failures here.

That level of safety is _FREE_ in Ada. The compiler does that heavy lifting for you. That's what C folks don't seem to get.

Many non-Ada folks are still mired in their "Ada is old school" or "wasn't that the DOD project decades ago?" thinking.

Ada ain't your grandpappy's language any more. Grampy's version was Ada-83.

The current language standard is Ada-2005 with the next revision in 2012. Arguably the biggest improvements came with Ada-95.

And the best news is that the compiler is available for free (GNAT/adagcc). If you don't like free, you can buy it from various vendors.

You can now have the comfort of a truly high level language, without resorting to asm voodo (you can still do some of that in Ada however, if you feel the need). Compilers are much better now and the compile times of even big languages are comfortable. Ada has language support for embedded work.

Hug some Ada.

Warren

Joel Koltner expounded in news:bvBFo.448609$rT.157857@en-nntp-

06.dc1.easynews.com:

ROTFL!

Oh, but C is "self-documenting". ;-)

Don't blame the tools for lazy workmanship. Crappy code can be written in any language.

Some craftsmen could build a chair from scratch using a hammer and chisel; others couldn't get it done right even with use of a full-on wood shop.

Cheers! Rich

Yes, but in my ideal world it's the company culture that keeps quality levels high far moreso than formal policy.

In theory this is where "brand name recognition" comes in -- a Sony DVR should perform far better than a non-name one. In practice, well, so many once-well-known-and-respected brand names are now nothing more than "labels for hire" (e.g., Westinghouse, Polaroid, RCA, etc.).

Many of them don't avail themselves of what the C compilers *do* provide for free. ...thus the idea that it's really more about the people than the language used.

---Joel

Exactly, so that whoever comes after you can decrypt your hieroglyphic code.

Cheers! Rich

The most outstanding example of programming that I recall was a procedure to draw straight line with rounded ends. It drew the line as a sequence of overlapped filled circles.

Not necessarily. The constructors of the static objects are launched before main(). There could be multiple entry points.

VLV

Ah, just how they make drilled slots in PCBs.. G85 code.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required