Mega-0 Analog Inputs?

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings

 

Trying to get up to speed on Mega-0 ADC operation. One of the key elements is management of the input port pin.

 

The ADC documentation explicitly says:

 

I/O Lines and Connections

The I/O pins AINx and VREF are configured by the port - I/O Pin Controller.

The digital input buffer should be disabled on the pin used as input for the ADC to disconnect the digital domain from the analog domain to obtain the best possible ADC results. This is configured by the PORT peripheral.

It took a while to trace down the place to control this. It seems to be in the PINCTRL register for the pin in question. While the caution, quoted above does not say so, it appears that the pull-up resistor is unaffected by the digital input buffer control so that it, also, needs to be turned off. It defaults off on bootup so normally, one would not have to do something except, maybe for "just being safe". That is also managed by one of the bits in the PINCTRL register so both disable of the digital input buffer and turn-off of the pull-up can be done in a single config write to PINCTRLn.

 

That is what I have found, so far. BUT (always a "BUT") the block diagram of the port structure shows an "Input Disable Override" signal that would appear to have precedence over the signal that disconnects the digital input block. It is not at all clear what the origin of this signal is, or if it even needs to be taken into account. Does anyone have any knowledge about this? After all, code CAN be actively executed while the ADC is running and if that code does something that causes the Input Disable to be overridden, the reading could be faulty!

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Tue. Jul 20, 2021 - 05:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have something like the Twi peripheral in use, it will override the input disable. Other peripherals that are less 'involved' with the pin overrides like usart rx, will not help you out if you disable its input. Which peripherals override input disable, not sure, but Twi is one of them at least and could be the only one.

 

For power saving, in early code I just loop through all pinctrl registers and set them to input disable (reg=4). Any unused pin will be all set for low power mode and do not have to deal with unused pins ever again (better than pullups, as will not be possible to source current). The pins you use will need the input disable 'removed' when setup (edit- if you need to use the input), except for twi which does its own thing (except if you need internal pullups for the 2 pins). If there are dedicated adc/ac pins, then they really do not need any changes either as they are also already setup.

Last Edited: Tue. Jul 20, 2021 - 05:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my application, ADC circuits a dedicated to analog measurement. There should never be any conflict with TWI (if properly configured).

 

Thanks

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

... One of the key elements is management of the input port pin. ...

... After all, code CAN be actively executed while the ADC is running and if that code does something that causes the Input Disable to be overridden, the reading could be faulty!

I think that you are perhaps reading too much into this.

 

Let's scroll back a couple decades, and consider your AT90S8535 app.  Yes, the code you wrote COULD make the ADC pin an output pin.  Yes, the code you wrote COULD turn on the internal pullup.

 

Now advance a decade, and consider your ATmega88 app.  Yes, the code you wrote COULD make the ADC pin an output pin.  Yes, the code you wrote COULD turn on the input pullup.  Yes, the code you wrote COULD overwrite the value that you placed into DIDRn.

 

In summary, you can have rogue code in any app that destroys the intended operation.  Given that [say] Mega88-generation AVR8 models also have DDR and pullup and DIDR capabilities, how is what you described for this generation that much different?

 

Are your "cautions" really any different than

For analog input pins, the digital input buffer should be disabled at all times. An analog signal
level close to VCC/2 on an input pin can cause significant current even in active mode. Digital
input buffers can be disabled by writing to the Digital Input Disable Registers (DIDR1 and
DIDR0). Refer to ”DIDR1 – Digital Input Disable Register 1” on page 249and ”DIDR0 – Digital
Input Disable Register 0” on page 266for details.

...and other notes when you search an AVR8 datasheet for "input buffer"?  I say not.  You sparkies can educate me.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My question involved the ill-defined "Input Disable Override". The spec sheet gives no hints (that I could find) about what might create such an override. So, how do i know what not to do while the ADC runs? It is not a matter of a rogue operation. it is all about what might generate that override? curtvm has suggested one situation with twi. I would have never guessed that! Remember, this is a M4809 or similar with lots of port multiplexing and such.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Wed. Jul 21, 2021 - 04:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

ka7ehk wrote:
It is not a matter of a rogue operation.

???  Isn't that what you said?  Or implied?  Is "rogue" not a good word to describe what you said was code that can change port pin operation? 

 

