next topic »

[on:]

I'm working on a project that requires pins to be in a high-impedance state. For most pins this works fine by setting the pin to input and disabling the pull-up resistor. However, when I do this with pins 0 and 1 they will source enough current to dimly light an LED. Presumably this has something to do with their dual function for USB. Anything I can do to disable this behavior, either in hardware or software?

[Reply #1 on:]

I'm working on a project that requires pins to be in a high-impedance state. For most pins this works fine by setting the pin to input and disabling the pull-up resistor. However, when I do this with pins 0 and 1 they will source enough current to dimly light an LED. Presumably this has something to do with their dual function for USB. Anything I can do to disable this behavior, either in hardware or software?

There are two series 1K ohm resistors going from arduino pins 0 and 1 going to the USB serial converter chip as the link for uploading sketches from the IDE or for general purpose serial comm between a sketch and a PC application. I guess you could cut the traces going to pins 0 and 1, and use a ICSP programmer to load sketches but you would still lose general purpose serial I/O to/from the PC. You choice. You didn't state what model arduino board you have but any of them have published schematics that will show the serial data path from pins 0 and 1 to the USB chip.

Lefty

[Reply #2 on:]

I'm using an Uno, and removing USB programming isn't a good option. I guess the only solution is to upgrade to a Mega so I don't have to reuse the serial I/O pins. Bummer.

[Reply #3 on:]

I'm working on a project that requires pins to be in a high-impedance state. For most pins this works fine by setting the pin to input and disabling the pull-up resistor. However, when I do this with pins 0 and 1 they will source enough current to dimly light an LED. Presumably this has something to do with their dual function for USB. Anything I can do to disable this behavior, either in hardware or software?

Pins 0 and 1 are the serial interface. When the USART is enabled it overrides the normal pin operation.

You can disable it by clearing the relevant bits in UCSRnA (see datasheet).

[Reply #4 on:]

You can disable it by clearing the relevant bits in UCSRnA (see datasheet).

This is an electrical hardware issue, not an internal firmware configuration situation.
The rec data coming to arduino pin 0 from the USB serial converter is going through a series 1k ohm resistor will act as a permanent pull-up to +5vdc as that is the idle state when the USB serial link is not active, so it's an electrical issue and the pin cannot be truly 'tri-stated' as long as that electrical path to the USB chip is intact.

 Now possibly if one wanted to erase the firmware in the USB serial converter chip, what you cause all it's I/O pins to default to input only and thus the two 1k series resistors would be a non issue.

Lefty

[Reply #5 on:]

You have other options - put a '1284 based board with 16K of SRAM & dual serial ports together instead for $25 or less if you parts on hand:

PL here http://www.crossroadsfencing.com/BobuinoRev17/
USB module can be onboard with MIKROE483 from mouser.com, $11
http://www.mouser.com/ProductDetail/mikroElektronika/MIKROE-483/?qs=%2fha2pyFadugsEwyLV5fFyIWdPbushEDhRSvnBE0ODG8%3d

or offboard via FTDI cable or similar USB/serial adapter.
Guess I should get a schematic up there too.

[Reply #6 on:]

This is an electrical hardware issue, not an internal firmware configuration situation.
The rec data coming to arduino pin 0 from the USB serial converter is going through a series 1k ohm resistor will act as a permanent pull-up to +5vdc as that is the idle state when the USB serial link is not active, so it's an electrical issue and the pin cannot be truly 'tri-stated' as long as that electrical path to the USB chip is intact.

Now possibly if one wanted to erase the firmware in the USB serial converter chip, what you cause all it's I/O pins to default to input only and thus the two 1k series resistors would be a non issue.

It seems to me that it is a firmware configuration issue, but that it's a problem with the USART chip's firmware rather than the main microcontroller firmware. If the atmega16u2 were configured to have PD2 and PD3 (the RXD and TXD pins) as inputs, then that would solve my pull-up problems.

So what does disabling the USART (via the UCSRnA register) do? Does this only tell the atmega328 to stop sending serial commands, or does it initiate some communication with the atmega16u2 to initiate shutdown? The datasheet is a bit dense, maybe someone could clarify for me?

If I start playing with UCSR* registers, will a reset restore default USB functionality, or is there a chance of bricking my Uno? I don't have an ISP programmer, so if USB stops working I'm screwed.
 

[Reply #7 on:]

Nothing you do in the code will brick your processor. If you had an ISP programmer you could if you set your mind to it, but you said you don't.

If the atmega16u2 were configured to have PD2 and PD3 (the RXD and TXD pins) as inputs, then that would solve my pull-up problems.

How could it do that? It is designed to send stuff to the Rx pin, not receive from it. The Atmega16u2 chip cannot know what the Atmega328P is doing so it has to assume that incoming data needs to be sent to the main processor. Plus it has to hold the Rx line high (idle) if there is no data, otherwise the low data would be interpreted as random rubbish. The resistors are there so that the main processor can force those lines high or low if it wants to. So that is fine for outputs, but you cannot rely on using them as inputs, for that reason.

You can work around all that by using a simpler board, eg. a chip on a breadboard, or one of the boards that don't have the USB interface, such as the "bare bones" boards.