Useless Projects Vs. Useful Projects

[James_Parsons]

This may be me, but i think build a project (with an MPU) that flashes LED's is pretty useless. My reason for believing so is that this can be accomplished with a 555 timer, or some chip from radio shack. You really don't learn much assembly.

[Dr Jefyll]

Having learned how to use a 555, a person is then in a position to use it as part of a larger, more ambitious project.

The same applies to the simple assembly-language loop. In both cases we're dealing with building blocks -- elements that, once mastered, can then be used as part of a greater whole.

-- Jeff

[ttlworks]

When migrating to a new and different microcontroller,
and you are not absolutely sure about how to set
all those fuse/configuration Bits,
a simple application like a blinking LED
probably is the best way for getting started.

Because then you know, how to configurate
and to initialize that microcontroller
for running more complicated code later.


When debugging more complicated code on microcontrollers,
blinking LEDs could turn out to be very useful...
for getting a clue about when and where your code crashed,
for instance.
http://wilsonminesco.com/6502primer/debug.html

[BigDumbDinosaur]

James_Parsons wrote:

This may be me, but i think build a project (with an MPU) that flashes LED's is pretty useless. My reason for believing so is that this can be accomplished with a 555 timer, or some chip from radio shack. You really don't learn much assembly.

A project is useless only if:

1. It doesn't do anything, AND...
2. You can't learn anything from building it, AND...
3. Your mind is closed to learning the basics.

Even something as lowly as getting an MPU to blink some LEDs or make squawks come from a piezoelectric transducer can be useful. If nothing else, you learn how to assemble circuitry and figure it out when the LEDs don't blink, the transducer doesn't squawk or fragrant smoke wafts forth when power is applied. As Jeff said, the basics become the bricks and mortar from which you can build your computer house. Everyone of us started at the flashing LED/squawking transducer level and progressed at varying rates from that point.

At the risk of severely mixing up metaphors, perhaps using an MPU to flash LEDs or make irritating noises would be like the Navy sending out a battleship to sink a rowboat. Despite the seemingly uselessness of the mission, not to mention the gross overkill, the sailors still get some training and practice in how to handle the ship, aim the guns and hit a moving target.

[MichaelM]

I agree with BDD and Dr Jefyll.

It's funny how many times I revert to flashing LEDs on a card when trying to bring up a complex design. After 30+ years in electronics I kick myself every time that I forget put an LED for power status and at least one for blinking by SW/HW.

[nyef]

I'll just chime in with an agreement as well. A blinking LED is the "Hello, World!" program of the hardware world. If I didn't have a logic analyzer, I'd be hooking up an LED to address pins and writing a test program to control its blink rate, because that tells me that at least my CPU and ROM are on speaking terms. A couple more LEDs (or some careful programming) and I could send a short message (no more than 8 bits, really), which would be useful for diagnosing any problems setting up RAM or a UART, and so it goes.

Of course, a 6502 plus ROM plus RAM plus a UART isn't really that useful until you add more I/O, but don't knock the humble LED... And don't forget to put one each on the UART RxD and TxD pins (had to simulate this for a USB modem, which didn't have real RxD or TxD lines, once).

[GARTHWILSON]

As I said in the debugging page of the 6502 primer, I'm not really fond of LEDs as the initial debug tool, because an LED's on/off behavior can be a random result of a crash or accidentally writing to the wrong port at some unknown place in the code. OTOH, a beep produced by software tends to be a better indicator because the software is controlling the frequency and duration to be something recognizable that you intended, to indicate arrival at different parts of a program. It assures you that for the duration of the beep, the processor is in the beep routine, and you know where you called it in your code.

That said, I do use LEDs sometimes, particularly if a beep would slow things down too much, as I do a lot of realtime work; but in that case I put an oscilloscope probe on it, almost nullifying the use of the LED itself.

I normally keep the LED minitester on the RS-232 line. I seldom need it, but it doesn't hurt anything to leave it there.

This of course is all in the context of debugging without expensive equipment. Outside of that, I've used LEDs as status annunciators that were not particularly related to debugging. But just to see a light blink for no purpose is, well, rather puposeless.

[enso]

When I design FPGA boards I always place an LED on them. A blinking LED means the board is alive after programming. I blink it in hardware, then I blink it in software to see if the CPU is alive. To me a blinking LED is an old friend, a thing of comfort. Later in development, the LED is always used for some kind of debugging tool.

[Simon]

I have a 74HC573 8 bit latch with LEDs attached on my machine with logic so I can address it like an IO port. That's proven to be very valuable in debugging my Orwell machine. You can copy entire memory locations to it and from BASIC I can POKE values to it to make the LEDs light up.

Simon

[Aslak3]

Simon wrote:

I have a 74HC573 8 bit latch with LEDs attached on my machine with logic so I can address it like an IO port. That's proven to be very valuable in debugging my Orwell machine. You can copy entire memory locations to it and from BASIC I can POKE values to it to make the LEDs light up.

I use exactly the same trickery here. Very useful when I was getting the DUART working. I use it for showing "boot progress" as well.

[fachat]

Yes, having a blinking LED is always the first sign of life! Love it!