On Jul 14, 5:22 am, larwe <zwsdot...@gmail.com> wrote:> On Jul 13, 4:57 pm, "John B" <spamj_baraclo...@blockerzetnet.co.uk> > wrote: > > > Set DDRB bit 7 > > Set? That makes it an output. > > > Set PORTB bit 7 to enable the internal pull-up on PB7 > > Clear the PUD bit in MCUCR to enable internal pull-ups globally > > Set PCMSK1 bit 7 (PCINT15 bit) > > Set EIMSK bit 7 (PCIE1 bit) > > Clear SREG bit 7 (I bit) > > Is it necessary to set PCIE1Yes, this enables the Pin Change Interrupt block 1.>if you do not actually want the IRQ to fire?Fine as long as you disable the global interrupt mask.>I want/need to poll this bit in mainline code,I assume you are polling PC!F1.> I can't let an > ISR grab it. (Having said this, the IRQ wouldn't fire when I tried it > the normal way, with PCIE1 set, anyway).It does work for me in normal interrupt mode.
AVR, polling INT0 IRQ bit - help?
Started by ●July 10, 2008
Reply by ●July 13, 20082008-07-13
Reply by ●July 14, 20082008-07-14
On 13/07/2008 larwe wrote:> On Jul 13, 4:57�pm, "John B" <spamj_baraclo...@blockerzetnet.co.uk> > wrote: > > > Set DDRB bit 7 > > Set? That makes it an output.Oops, sorry I originally wrote "Set DDRB bit 7 to 0" and then edited it incorrectly.> > > Set PORTB bit 7 to enable the internal pull-up on PB7 > > Clear the PUD bit in MCUCR to enable internal pull-ups globally > > Set PCMSK1 bit 7 (PCINT15 bit) > > Set EIMSK bit 7 (PCIE1 bit) > > Clear SREG bit 7 (I bit) > > Is it necessary to set PCIE1 if you do not actually want the IRQ to > fire? I want/need to poll this bit in mainline code, I can't let an > ISR grab it. (Having said this, the IRQ wouldn't fire when I tried it > the normal way, with PCIE1 set, anyway).Yes, as Linnix says the PCIE1 bit enables the pin change block for PC15 through to PC8 to function. That will allow the PCIE1 flag to be set. Clearing the I bit in SREG stops that flag propagating through to the interrupt mechanism. -- John B
Reply by ●July 15, 20082008-07-15
On Jul 14, 9:26=A0am, "John B" <spamj_baraclo...@blockerzetnet.co.uk> wrote:> > Is it necessary to set PCIE1 if you do not actually want the IRQ to > > fire? I want/need to poll this bit in mainline code, I can't let an > > Yes, as Linnix says the PCIE1 bit enables the pin change block for PC15 > through to PC8 to function. That will allow the PCIE1 flag to be set. > Clearing the I bit in SREG stops that flag propagating through to the > interrupt mechanism.This isn't how I understood it - as I understood it, yes you have to set PCMSKxxx to enable the specific pin, but then the PCINT8..15 interrupt, PCIE1, is ANDED with PCIF1 and it's the result of this that is then gated with the global interrupt flag to determine if the core gets an interrupt. However, the point is moot - even when I set PCIE1 and disable global interrupts, the request flag is STILL not being set. Atmel claims that my exact same code works on their hardware, so I'm baffled. I can physically see the pin changing state (and I've even verified that the micro is seeing that change of state). Beyond mysterious.
Reply by ●July 15, 20082008-07-15
On 15/07/2008 larwe wrote: . . .> > Yes, as Linnix says the PCIE1 bit enables the pin change block for > > PC15 through to PC8 to function. That will allow the PCIE1 flag to > > be set. Clearing the I bit in SREG stops that flag propagating > > through to the interrupt mechanism. > > This isn't how I understood it - as I understood it, yes you have to > set PCMSKxxx to enable the specific pin, but then the PCINT8..15 > interrupt, PCIE1, is ANDED with PCIF1 and it's the result of this that > is then gated with the global interrupt flag to determine if the core > gets an interrupt. However, the point is moot - even when I set PCIE1 > and disable global interrupts, the request flag is STILL not being > set. > > Atmel claims that my exact same code works on their hardware, so I'm > baffled. I can physically see the pin changing state (and I've even > verified that the micro is seeing that change of state). Beyond > mysterious.Well that certainly does sound strange. I've used the pin-change flag on a mega2561 in exactly the same way as you are trying to. It's possible that the mega169 uses a different block but I would think that's unlikely as they would have to rewrite and test the Verilog. Maybe Ulf will come along soon and give us a definitive answer. -- John B
Reply by ●July 16, 20082008-07-16
On Jul 15, 12:58=A0pm, "John B" <spamj_baraclo...@blockerzetnet.co.uk> wrote:> possible that the mega169 uses a different block but I would think > that's unlikely as they would have to rewrite and test the Verilog.Of course the problem turns out to be my fault (well, someone else in my team originally, but my fault for not spotting it). Our circuit can use the 169/329/649 but initial bring-up was done on the 169. Someone forgot or ignored my advice to include avr.h and instead included mega169.h MOST of the registers are the same between 169 and 32/649 but not all of them. The PCINT bit assignments in particular are different! Also, it is not necessary to set the interrupt mask for PCIE1 in order to see PCIF1 toggling.
Reply by ●July 16, 20082008-07-16
larwe wrote:> MOST of the registers are the same between 169 and 32/649 but not all > of them. The PCINT bit assignments in particular are different!BTW, many small problems like that is one of the reasons for not using AVRs. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●July 16, 20082008-07-16
On Jul 16, 10:45=A0am, Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote:> larwe wrote: > > MOST of the registers are the same between 169 and 32/649 but not all > > of them. The PCINT bit assignments in particular are different! > > BTW, many small problems like that is one of the reasons for not using AV=Rs. I can't blame Atmel for this - we were using the wrong header file. We should have included avr.h and let the compiler pick the correct chip- specific header based on the project settings. I agree this would be an issue if we needed binary compatibility, but in practice we don't (the administrative requirements of changing micros are massive and the cost of SWQA for a recompile-to-new-chip operation is negligible).
Reply by ●July 16, 20082008-07-16
On Jul 16, 10:51 pm, larwe <zwsdot...@gmail.com> wrote:> On Jul 16, 10:45 am, Vladimir Vassilevsky <antispam_bo...@hotmail.com> > wrote: > > > larwe wrote: > > > MOST of the registers are the same between 169 and 32/649 but not all > > > of them. The PCINT bit assignments in particular are different! > > > BTW, many small problems like that is one of the reasons for not using AVRs. > > I can't blame Atmel for this - we were using the wrong header file. We > should have included avr.h and let the compiler pick the correct chip- > specific header based on the project settings.I agree. We can blame Atmel for many other faults, but not for product migrations. If we force them to be binary compatible, then we end up with a static uC architecture. We are moving off the 169 purely for cost reason. Our new uC (6502) is 75% off, but it's difficult to port the hardware/software. The 169 fits so well in the original project, if only they have lower cost solution. By the way, our new uC will be die-bounded Chip-On-Board One-Time- Programmable. Atmel is certainly capable of providing COG and OTP, but unwilling to do so.> > I agree this would be an issue if we needed binary compatibility, but > in practice we don't (the administrative requirements of changing > micros are massive and the cost of SWQA for a recompile-to-new-chip > operation is negligible).
Reply by ●July 17, 20082008-07-17
On 16/07/2008 larwe wrote: . .> Of course the problem turns out to be my fault (well, someone else in > my team originally, but my fault for not spotting it). Our circuit can > use the 169/329/649 but initial bring-up was done on the 169. Someone > forgot or ignored my advice to include avr.h and instead included > mega169.h >Yep, been there as well!! I use Imagecraft ICCAVR and there is a similar system in place of allowing the compiler to pick the correct header file.> MOST of the registers are the same between 169 and 32/649 but not all > of them. The PCINT bit assignments in particular are different! >Always a problem of an ever expanding product range. At least the series (eg m640, m1280, m2560, m5120??) match one another.> Also, it is not necessary to set the interrupt mask for PCIE1 in order > to see PCIF1 toggling.Ah, I must revisit my 2561 application and check. I found the PCIE0 bit had to be set, but I guess there may have been other reasons. -- John B
Reply by ●July 17, 20082008-07-17
On Jul 16, 7:23=A0pm, linnix <m...@linnix.info-for.us> wrote:> We are moving off the 169 purely for cost reason. =A0Our new uC (6502) > is 75% off, but it's difficult to port the hardware/software. =A0The 169Energy metering project? (That's what the mega169/329/649 were designed for). Are you using one of the 6502 variants e.g. from Sunplus, intended for toy use? Just out of interest, what's your cost target? We moved to the mega169 because it's significantly under $1.> By the way, our new uC will be die-bounded Chip-On-Board One-Time- > Programmable. =A0Atmel is certainly capable of providing COG and OTP, > but unwilling to do so.I can't see that an OTP version of the mega169 would really be cheaper - since it's not a standard part, there would be big NREs.
