Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

2106 and 2138 interrupt and IOPIN

2106 and 2138 interrupt and IOPIN

2006-02-04 by charlesgrenz

Hello group,

  Have a strange problem. The following code works perfectly on a LPC2106.

    if (((T1IR & T1IR_MR2INT) != 0) || (T1MR2 < T1TC)) // Timer 1,
Match 2 - 500ms LED Delay <<<<<<<<<<<<<<<<<<<<<<
       {
        T1MR2 = T1TC + DEFAULT_TMR1_MR2_TIMEBASE; // Count up to this
value. Generate 2 Hz interrupt.
                    if ((IOPIN & POWER_LED) == 0)
                       {
                        IOSET = POWER_LED;
                       }
                    else
                       {
                        IOCLR = POWER_LED;
                       }
       }

=================================================
 I then used the same software on a LPC2138 and it only runs once and
then never again.

    if (((T1IR & T1IR_MR2INT) != 0) || (T1MR2 < T1TC)) // Timer 1,
Match 2 - 500ms LED Delay <<<<<<<<<<<<<<<<<<<<<<
       {
        T1MR2 = T1TC + DEFAULT_TMR1_MR2_TIMEBASE; // Count up to this
value. Generate 2 Hz interrupt.
                    if ((IO0PIN & POWER_LED) == 0)
                       {
                        IO0SET = POWER_LED;
                       }
                    else
                       {
                        IO0CLR = POWER_LED;
                       }
       }
========================================================
  I then changed the routine to the following and found it worked
perfectly on the LPC2138.

    if (((T1IR & T1IR_MR2INT) != 0) || (T1MR2 < T1TC)) // Timer 1,
Match 2 - 500ms LED Delay <<<<<<<<<<<<<<<<<<<<<<
       {
        T1MR2 = T1TC + DEFAULT_TMR1_MR2_TIMEBASE; // Count up to this
value. Generate 2 Hz interrupt.
                    if (led_50 == TRUE)
                       {
                        IO0SET = POWER_LED;
                        led_50 = FALSE;
                       }
                    else
                       {
                        IO0CLR = POWER_LED;
                        led_50 = TRUE;
                       }
       }

  It almost looks like that the IO0PIN can not be read in an interrupt
for the 2183 but it is ok on the 2106. Anyone else seen this behavior
before??

PS I checked the assembly code and all looked perfect!

regards,
Charles

Re: [lpc2000] 2106 and 2138 interrupt and IOPIN

2006-02-05 by Tom Walsh

charlesgrenz wrote:

>Hello group,
>
>  Have a strange problem. The following code works perfectly on a LPC2106.
>
>    if (((T1IR & T1IR_MR2INT) != 0) || (T1MR2 < T1TC)) // Timer 1,
>Match 2 - 500ms LED Delay <<<<<<<<<<<<<<<<<<<<<<
>       {
>        T1MR2 = T1TC + DEFAULT_TMR1_MR2_TIMEBASE; // Count up to this
>value. Generate 2 Hz interrupt.
>                    if ((IOPIN & POWER_LED) == 0)
>                       {
>                        IOSET = POWER_LED;
>                       }
>                    else
>                       {
>                        IOCLR = POWER_LED;
>                       }
>       }
>
>  
>
FWIW, as a matter of programming style, I always have the pin reflect a 
variable state.  I don't have any reason, other than the pin port 
structures of some processors read the value of the pin Latch as opposed 
to the actual value at the pin.  IIRC, 8051 was like this.

Having said that, never assume.  Are you measuring the actual voltage at 
that pin?  Are you assuming that since the LED is on / off that the pin 
voltage would be considered a 0 or 1 state?

OH!  and another thing, there may be something where the pin is 
programmed to an output state and there is no way to read the actual 
value of the pin / pin latch (always returns a 0 or 1).

Like I said, what you are doing is a bit unusual as far as common 
practice is concerned.


TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: 2106 and 2138 interrupt and IOPIN

2006-02-06 by charlesgrenz

Hi Tom,

  Thanks for the reminder! I always used a port image for outputs, but
since it worked fine on the LPC2106, I assumed .......... Oh well.

regards,
Charles

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
>
> charlesgrenz wrote:
> 
> >Hello group,
> >
> >  Have a strange problem. The following code works perfectly on a
LPC2106.
> >
> >    if (((T1IR & T1IR_MR2INT) != 0) || (T1MR2 < T1TC)) // Timer 1,
> >Match 2 - 500ms LED Delay <<<<<<<<<<<<<<<<<<<<<<
> >       {
> >        T1MR2 = T1TC + DEFAULT_TMR1_MR2_TIMEBASE; // Count up to this
> >value. Generate 2 Hz interrupt.
> >                    if ((IOPIN & POWER_LED) == 0)
> >                       {
> >                        IOSET = POWER_LED;
> >                       }
> >                    else
> >                       {
> >                        IOCLR = POWER_LED;
> >                       }
> >       }
> >
> >  
> >
> FWIW, as a matter of programming style, I always have the pin reflect a 
> variable state.  I don't have any reason, other than the pin port 
> structures of some processors read the value of the pin Latch as
opposed 
> to the actual value at the pin.  IIRC, 8051 was like this.
> 
> Having said that, never assume.  Are you measuring the actual
voltage at 
Show quoted textHide quoted text
> that pin?  Are you assuming that since the LED is on / off that the pin 
> voltage would be considered a 0 or 1 state?
> 
> OH!  and another thing, there may be something where the pin is 
> programmed to an output state and there is no way to read the actual 
> value of the pin / pin latch (always returns a 0 or 1).
> 
> Like I said, what you are doing is a bit unusual as far as common 
> practice is concerned.
> 
> 
> TomW
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.