A really useful Arduino

Y'know what would be really useful to have on an Arduino board? An LED on every pin. It would be great for beginners - no more poking LEDs into headers or annoying the forum-regulars by forgetting to use current limiting resistors. It would be great for debugging without a serial terminal, or simply to indicate what the Arduino is doing. Or just to scratch that itch we all have to make flashy blinky things (c'mon, admit it...)

The LEDs would need to be FET-driven so that pins can still be used as high-impedance inputs. I have already made a shield which does just this, but it would be a lot neater to have surface-mount components on the main board.

I'm not suggesting this for the official Arduino Uno, but maybe there's a clone manufacturer out there looking to make something slightly different. What do you think?

Could be useful.
I could see it leading to a new set of questions, "why is my LED flickering or turning on/off randomly or when I wave my hand around?" with more answers like "Enable the internal pullup so the unused pin is high and not floating."

Honestly, I think that is a good idea. Right now we can do the same thing using Serial communications, but it would definitely help in debugging.

But wouldn't a shield be the right way to go for this? Because I wouldn't really want the board blinking with about 20LEDs all the time. Or maybe there would be a way to turn it off (debug=false) so I don't have to see the blinkies when I'm not debugging

there is a shield that might help,

Blinkenlight ,

leds on each pin,
but no fets,

The thing with shields is they're often just as expensive as a whole Arduino. Even an empty prototyping shield is just $5 less than an Arduino Pro. So even if you don't want flashing lights in the final project (who would want that?!), cost-wise you might as well buy two Arduinos: one with lights for development, and one without for installation.

The point about interference is good. Perhaps a largish pull-down resistor on the FET gates would be tolerable. It would still be better than connecting the LEDs directly (as on the Uno does on its pin 13).

As nice as this option seems in theory, the main issue is one of the impact it could have on measurements and the like. Try using an ADC while even a small LED (i.e. like the 3mA 0805 models from Osram) are pulling off current. Thanks but no thanks. Those that need lights to know what the status of an output is have yet to learn how to use a multi-meter I guess. My recommendation for the folk who want to do this on the cheap is to buy a RBBB from modern devices and put it in a breadboard, along with the requisite LEDs and resistors.

No, in my mind a much better modification to the Uno is the Ruggeduino from Rugged Circuits. Great concept and excellent work regarding detecting all the possible means of frying an Arduino and ways to mitigate said risk. But note that the impact on signals due to the Zeners and other protective aspects are mostly minimal.

the rugged uni has saved me more than once,

now when / if the rugged mega come out,
things will only get better.

but then well want the rugged 32 bit version !

" It would still be better than connecting the LEDs directly (as on the Uno does on its pin 13)."
Uno no longer does that -

D13 LED now driven by the other comparator in the LM358.
I have answered questions about why the L LED is on because of that.

Constantin:
Try using an ADC while even a small LED (i.e. like the 3mA 0805 models from Osram) are pulling off current. Thanks but no thanks.

Constantin, that's not what I'm suggesting. Take a closer look at my message.

Those that need lights to know what the status of an output is have yet to learn how to use a multi-meter I guess.

Ahem. Some people have yet to learn how to use lights I guess :wink:
With LEDs you get to monitor all channels (20 on an Arduino) simultaneously. They respond quickly, so you can see when communication channels are active. And they're small and cheap, so they're convenient to put in and may be left installed permanently or semi-permanently.

My bad and apologies for misinterpreting. That said, a shield still seems more appropriate for the application you're describing. Protecting inputs seems like a better use of board space for beginners. But opinions are free to differ. Fwiw, I find it easier to debug via the serial channel since it allows me to not only debug inputs and outputs, but also review responses to same.

Imo, an inexpensive way to implement what you're describing is using an RBBB with a breadboard and LEDs on the channels in question. Makes for an easy development environment and insures that one keeps track of the channels being used.

I too like to use LEDs to keep track of certain channels (serial, among others) in boards i design but certainly not all channels. At some point it becomes confusing to have tons of channels blinking.

Well, there's another issue you might face with LEDs. If you're using SPI or I2C communication and want to see if there's anything going on, I don't think you'll see the LED flicker at all. Similar with really high frequency changes such as PWM etc. In a way, this would work only for anything that has a frequency of less than 30-40Hz.

On a similar note, do you think it would be possible to develop an app for the PC and a library that communicates via UART (or the USB interface in the Leonardo), to show in realtime the states of the various pins? I know there will be a significant lag, but it's a start.

Doesn't processing / fritzing allow you to do much of that in simulation?

Constantin:
Doesn't processing / fritzing allow you to do much of that in simulation?

Fair point. I'd forgotten about processing completely. Setting up an animation should be easy enough.:slight_smile:

I think PWM would yield varying levels of brightness depending on the level, from very dim to full on.
SPI, could be little blip for 1 time transfers to varying levels similar to PWM for longer transfers.

I suppose one could add something at the start of void loop to read the port registers and output a serial message if the state had changed since the previous read of the registers for the ports being used as digital ports. Would require the user to use the internal pullups on all inputs so there were no floating pins.

Just a few quick measurements, driving LEDs at 3mA via BS170 FETs (1.7Ohm on-resistance at Vgs=5V). I switched the Arduino pins from high-outputs to low-inputs (pull-ups disabled) and measured the time response of the FET drains.

  • Without pull-down resistors on the FET gates the LEDs get stuck essentially indefinitely. The Arduino input impedance is extremely high.
  • Without pull-down resistors I could cause the LEDs to change state without touching them.
  • With 10MOhm pull-down resistors on the FET gates the LED response is delayed by 1ms (WRT the pin state-change).
  • With 10MOhm pull-down resistors I could cause the LEDs to change state but had to try quite hard (holding one hand near an AC motor and touching the FET gate with the other).

And the highest frequency which was clearly visible as flickering (to my eyes) was 35Hz.

10MOhm seems a good compromise to me. It's moderately resistant to low-level interference, whilst causing minimal disturbance to ADC input readings.

I started to use http://www.virtualbreadboard.com/ and its still a little slow/clunky and glitchy, but Its seems to support debugging/learning. I recently added a ShiftOut procedure to their 595 java library.

Perhaps a shield that has stacking headers, a LED on each pin and a simple jumper or perhaps DIP switches to disconnect the LED from the pin it is on. That would be pretty easy and cheap to build. However, a better approach is a logic analyzer. It would cost more than a shield, but a logic analyzer is vastly more useful.