RESET/ pin with debugWire and an external interrupt source

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

In the hunt for just one more ATmega328 line that can be used as an external 0-level interrupt input I'm wanting to use the RESET/ pin. The user guide defines the RESET/ pin as open-drain when the DWEN fuse is programmed. The guide's Alternate Functions of Port C section also says that the RESET/ pin can be used as a Pin Change interrupt input PCINT13.

So it looks like I could attach an external interrupt open-drain/open-collector pull-down to RESET/ to generate interrupts and still preserve debugWire functionality. Anyone ever tried this? I'm wondering what would happen if the external int source stuck open-drain low when debugWire tried to take over the pin. My guess is that debugWire would choke.

Chris

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

Every time that you issue a debugWIRE command, the PCINT2_vect will fire. (if you have enabled PCINT14)

I don't know where you get PCINT13 for the PC6 pin.

There are generally better ways of using GPIO pins than tying your hands behind your back and trying to shoot your foot.

David.

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

David, it's PCINT14 for the RESET pin, not 13 (my typo).

I find your closing comment superfluous, esp. with zero knowledge of the overall design or its pin usage.

After thinking about it a bit more I've come to the conclusion the only way using the RESET pin as an int input and still preserve debugWire functionality is if I can ensure that the int source can't stick low. In this case I cannot...

Chris

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

It was intentionally superfluous. It means that you should think through your design again.

If you posted your GPIO requirements, I bet that some bright member can offer a solution for pin sharing.

If there is no solution, move to a mega324. The extra size of TQFP/QFN is trivial.

David.

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

Quote:

In the hunt for just one more ATmega328 line that can be used as an external 0-level interrupt input

I'm more of the "look for one more edge-triggered interrupt pin" camp.

Are you out of pins, or out of external-interrupt pins?

It must be "out of pins"; otherwise you could do the pin-change trick on any pin on that model.

Tell more about the need before all the foot-shooting starts. Do you need this for awakening?

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

theusch wrote:
Tell more about the need before all the foot-shooting starts. Do you need this for awakening?

:) Thanks for the actual offer of help. I have a good sense of humor but I have little tolerance for rudeness.

I'm an experienced engineer but have only been working with AVRs for the last 6 months and I greatly value being able to post q's here. So I'm still unraveling all my low-level options when it comes to pin usage.

This design is a real product. I didn't want to overload the question with tons of design details but it's probably a typical "well used" AVR with the following I/O:

    3 push buttons (w/ pin change ints) 2x16 LCD (4-byte data,E,RS,hardwired R/W line)
    Bit for LCD backlight control
    4 SPI pins + 1 CS bit for wireless transceiver
    (hunting for a wireless IRQ pin)
    2 Xtal pins
    3 bits for 16bit shift reg high current driver interface (2 of these 3 shared with 2 LCD data bits)
    3 A/D voltage inputs (1 of which is shared with a digital input)
    1 sensor input bit
    1 output device bit
    RESET pin

The product doesn't actually need a reset button. The wireless IRQ pin I'm searching for is not 100% necessary--I could just periodically poll the RX/TX queue--but everything else is efficiently int-driven. Still, this is not a horrible option.

There aren't any other pin functions that could easily be shared without additional h/w (which is still an option).

Pin assignments are all about managing design tradeoffs so I'm at a point now where there are fewer degrees of pin-changing choices. Hence my attention on the RESET pin.

Any feedback greatly appreciated!

Chris

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

Quote:

Any feedback greatly appreciated!


So, are you out of pins or not? I lost count. 25?

What package are you using?

What clock source is your AVR using? Crystal, in fact, as the pin listing suggests? If you need "one more pin" you could use some kind of external clock source.

Why do you have 4 SPI pins plus a chip select?

Side comment on

Quote:

3 push buttons (w/ pin change ints)

Generally, buttons on interrupt pins are just for wakeup, as buttons bounce.

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

I do not think you can use nRESET as IO with only DWEN programmed. Asserting it low halts the uC (that is how the dongle does the "halt" trick).
AFAIK the only way to use this IO is to RSTDISBL.

If you are desperate to RSTDISBL - please send us some pictures from desoldering and HVPP.

No RSTDISBL, no fun!

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

theusch wrote:

So, are you out of pins or not? I lost count. 25?
What package are you using?

Yes outta pins, using 28pin DIP on this board.

Quote:
What clock source is your AVR using?

Using a crystal. Using an external osc is possible but that may be more expensive in $ and space than discretes to enable sharing of another bit. Not sure yet.

Quote:
Why do you have 4 SPI pins plus a chip select?

The chip is the Nordic nRF24L01+ 2.4G transceiver. It uses the full SPI i/f + a separate CS for RX/TX select.

Quote:

Side comment on 3 push buttons (w/ pin change ints)
Generally, buttons on interrupt pins are just for wakeup, as buttons bounce.

Yep that's how it works. Any of the key ints wake up the key-handler task that is managed by a coop m-tasker running w/ a 10mS RT clock.

Still kicking around other line sharing ideas. Like I said before the wireless int is not 100% necessary but running without it would require more careful time/packet arrival awareness as the number of remote nodes increases.

Chris

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

Brutte wrote:
I do not think you can use nRESET as IO with only DWEN programmed...If you are desperate to RSTDISBL - please send us some pictures from desoldering and HVPP.

Thanks for the advice...and the chuckle. I had to look up HVPP. I'm steering clear of using RESET for now.

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

Okay, I surrender. After exploring quite a few other line-sharing ideas including using discrete MOSFETs, external latches, and analog switches I decided to just set one of the unused timers to interrupt often enough to ensure no lost wireless packets. All the timer ISR does is poll and transfer the wireless chip RX fifo to a circular buffer and return.

Doing it this way limits the # of times I have to bang the SPI interface for polling i.e. less digital noise on a board with analog sensors being read. Using this timer interrupt approach also eliminates having to worry about the worse-case latency of the other tasks that might cause missing a packet.

It was a good exercise but I like the zero-added-hardware approach best. Don't need no stinkin' IRQ...

Chris