As I'm not familiar with that series, perhaps you can give me some links to the series and model documentation that you are quoting, especially in the light of the recent thread about the changes in documentation structure.  https://www.avrfreaks.net/commen... Then I'll compare that wording with [say] Mega88 where DIEOExn and friends are discussed.

 

Start with the general discussion, which concentrates on SLEEP and has the mention of the possibilities when a level sits around Vcc/2:

and the figure simply shows

 

But then we keep digging to Alternate Port Functions and there is more detail

...

...

 

Aren't these signals analogous to what you are referring to?  And there are no such discussions or tables in your  device documents?

 

 

 

 

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Jul 21, 2021 - 11:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Indeed, one needs to dig around.  From a device datasheet, in the end it sounds just like AVR8, albeit all done in ISC register:

I picked this document to look at https://ww1.microchip.com/downlo...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC, input overrides are enabled when alternate functions are enabled for affected pins, hope that helps!

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


This from the 4809 datasheet:

 

The best place to look where override can happen is the I/O Mux section ...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My starting reference is Figure 16.1 in the document theutch referenced. In my older document, the signal was called "Input Disable Override" but now is called "Peripheral Override". There are several instances of that signal name in that block diagram. The one I am concerned about is near the bottom of the diagram.

 

My question ought to be pretty simple: What are the conditions in which that "Peripheral Override" signal is asserted? No reference to that text is found in the text of the document. BUT, a lot of that document is in image blocks that are not readily searchable.

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


As 16.3.2.4 says, the override is peripheral-dependent.   So I think you need to read the documentation for the applicable peripherals.  For example:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, this heads me straight into the dilemma of managing various peripheral I/Os when a large fraction of the package pins have to be used. Got to deal with that one somehow. I've known it was coming ...

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
My question ought to be pretty simple:

And I think the answer is also pretty simple:

 

The Section: 4.1 Multiplexed Signals is key.

You mentioned Analog Pins; so lets consider AIN1. Here's the relevant line from the table:

 

TQFP48/
VQFN48
PDIP40(4) TQFP32/
VQFN32
SSOP28 Pin name(1,2) Special ADC0 AC0 USARTn SPI0 TWI0 TCA0 TCBn EVSYS CCL-LUTn
21 10 11 7 PD1   AIN1 P3       0-WO1(3)     2-IN1

 

We see that AIN1 competes with AC0, TCA0 and CCL for use of the Pin.

 

We've read above in #11 that TCA overrides the port value when waveform generation is enabled but not the direction.

For AC0 no override is specifically mentioned.

For CCL-LUT2 the only mention of override is for output pins.

 

This is a standard problem of pin selection as part of the design process. There is nothing nefarious going on here at all.

 

Last Edited: Wed. Jul 21, 2021 - 06:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
My question ought to be pretty simple: What are the conditions in which that "Peripheral Override" signal is asserted?

That isn't what you asked at first, is it?  I thought the query was about input disable, not peripheral override.

ka7ehk wrote:
BUT (always a "BUT") the block diagram of the port structure shows an "Input Disable Override" signal that would appear to have precedence over the signal that disconnects the digital input block. It is not at all clear what the origin of this signal is, or if it even needs to be taken into account. Does anyone have any knowledge about this? After all, code CAN be actively executed while the ADC is running and if that code does something that causes the Input Disable to be overridden, the reading could be faulty!

Those are two different things, aren't they?  I guess they could be related -- if you mark a pin as Input Disable does/can Peripheral Override -- well, override that selection.

 

Again, though, I don't see where the newfangled series operates in a substantially different manner than classic AVR8 of the Mega88 era or later (i.e. the ones with DIDR feature).

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Jul 21, 2021 - 07:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N. Winterbottom - nothing nefarious is assumed. Just my confusion!

 

Theusch - I accidentally started out with the old spec sheet. The override signal has a different name in the new one. 

 

Winterbottom suggests a plausible case: there are peripheral uses that override the port configuration and that signal is used to manage that override. That hypothesis is, at the very least, testable. I guess that as long as you (e.g. "the programmer") don't program two or more things to use the same port pin, there should be no problem with Peripheral Overrides.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Here is the diagram in the 4809 sheet.  It seems to indicate, as you say, that peripherals can override DIR and INPUT_DISABLE.

 

And the sheets says that if a pin is configured for output you can still read it.   I'm guessing (not confirmed) that you can generate software interrupts this way.

 

 

 

Last Edited: Wed. Jul 21, 2021 - 10:26 PM