Using Pull-up override PUOExn, PUOVxn

Projects Programming
1

Dear fellow forum members,

I'm using the Arduino Mega 2560.
In the Atmel Datasheet, I found that alternate pin configurations can be controlled on a lower level by controlling the respective registers.
Also, I'm aware of the ability to use the PortManipulation library for writing a specific byte to a port.

Yet nowhere in the internet, I have found how to control the PUOExn or PUOV signals per pin...
The Atmel Datasheet is rather confusing on the latter...

Who could point me in the right direction of how to use this?

Much apprediated!

2

Are you trying to enable an internal pull-up resistor?

3

Yes, but not simply that:

I have all pull-up resistors disabled ( in the MCUCR register, the PUD bit has been set) BUT I want to be able to override this global setting for every pin apart for a short time during a subroutine.

setting the PUOExn register high allows the value set in register PUOVxn (0 or 1) to override any value set in the PUD.

And I need to find the way to set these registers (PUOExn and PUOVxn).

4

I have all pull-up resistors disabled ( in the MCUCR register, the PUD bit has been set)

Why?

I want to be able to override this global setting for every pin apart for a short time during a subroutine

Why?

setting the PUOExn register high

"PUOE" is not a register. It is a "signal line". A signal line that is very likely controlled indirectly by various subsystems (like SPI).

5

wazzco:
I have all pull-up resistors disabled ( in the MCUCR register, the PUD bit has been set) BUT I want to be able to override this global setting for every pin apart for a short time during a subroutine.

setting the PUOExn register high allows the value set in register PUOVxn (0 or 1) to override any value set in the PUD.

And I need to find the way to set these registers (PUOExn and PUOVxn).

Well, you can't do it.

The PUOE and PUOV thingies are not bits that you can set in a register somewhere. They are signals that are generated under certain conditions for certain pins. In particular, they control pull-ups for alternate I/O functions (not general-purpose digital read/write functionality).

For example for the '2560 Port E (Table 12-16 and 12-17)
There are no signals for bits 7, 6, 5, 4, 3 ,2 that can cause PUOE or PUOV to be asserted for those pins. (Normal DDR functionality holds, and can not override the setting of the global PUD bit.)

On the other hand, If you have TXEN0 bit set in the USR0B register, the pin associated with bit 1 will be an output pin (DDOE is set and DDOV is 1, overriding the normal DDR register), and nothing you can do can enable the pull-up (PUOV is 1 and PUOE is zero) ---makes sense, right?

Then...
If you have the RXEN0 set in the UCSR0B register, PUOE for this bit is set, the PUOV signal will enable the pull-up resistor if you have written a '1' to bit zero of the PORTE register and have not written 1 to the PUD bit. (In other words you can't override it.)

Certain other alternative function bits can override the PUD bit (For bits associated with the pins used for JTAG inputs the pull-ups will be enabled when the JTAGEN fuse is programmed, regardless of the PUD bit value.)

I can't think of any other I/O bits of any kind for which the pull-ups can be enabled in spite of the PUD bit. (I could be wrong about that, but I am certain that for the vast majority of I/O pins, the pull-ups can not be enabled when PUD is set. Well pretty certain.)

Regards,

Dave

6

Dear Dave,

thank you kindly for the liberating answer! The solution is as I feared...
Thank you very, very much for taking the time to explain this matter in detail!

Just one last question:

From the ATMEGA2560 datasheet (Figure 27-3 page 306) it seems like the JTAG chain (EXTEST in particular) has the final call over the PUE signal. In extremis, would you deem it possible to program the processor to manipulate its own JTAG chain in order to gain absolute control of the output? (Admitted: practically, this would be very inefficiënt)

Kind regards!

7

wazzco:
...JTAG chain (EXTEST in particular) has the final call over the PUE signal. In extremis, would you deem it possible to program the processor to manipulate its own JTAG chain in order to gain absolute control of the output? ...

I'm not sure whether this answers your question, but here's my take on JTAG for ATmega1280/2560

In boundary-scan mode, almost all of the I/O (pins other than the specific ones dedicated to JTAG command/data operation) are connected as an external scan chain (a big ol' shift register) that can be controlled directly by the equipment connected to the JTAG signal pins. The purpose of this is to be able to test PC board integrity and interaction with other JTAG-enabled devices by letting the test equipment cause the JTAG boundary scan register to apply signals to chip pins and read values of chip pins to see how they interact with other signals and devices on the PC board.

The test equipment can do just about anything it bloomin' well wants, regardless of what would have been going on inside the Arduino running a program.

On the other hand...

In OCD (On-Chip Debugging) mode, a program like AVR Studio controlling a suitable JTAG debugger can interrupt program flow to access an internal scan chain to read (and write) internal registers and other state information of a running program to help programmers try to figure out what went wrong in applications where, for some reason, things like our old faithful "Serial.print" instructions sprinkled around the landscape won't cut it.

Bottom line for me in OCD mode:
The JTAG pins themselves are forced to behave as outputs or inputs (with or without pull-ups), as defined by the JTAG interface specification, but the other I/O pins are still controlled by the "normal" DDR and PUR registers. Modes of certain pins, operating with "Alternate Port" functionality are overridden by the DDOE, DDOV, PUOE and PUOV, etc., signals.

Regards,

Dave