Stealth Blinky

A long standing habit with me is to make sure that whenever possible, any processor for which do the system design blinks at least one LED under software control, and has at least one LED on at any given time. This isn't just whim -- when you've got a headless system, and it's sick, you can knock down the top two problems by looking at the lights: "is there a light on?" -- yes, you've got power, no, you don't; "do you have blinky?" -- yes, the processor is at least basically functional, no, the processor (or software) is dorked.

Now I've got a customer who has a system and who wants the lights to stay on steady. But I really like my little diagnostic (it's saved my hind end numerous time with manufacturing and service personnel).

So, is it too weird to blink the lights under software control at 50 or

100Hz? They'll appear to be steady to the naked eye, but if you wave the instrument in the air (it's hand-held) then a running processor will show you a train of dashes, while a dead one will show you a solid streak.

I've got to blink the lights for certain error conditions anyway, so it's not like I'm adding a bunch of work to do this.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

Seems kosher to me. Although explaining "wave it around and watch" to untrained personnel may get complicated.

--
Rob Gaddi, Highland Technology
Email address is currently out of order
Reply to
Rob Gaddi

I also like to have push button(s), as well. Other than /RST, of course. One is a minimum. I can then use it to affect behavior in some useful way during diagnostics. In the end, it often finds other use if I'm on the phone with someone having a problem (because I will use the PB in an undocumetned but useful way in the final version that helps me.) But YES on the LED idea, too. ;)

Insistant on it? Why?

I do more, where it doesn't conflict with the instrument. (Sometimes, it is a conflict and instrument needs always trump my LED use for obvious reasons.) I use a geometric progression on PWM to make it appear rising and falling along an intensity line. Brightens, then dims. Etc.

Yes. In one product, I even used one PB and one LED and allowed complete programming via several different PB commands (long hold, short hold, or combinations -- kind of like Morse code, really) to allow quite a variety of modes to be entered, device IDs to be programmed and saved, etc. All using one LED for precise feedback and one PB. (Mostly, for calibration and final setup before shipment use -- but there were the few times where service personal on-site used it.)

You can do a LOT with one LED and a PB.

Jon

Reply to
Jon Kirwan

I like using bicolor LEDs for this purpose. I arrange the hardware so that a "reset" processor leaves the red lamp illuminated. Once the processor gets to "some point" in it's BIST, I have it toggle the LED to Green (substitute whatever colors you have available). Once the system is running, I drive it with AC to yield Yellow.

This tells me:

- power is available (else it is a D.E.D.)

- processor hasn't managed to get started doing *anything*

- processor has achieved "minimal sufficiency" (whatever that means... maybe "I appear to be working but my runtime is corrupt)

- processor is actively running

[note that I don't rely on this for the *user*. To her/him, the light is on YELLOW or off -- the RED and GREEN states are transitory so he/she need not be able to comment on their actual color]

I like to drive visible indicators syntonous with the local LFC.

If stuck with a monochromatic LED, you can duty cycle modulate to get a "signal" that someone knowing what to look for can easily detect -- yet, to others, is nonexistent. E.g., at startup, run LED at 100% for 1.0 second (or some nice easily recognizable duration). Then drop down to ~80% for your "normal" indication.

The drawback of this approach is that it isn't static -- you need to see the processor coming out of reset in order to sense the change in intensity. (you could also modulate the duty cycle with a very low duty cycle square wave so the lamp briefly brightens periodically)

Reply to
D Yuniskis

BTW, an unused EIA level translator makes a cheap driver for a bicolor LED.

With all the I/O programmability present in newer MCU's, you can hang this on an unused UART TxD. This makes it a little cleaner to drive (you just instantiate another copy of your serial port driver and pass "characters" out through it).

On some industrial control devices, I used this scheme to "sneak" diagnostic output out of the device (run some clipleads to a DB25 and plug a dumb terminal into that): "BIST complete\n" "OS initialization complete\n" "Starting LFC task @ 0x2100\n" "Starting battery monitor @ 0x3008\n" ... "System operational\n" ... "Operator commanding full N motion\n" "COM2: Carrier detected\n" "N-S motor at N limit\n" ... "LFC: power fail detected\n" ... "Battery exhausted. Shutting down\n"

If you don't have the ability to reprogram the pin as a pure output, then you have to keep up a continuous "chatter" to keep "AC" on the lamp. A cheating way to do this is to pad idle time with BS characters -- if they appear *after* a newline, many terminals will treat them as noops, effectively.

Reply to
D Yuniskis

In my experience, the first thing you do with a new board is get a blinking LED to work. (The second is to find a way to update the firmware safely in-system, so that the board can ship even though the software is not finished....)

I would say a 100 Hz blink would be fine, and appear steady in normal use. 50 Hz is too slow - if you see it from the corner of your eye, it would appear unstable.

If the customer wonders why it is blinking, you can always tell him it is a power-saving technique. Blinking an LED at 50% duty cycle at 100 Hz will use half the power of a 100% duty cycle, but appear about 90% of the brightness.

Reply to
David Brown

In things I did, we called it a "heartbeat", and the customers were fine with that -- our particular customers were, anyway.

Mel.

Reply to
Mel

Ha ha how true that is :) And it's often the hardest part of getting to grips with a new chip. You have to delve into linker scripts, relocating sections into RAM so you can run the bootloader there so you can reprogram the flash... By the time the bootloader is written I usually know the systen well enough that the rest is simple.

[...]
--

John Devereux
Reply to
John Devereux

A simple "Its running' has saved me a lot of hours of debug time.

One blinking light use might be to broadcast current status messages.

w..

Reply to
Walter Banks

e

ak.

A steady-state full intensity duplicate right next to the 80% one would give you enough contrast.

I wonder if cellphone cameras could 'see' an infrared LED? The customer would see nothing, but your phone could be used to troubleshoot/confirm operation.

Reply to
1 Lucky Texan

Yes, but that adds a component just to give you a "reference" (I think the point is to get as much information out of the least componentry)

Yes, most digital cameras will (though I can't speak for all!). But, an Ir LED doesn't tell the customer "power is on", etc. In fact, it might result in more support calls: "The power indicator (that *must* be what this thing does, right?) on my Wonkerator8000 doesn't light up!"

Reply to
D Yuniskis

All cellphones with camera I have had so far were able to see IR LED's. It is a great diagnostics tool to check IR remotes.

Reply to
Dombo

Just label it 'warning light'.

Reply to
1 Lucky Texan

Hmmm... you don't, by chance, work for MICROSOFT??? ;-) (sure sounds like the way *they* would "solve" the problem. And, then, file for PATENT PROTECTION on their innovative new idea! :-/ )

Reply to
D Yuniskis

In message , Tim Wescott writes

Another trick would be to wave your hand, fingers spread in front of the 100Hz LED. You will get a stroboscopic effect and the LED will seem to blink slower.

--
 To reply, my gmail address is nojay1              Robert Sneddon
Reply to
Robert Sneddon

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.