#avr Logs

Aug 28 2019

04:38 AM Smidge204: Wanting to save power while in sleep mode, and waking on pin interrupt, what would be the lowest power state to trigger asid interrupt? Like, should the internal pullup be enabled and wait for the line to go low, or wait for the line to go high?
04:45 AM Smidge204: The situation; I'm using a 1-of-4 switch to select alarm and set modes for this talking clock project. I'd like a change in the switch state (multiplexed into 2 pins) to trigger a wake
04:45 AM LeoNerd: Ah the 814 is a new xtiny 1series, so yeah. But only on pins 2 or 6 - so PA2 PA6 PB2
04:45 AM Smidge204: Wow really, lemme take a closer look at that
04:45 AM LeoNerd: Any of the other pins can do pinchange interrupt but only synchronously, which means they use the input synchroniser so that has to have CLK_PER (i.e. the main CPU clock) running
04:49 AM LeoNerd: 16.3.2.3 has a table explaining the types of interrupt vs. types of pin
04:50 AM LeoNerd: Looks like I misremembered a bit. The fully-async pins can wake on any kind of change, whereas the non-async pins can wake in "bothedges" or "level" mode, but not single edge mode
04:52 AM Smidge204: "All pins can be used for external interrupt, where pins Px2 and Px6 of each port have full asynchronous detection"
04:52 AM LeoNerd: Ah; and the bit about pins 2 and 6 is noted ... yes you found it
04:52 AM Smidge204: Aha. Well that's kinda balls but I can work around that
04:52 AM LeoNerd: It's fine, it just means you'll have to use BOTHEDGES mode, and you can throw away the edges you don't want in software
04:52 AM Smidge204: But that means I have three such pins; PA2, PA6 and PB2
04:52 AM LeoNerd: I usually do that with a `static uint8_t` in the ISR that captures the previous value
04:53 AM LeoNerd: Then your logic can compare to the old value and ignore the edge you didn't want
04:53 AM Smidge204: All I really care about is waking on change - any change
04:53 AM LeoNerd: Ohright; you'll be fine then
04:53 AM LeoNerd: Any pin can do BOTHEDGES
04:55 AM Smidge204: This is for my talking clock project, so I'd like to sleep/power down 99.999% of the time it's doing nothing but wake on three conditions: User presses the main button to announce the time, user changes the state of the mode switch (alarm on/off and alarm/time set), the external RTC chip triggers an alarm signal
04:55 AM Smidge204: But realistically I only have two IO pins that could wake from a power down state, it seems: PA2 and PA6
04:56 AM Smidge204: PB2 is used by the UART currently
04:56 AM LeoNerd: No...
04:56 AM LeoNerd: Reread again what I said
04:56 AM LeoNerd: And also take a look at 16.3.2.3
04:57 AM Smidge204: Right but if I"m in power down mode, then only full async will work?
04:58 AM LeoNerd: Have you looked at the table at the end of 16.3.2.3 ?
04:58 AM Smidge204: Yes I'm looking at it now
04:58 AM LeoNerd: So, the two lines where it says BOTHEDGES and LEVEL mode "will wake system" for all of the pin types
04:59 AM Smidge204: Even from power down?
04:59 AM Smidge204: Or just sleep?
04:59 AM Smidge204: 'cause it looks like I'd have to use sleep instead of full power down to use the other pins as interrupts
04:59 AM LeoNerd: "powerdown" is a kind of sleep
05:00 AM LeoNerd: "sleep" means that the main CPU clock is not running
05:00 AM Smidge204: "Standby" then :p
05:00 AM LeoNerd: Which /kind/ of sleep that is - idle, standby, powerdown - chooses what other peripherals keep running
05:01 AM LeoNerd: You furthermore might want to look at table 11-2 in section 11.3.2; it explains what kinds of interrupt can wake from what kinds of sleep
05:01 AM LeoNerd: In particular it notes that "INTn and pin change" can wake from all of idle, standby, and powerdown
05:01 AM Smidge204: I see
05:02 AM Smidge204: I guess I misunderstood what was said earlier then.
05:02 AM LeoNerd: Yah there's various subtle details in 3 different bits of the datasheet here :)
05:02 AM LeoNerd: But to summarize for your situation: If you are using BOTHEDGES then any pin can wake from any sleep state
05:02 AM Smidge204: That's fantastic then
05:03 AM LeoNerd: You'd only need to care about which pins to use, if you were using RISING or FALLING mode, but you said you wanted either edge, so I guess you're all good :)
05:04 AM Smidge204: Yeah I'm fine with waking then checking the pin(s) to see the actual state
05:09 AM cehteh: the INT interrupts are available only on few pins and allow wakeup from lowest sleep
05:10 AM LeoNerd: I don't know why the datasheet talks about "INTn" interrupts, because those don't exist now
05:10 AM LeoNerd: Any pin can be an interrupt source
05:11 AM cehteh: when going to sleep you should disable all shit running (adc, unused timers, watchtdog, bandgap) and possible disable pullup global (PUD bit somewhere) to save the most power
05:11 AM cehteh: i meant IN0 / INT1 etc
05:11 AM cehteh: not pinchange
05:11 AM cehteh: because pinchange interrupts dont wake from lowest sleep
05:12 AM cehteh: at least for some chips,
05:12 AM LeoNerd: That's all good advice for the older chips. This is the t814, one of the new xtiny 1-series
05:12 AM LeoNerd: Quite a different peripheral
05:12 AM cehteh: ah ok
05:13 AM LeoNerd: On the xtiny there's no longer a distinction between "interrupt" and "pinchange" - any port of any pin can be in any interrupt mode
05:13 AM cehteh: i just have the tiny84 datasheet open .. pinchange can wake from lowest sleep there as well
05:13 AM LeoNerd: You only get one ISR per entire port, but you can do any edge detection on any pin
05:13 AM cehteh: interesting
05:13 AM cehteh: yes
05:14 AM LeoNerd: I like it - it makes them simpler to handle, not needing to route/reserve a special pin for some interrupt
05:18 AM cehteh: yes
05:19 AM cehteh: well if that would be configureable it would be nice, but we cant ask for anything :D
05:20 AM cehteh: for each pin the kind of interrupt (HIGH, LOW, RISING, FALLING) and then route that to an ISR
05:21 AM cehteh: often it sucks to have too mcuh ISR's , sometimes you want that
05:27 AM LeoNerd: I usually find one ISR per port is enough; it's rare you'd need more than 2 or 3 different -kinds- of behaviour
05:27 AM LeoNerd: A few I²C or SPI slave chips, one each. Or maybe a group of buttons can just share one ISR
05:27 AM LeoNerd: Plus if you really do have to share two unrelated things in one ISR you've still got the .INTFLAGS register
04:05 PM captain_morgan8 is now known as captain_morgan
05:42 PM rue_mohr: how many io do you have for how many buttons?
11:31 PM day__ is now known as day