Searching \ for '[PIC] Interrupt on Change Pin' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'Interrupt on Change Pin'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Interrupt on Change Pin'
2008\12\06@180959 by solarwind

picon face
So I tried to get this to work. I have a PICKIT 2 with a LPC demo
board. It's a PIC 16F690 with LEDs on PORT C and a push button switch
on PORT A. Here's my code:

http://pastebin.com/f5e47b284

I'm trying to turn the LEDs on or off every time I press the switch.
How do I do this?

--
..::[ solarwind ]::..

2008\12\06@201921 by solarwind

picon face
Still can't get this to work... I've looked at the datasheets, but
it's hard without an example.

--
..::[ solarwind ]::..

2008\12\07@120610 by Robert Kiely

picon face
2008/12/7 solarwind <spam_OUTx.solarwind.xTakeThisOuTspamgmail.com>:
> Still can't get this to work... I've looked at the datasheets, but
> it's hard without an example.

Just glanced at the code there and first thing off is you need enable
interrupts by setting the relevant bits in the INTCON register or an
interrupt will never be caught so your code will just get to the sleep
part and stay there. You also need to clear the relevant bit of the
ANSEL register to set the input to digital for the push button. Inputs
default to analogue on power-up. This can be seen on page 98 of the
datasheet in the A/D converter section. Above each bit it says R/W -
*1*, this mean it defaults to 1. Also you have no interrupt function
or ISR as it's called. When an interrupt does occur code execution
will jump to the interrupt vector and needs to be handled from there,
at a minimum you need to clear the interrupt flag to prevent an
infinite loop of interrupts. You say you looked at the datasheet but
it seems you didn't. Getting started can be hard but there are *so*
many examples out there on the net just ask Uncle Google and he'll
sort you out. Hope this help somewhat... oh and if you search the list
archives on the 23 Nov this year you will get my post about timer0
interrupts which should help shed some light and how interrupts work.

Rgds,
Rob

2008\12\07@171146 by solarwind

picon face
On Sun, Dec 7, 2008 at 12:05 PM, Robert Kiely <.....robert.kielyKILLspamspam@spam@gmail.com> wrote:
> Just glanced at the code there and first thing off is you need enable
> interrupts by setting the relevant bits in the INTCON register or an
> interrupt will never be caught so your code will just get to the sleep
> part and stay there. You also need to clear the relevant bit of the
> ANSEL register to set the input to digital for the push button. Inputs
> default to analogue on power-up. This can be seen on page 98 of the
> datasheet in the A/D converter section. Above each bit it says R/W -
> *1*, this mean it defaults to 1. Also you have no interrupt function
> or ISR as it's called. When an interrupt does occur code execution
> will jump to the interrupt vector and needs to be handled from there,
> at a minimum you need to clear the interrupt flag to prevent an
> infinite loop of interrupts. You say you looked at the datasheet but
> it seems you didn't. Getting started can be hard but there are *so*
> many examples out there on the net just ask Uncle Google and he'll
> sort you out. Hope this help somewhat... oh and if you search the list
> archives on the 23 Nov this year you will get my post about timer0
> interrupts which should help shed some light and how interrupts work.

I don't know how to do this. The data sheet doesn't explain anything either.

--
..::[ solarwind ]::..

2008\12\07@172844 by Jan-Erik Soderholm

face picon face
solarwind wrote:
{Quote hidden}

Exactly what part of the above does "this" refer to ??

> The data sheet doesn't explain anything either.

I'd say it does, in it's own way of explaining things...

2008\12\07@174309 by solarwind

picon face
I do not know how to cause an interrupt on a pin change.
--
..::[ solarwind ]::..

2008\12\07@175922 by Picbits Sales

flavicon
face


>I do not know how to cause an interrupt on a pin change.
> --
> ..::[ solarwind ]::..
> --

As I posted in my other reply - get a demo type board and get some code up
and running.

Don't try and run with PIC programming before you can walk or you'll end up
tripping over.

I use predominantly 18F1320 for development and they are good processors to
start with / learn on.

Taken from the 18F1320 datasheet on page 87 ish:

9.8 PORTB Interrupt-on-Change
An input change on PORTB<7:4> sets flag bit, RBIF
(INTCON<0>). The interrupt can be enabled/disabled
by setting/clearing enable bit, RBIE (INTCON<3>).
Interrupt priority for PORTB interrupt-on-change is
determined by the value contained in the interrupt
priority bit, RBIP (INTCON2<0>).



If the above confuddles you then definitely get yourself a demo/development
board and start from the beginning. Within a few hours of programming and
demo code you will pick up what the above it talking about.

Dom

2008\12\07@181017 by solarwind

picon face
All I need is a simple example how to get the interrupt on pin change
to work. There aren't many C examples for this.

--
..::[ solarwind ]::..

2008\12\07@182031 by Jinx

face picon face
> The data sheet doesn't explain anything either

Section 4.0 of the 16F690 manual is pretty clear, even if you're
starting from scratch. You should also look at the PICList I/O
and interrupt pages

http://www.piclist.com/techref/microchip/ios.htm

http://www.piclist.com/techref/microchip/ints.htm

and search the mail archives. The subject(s) have been covered many
many times

> There aren't many C examples for this

One you understand what is happening at the assembler level then you
can translate that to C

2008\12\07@182207 by Mark Rages

face picon face
On Sun, Dec 7, 2008 at 5:10 PM, solarwind <.....x.solarwind.xKILLspamspam.....gmail.com> wrote:
> All I need is a simple example how to get the interrupt on pin change
> to work. There aren't many C examples for this.
>

Do you understand how PIC interrupts work yet?  (not being snide here,
you're learning and that's cool.)

C example will be very similar to the assembler.  You'll want to learn
the "set register" and "set/clear a single bit" instructions, at
least, to understand the datasheet examples.   The actual interrupt
handler tends to vary by compiler; consult the manual for the compiler
you are using.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
EraseMEmarkragesspam_OUTspamTakeThisOuTmidwesttelecine.com

2008\12\07@182423 by Jan-Erik Soderholm

face picon face
solarwind wrote:
> All I need is a simple example how to get the interrupt on pin change
> to work. There aren't many C examples for this.
>

There are assembler examples in the datasheet.
Read them. Understand them. Then do the same in C.
Generaly speaking, C examples for such basic things are
not *that* usable, since there are many different C's.
Better then with a clear assembler example that you can
learn from and then implement in whatever C you're using.

And I'd bet that this is *not* all you need...

2008\12\07@182537 by Tamas Rudnai

face picon face
You do not need C example, you just need to learn the architecture. That is
described on the DS very well and no matter what language you use you have
to use pretty much in the same way as described there. This is not Windows
or Linux where you have API for everything, so you have to dig down to the
ground. The problem here is that we do not see the effort, and if you are
not willing to put it on why should we? If you send a C code that your wrote
this and still does not work, I am pretty sure someone can help you staright
away.

Tamas



On Sun, Dec 7, 2008 at 11:10 PM, solarwind <x.solarwind.xspamspam_OUTgmail.com> wrote:

> All I need is a simple example how to get the interrupt on pin change
> to work. There aren't many C examples for this.
>
> --
> ..::[ solarwind ]::..
> -

2008\12\07@182924 by William \Chops\ Westfield

face picon face

On Dec 7, 2008, at 2:43 PM, solarwind wrote:

> I do not know how to cause an interrupt on a pin change.

Dom says you have linux experience.  Do you understand how interrupts  
work in, say, a linux device driver, or on a legacy x86?

There's this general problem explaining things to people who have  
significant experience in some related area but nothing in the area in  
question.  If you word your answers too simply it comes across as  
insulting or isn't useful, but it's very easy to trip over a line into  
terms that just aren't part of the questioner's vocabulary (the whole  
"mil" thing being a fine example.)  In microcontrollers, this usually  
shows up when someone has a lot of electronics background but has  
never done software, or a lot of software background but has never  
done electronics.  I run into it frquently, trying to find books on  
windows programming for someone with a lot of experience in CLI and  
embedded software.

So in order to do something with interrupts in general, you need to:

1) Set up some code that is executed when the interrupt occurs (The  
"Interrupt Service Routine" or ISR)
2) configure the Interrupt Controller and/or interrupt vector table so  
that the desired interrupt or hardware signal will cause a jump/call  
to the ISR code.
3) configure the device that is supposed to generate the interrupt  
appropriately.
4) globally enable interrupts at the CPU level.

In your sample snippet of code, you did (3) without doing any of the  
other things.
It actually raised an interesting question for me (I've never used  
change pin interrupts): does IoC configured on a port cause the PIC to  
wake up from sleep even if higher levels of interrupt control aren't  
enabled?  It seems like it should, but then if it did I would think  
your code would work.

Some CPUs return to sleep mode when they're done executing the ISR, if  
they were in sleep mode when the interrupt occurred.  I don't recall  
whether the PIC is one of them.  Sometimes this is a consequence of  
sleep status being part of the "status register" that an interrupt  
saves automatically.  If so, part of the ISR has to be explicitly  
change the status register or sleep status before returning.

BillW

2008\12\07@185700 by olin piclist

face picon face
solarwind wrote:
{Quote hidden}

Do what precicely?  There are many possible "this" in the paragraph above.

> The data sheet doesn't explain anything either.

Of course it does.  Microchip documentation of their PICs is well written
and complete.  If you don't understand something specific then ask, but
don't try blaming the data sheet.  All that does is undermine your
credibility, not its.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\07@185742 by olin piclist

face picon face
solarwind wrote:
> I do not know how to cause an interrupt on a pin change.

So go look it up.  Why are you telling us this?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\07@191211 by olin piclist

face picon face
William Chops" Westfield" wrote:
> does IoC configured on a port cause the PIC to
> wake up from sleep even if higher levels of interrupt control aren't
> enabled?

Yes.

> Some CPUs return to sleep mode when they're done executing the ISR,

Maybe, but not PICs.  PICs have no notion of being "in" a interrupt.  A
interrupt is simply a event that occurs when its requisite conditions have
been met.  If interrupts are globally enabled, the specific interrupt is
enabled, peripheral interrupts are enabled if this is a "peripheral"
interrupt, and the interrupt condition becomes true, then the PIC will
execute a call to the interrupt vector while at the same time disabling
interrupts.  That's all.  If you happen to have code at the interrupt vector
that services the interrupt and then returns to the interrupted code, that's
your business.  You might call that code a Interrupt Service Routine or ISR,
but the PIC doesn't require nor expect nor check for that.

In one PIC 16 project I used the INT interrupt as a externally forced GOTO
4.  Yes, this caused the stack to overflow and wrap around, but I didn't
care since the code never tried to return to the address pushed onto the
call stack by the interrupt.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\07@193018 by solarwind

picon face
On Sun, Dec 7, 2008 at 6:29 PM, William Chops Westfield <@spam@westfwKILLspamspammac.com> wrote:
{Quote hidden}

> -

2008\12\07@194633 by Andre Abelian

flavicon
face
Solarwind,

Your code is incomplete. You need to enable porta on change interrupt,
global interrupt,
disable analog, comparator.



Using ccs compiler


void main()
{

  setup_adc_ports(NO_ANALOGS|VSS_VDD);
  setup_adc(ADC_OFF);
  setup_spi(SPI_SS_DISABLED);
  setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
  setup_timer_1(T1_DISABLED);
  setup_timer_2(T2_DISABLED,0,1);
  setup_comparator(NC_NC_NC_NC);// This device COMP currently not supported
by the PICWizard
  enable_interrupts(INT_RA);
  enable_interrupts(GLOBAL);

  while(true)
      {
                  SLEEP();
      }

}



#int_RA               // porta change interrupt will jump here
void  RA_isr(void)
{
//
// put your code here to turn on off and after 10 seconds go to sleep.
}


















{Original Message removed}

2008\12\07@200022 by Jinx

face picon face
> It is difficult to learn when all you get when you ask a question
> is GOOGLE IT NOOB

(Speaking in general, not to you specifically)

But not impossible. Many of us started with micros and electronics
before Google was even born. Googling is not the be all and end all
of learning how to do something, but it seems intrinsic to the modern
way of "researching". I'd go out on a limb and suggest that the Google
generation has a lot of their thinking and figuring out done for them
and those skills are being lost

Learning PICs properly is like anything else. Start at the bottom and
work up. Even if it takes all day to discover for yourself how PortA
works surely that MUST be more valuable than a Copy/Paste which
you don't understand

2008\12\07@201815 by Xiaofan Chen

face picon face
On Mon, Dec 8, 2008 at 7:10 AM, solarwind <KILLspamx.solarwind.xKILLspamspamgmail.com> wrote:
> All I need is a simple example how to get the interrupt on pin change
> to work. There aren't many C examples for this.
>

Many people are saying this in the Microchip forum as well.
All they need is just an example. And they are busy, no
time to read the datasheets, no time to go through the ABCs
of electronics, etc, since their projects are due next week.

On the other hand, you are young, you got time,
you are eager to learn, that is great! So stay back,
get a development board, learning from ABCs. You got
good background in programming, that is an advantage.

Nice tips:
http://forum.microchip.com/tm.aspx?m=372119&mpage=1&key=&#372126

This may help as well.
http://forum.microchip.com/tm.aspx?m=358912

Xiaofan

2008\12\07@202120 by Bob Ammerman

picon face
> On Sun, Dec 7, 2008 at 5:10 PM, solarwind <RemoveMEx.solarwind.xTakeThisOuTspamgmail.com> wrote:
>> All I need is a simple example how to get the interrupt on pin change
>> to work. There aren't many C examples for this.
>>
>
> Do you understand how PIC interrupts work yet?  (not being snide here,
> you're learning and that's cool.)
>
> C example will be very similar to the assembler.  You'll want to learn
> the "set register" and "set/clear a single bit" instructions, at
> least, to understand the datasheet examples.   The actual interrupt
> handler tends to vary by compiler; consult the manual for the compiler
> you are using.

Again, you do *not* actually need to use an interrupt handler, nor globally
enable interrupts to get interrupt-on-change to work to wake up from sleep.

As Olin noted, an enabled interrupt-on-change causes an interrupt
*condition*, but it only becomes an actual interrupt if interrupts are
globally enabled.

So, you want to do the following:

1: Make sure you properly initialize your inputs as digital as opposed to
analog (often controlled by a port called ANSEL, but this varies amoung
several different PICs).

2: Make sure your inputs are set up as inputs rather than outputs (this is
the default condition, check out TRIS registers for this).

3: Make sure that interrupts are globally disabled (often a flag bit called
GIE). This is the default condition.

4: Make sure the interrupt-on-change interrupt is enabled (another flag
bit).

Now a SLEEP should be terminated when the input bit changes, but no
interrupt handler is needed.


Some baby steps:

I would start by trying to write a program that just copied the state of an
input bit to an output bit. This makes sure you have inputs set up as inputs
and outputs as outputs. Then I would try to add the
interrupt-on-change/wakeup from SLEEP logic.

-- Bob Ammerman
RAm Systems


2008\12\07@202355 by solarwind

picon face
On Sun, Dec 7, 2008 at 8:17 PM, Xiaofan Chen <spamBeGonexiaofancspamBeGonespamgmail.com> wrote:
>
> Many people are saying this in the Microchip forum as well.
> All they need is just an example. And they are busy, no
> time to read the datasheets, no time to go through the ABCs
> of electronics, etc, since their projects are due next week.
>
> On the other hand, you are young, you got time,
> you are eager to learn, that is great! So stay back,
> get a development board, learning from ABCs. You got
> good background in programming, that is an advantage.
>
> Nice tips:
> http://forum.microchip.com/tm.aspx?m=372119&mpage=1&key=&#372126
>
> This may help as well.
> http://forum.microchip.com/tm.aspx?m=358912
>
> Xiaofan

I've been following your blog for the past year on the PICKIT2 for
Linux. Any update on that for the latest PICKIT2 firmware?

--
..::[ solarwind ]::..

2008\12\07@202616 by solarwind

picon face
On Sun, Dec 7, 2008 at 8:20 PM, Bob Ammerman <TakeThisOuTrammermanEraseMEspamspam_OUTverizon.net> wrote:
{Quote hidden}

Very helpful, thank you. Attempting now.



--
..::[ solarwind ]::..

2008\12\07@204527 by Bob Ammerman

picon face
Added step 1A to the following:

>> So, you want to do the following:
>>
>> 1: Make sure you properly initialize your inputs as digital as opposed to
>> analog (often controlled by a port called ANSEL, but this varies amoung
>> several different PICs).

1A: You may also have to disable the built-in comparator(s) on some PICs.

{Quote hidden}

[notice the mixed "TOP POSTING" and "MIDDLE POSTING", hope nobody flames me
on this :-)


-- Bob Ammerman
RAm Systems

2008\12\07@210155 by solarwind

picon face
On Sun, Dec 7, 2008 at 8:45 PM, Bob Ammerman <RemoveMErammermanspamTakeThisOuTverizon.net> wrote:
{Quote hidden}

Ok, I tried it with step 1A added. Still no luck. I honestly tried and
read the datasheet. Here's my code. I don't know what I'm doing wrong.

http://pastebin.com/f286b7121


--
..::[ solarwind ]::..

2008\12\07@210309 by solarwind

picon face
And yes, I got the input pins working, it's just the interrupt
condition isn't working.

2008\12\07@211732 by Tamas Rudnai

face picon face
Solarwind, I tell you a secret - do not tell anyone here in the list ;-)

I was NOT borne with the knowledge of PIC microcontrollers.

What I have done is to look for PIC tutorials and books on the net. I am
pretty sure you did the same with C and linux, you read so many books on the
subject. So here are two important links you may start:

www.piclist.com/techref/piclist/begin.htm
http://www.mikroe.com/en/books/

The first one gives you many starting up points, while the second one is a
free library, you can read those books free of charge.

Hope it helps
Tamas



On Mon, Dec 8, 2008 at 1:26 AM, solarwind <x.solarwind.xEraseMEspam.....gmail.com> wrote:

{Quote hidden}

> -

2008\12\07@212729 by solarwind

picon face
On Sun, Dec 7, 2008 at 9:17 PM, Tamas Rudnai <RemoveMEtamas.rudnaiEraseMEspamEraseMEgmail.com> wrote:
> Solarwind, I tell you a secret - do not tell anyone here in the list ;-)
>
> I was NOT borne with the knowledge of PIC microcontrollers.

OMGOSH! I wont tell anyone that you were borne with the knowledge of
PIC microcontrollers! Thanks for trusting me with your secret!

--
..::[ solarwind ]::..

2008\12\07@221122 by William \Chops\ Westfield

face picon face
On Dec 7, 2008, at 6:01 PM, solarwind wrote:
>
> http://pastebin.com/f286b7121


        GIE = 0;                //(INTCON[7]) Disable global interrupts
        RABIE = 1;              //(INTCON[3]) Enable PORTA/PORTB  
change interrupt
        RABIF = 0;              //(INTCON[0]) Change interrupt flag  
bit - clear
        C1ON = 0;               //Disable comparators 1 and 2
        C2ON = 0;

Hmm.  Those are sort of interesting, since the left-side symbols are  
single bits.  Does HTC actually let you do that sort of thing?  I  
mean, it's within what the PIC architecture allows via BSD/BCF  
instructions, and it's within the "extensions" I've seen for some C  
compilers on microcontrollers, but it's clearly not standard C, and  
it's something I'd be suspicious of without seeing it specifically  
used in an example in the manual, or without carefully looking at the  
include files and/or generated code...  I also might tend to avoid  
this syntax as being less portable; it depends on how badly the code  
generator does with more standard C constructs like:
       INTCON |= INTCON_RABIE;
or
       INTCON.RABIE = 1;

BillW

2008\12\07@222756 by solarwind

picon face
On Sun, Dec 7, 2008 at 10:09 PM, William Chops Westfield <RemoveMEwestfwspam_OUTspamKILLspammac.com> wrote:
{Quote hidden}

If my code logic is correct, the therein lie the problem. But I don't
know if my code logic is correct in the first place...


--
..::[ solarwind ]::..

2008\12\07@231022 by Xiaofan Chen

face picon face
On Mon, Dec 8, 2008 at 9:23 AM, solarwind <RemoveMEx.solarwind.xTakeThisOuTspamspamgmail.com> wrote:
> I've been following your blog for the past year on the PICKIT2 for
> Linux. Any update on that for the latest PICKIT2 firmware?

The latest version of pk2cmd works under Windows, Linux
and Mac OS X and support most of the PIC12F/16F/18F,
PIC24/dsPIC30/dsPIC33 and PIC32 Flash based MCUs.
Download: http://www.microchip.com/pickit2



Xiaofan

2008\12\07@233108 by solarwind

picon face
On Sun, Dec 7, 2008 at 11:10 PM, Xiaofan Chen <EraseMExiaofancspamspamspamBeGonegmail.com> wrote:
> The latest version of pk2cmd works under Windows, Linux
> and Mac OS X and support most of the PIC12F/16F/18F,
> PIC24/dsPIC30/dsPIC33 and PIC32 Flash based MCUs.
> Download: http://www.microchip.com/pickit2

Wow! Didn't know that existed! And they have the source code too!?!?
Since when??

--
..::[ solarwind ]::..

2008\12\08@000813 by John Temples

flavicon
face
On Sun, 7 Dec 2008, William \"Chops\" Westfield wrote:

> On Dec 7, 2008, at 6:01 PM, solarwind wrote:
>
>         GIE = 0;                //(INTCON[7]) Disable global interrupts
>         RABIE = 1;              //(INTCON[3]) Enable PORTA/PORTB
> change interrupt
>         RABIF = 0;              //(INTCON[0]) Change interrupt flag
> bit - clear
>         C1ON = 0;               //Disable comparators 1 and 2
>         C2ON = 0;
>
> Hmm.  Those are sort of interesting, since the left-side symbols are
> single bits.  Does HTC actually let you do that sort of thing?

Yes.

> I
> mean, it's within what the PIC architecture allows via BSD/BCF
> instructions, and it's within the "extensions" I've seen for some C
> compilers on microcontrollers, but it's clearly not standard C,

Sure it is.  Those symbols are defined by the implementation by
including implementation-specific header files.  What happens under
the hood is of no concern to the programmer.  It's really no different
than, say, the standard offsetof() macro. Its implementation details
are of no concern to the programmer and it undoubtedly uses
non-portable, and possibly non-standard constructs to get its job
done.

> I also might tend to avoid
> this syntax as being less portable; it depends on how badly the code
> generator does with more standard C constructs like:
>        INTCON |= INTCON_RABIE;
> or
>        INTCON.RABIE = 1;

There is no "portable" way to access a PIC's internal registers.  You
have to rely on the implementation to define INTCON.  Both the
examples you cite are problematic: the first is error prone since
there's nothing to ensure the register matches bit mask, and both
require you to remember which register RABIE is in.

Hi-Tech's approach gives optimal code for something like "RABIE = 1",
with the helpful side effects of not being error-prone and not
requiring you to remember which register RABIE is in.

--
John W. Temples, III

2008\12\08@020951 by Wouter van Ooijen

face picon face
Jinx wrote:
>> It is difficult to learn when all you get when you ask a question
>> is GOOGLE IT NOOB

Why? It is easy to google, and easy to show that you did. Add a little
thinking of your own, show it, learn the (universal) rules for asking
questions, and you are in for a flood of useful answers.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\12\08@021123 by Wouter van Ooijen

face picon face
>> (snip > a screenful of lines)
>> -- Bob Ammerman
>
> Very helpful, thank you. Attempting now.

And what about trimming the message you reply to?

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\12\08@024303 by Jinx

face picon face
> Jinx wrote:
> >> It is difficult to learn when all you get when you ask a question
> >> is GOOGLE IT NOOB
>
> Why? It is easy to google, and easy to show that you did. Add a little
> thinking of your own, show it, learn the (universal) rules for asking
> questions, and you are in for a flood of useful answers

Wouter, please, I didn't write the above. In fact I wrote a paragraph
about why Google is not necessarily the answer to all life's problems

2008\12\08@031546 by apptech

face
flavicon
face
>> So in order to do something with interrupts in general, you need to:
>>
>> 1) Set up some code that is executed when the interrupt occurs (The
...
>> 2) configure the Interrupt Controller and/or interrupt vector table so
...
>> 3) configure the device that is supposed to generate the interrupt
...
>> 4) globally enable interrupts at the CPU level.

>> In your sample snippet of code, you did (3) without doing any of the
>> other things.

BUT, if I'm skim-following all this correctly, in THIS case that is all he
was trying to do.

Acting on advice from others he was trying to cause an interupt triggering
event without triggering an actual interupt. The reason for this bizarre
sounding feat is that the interupt on change feature will wake the PIC from
sleep mode in order to trigger the interupt that is required. In this case,
there isn't one - the waking was the object. Once it has done so, the IRQs
are found to be disabled, there is no IRQ code established and no vector, so
it just continues from where it was last, which was the place where it put
itself to sleep to await the keypress that has now woken it.

ie in this case step 3 is all he wants to do and he can't make it work.

BUT despite having by now put a significant amount of effort and time into
this and having given it a good shot there are still copious numbers of
people running around telling him to read the manual / data sheet /
googlebase ... but nobody who has as yet said " ... well, actually, yes,
that caused me vast amounts of grief too, and it turned out to be extremely
easy after the event, but until I found out how, it was inscrutable. Here's
what I did and found ..."

Alas I am not able to show and tell in this case, else I would.
He's got as far as writing C code to do the bit setting that's required by
the data sheet, googlestuff and 3 acts of parliament, and he hasn't yet got
it working. What other hoops are the watchers going to roll out for jumping
through before the arcane mysteries are revealed ?

NB: No complaint with those who have offered as good practical advice along
the way while also doling out some apple pie and motherhood advice.
Admonition and hard data can almost be tolerated. Admonition plus holier
than thou is (just a tiny) bit harder to take.


>> It actually raised an interesting question for me (I've never used
>> change pin interrupts): does IoC configured on a port cause the PIC to
>> wake up from sleep even if higher levels of interrupt control aren't
>> enabled?  It seems like it should, but then if it did I would think
>> your code would work.

Yes. That's what he's been told. But apparently it doesn't.


         Russell


2008\12\08@033008 by apptech

face
flavicon
face
This MAY be useful
In German.

       http://www.mikrocontroller.net/topic/73742

As may this

       http://www.innovexpo.itee.uq.edu.au/2001/projects/s369495/thesis.pdf




           Russell



2008\12\08@041112 by Nicola Perotto

picon face

solarwind wrote:
> That being said, almost all or 100% of the stuff I've asked can be
> found on google, but the thing about google is you have to KNOW what
> you're wanting to find and KNOW the right question to ask. I DON'T
> know the right question. That's where other humans come in - they
> interpret my questions and either tell me what the right question is,
> or simply paste some links or even explain the solution to me. This I
> am grateful for. It's not that I'm too lazy to google it, It's just
> that google doesn't always give you the right answers to your question
> and sometimes you don't know the right question to ask.
>
> Please understand, I'm not doing this on purpose. I'm just trying to learn.
>
>  
This is true and google doesn't works so well: too many results not
really concerning the question!

But a point you forgot is: before starting a new "argument" you need to
document yourself!
You ever need a base knowledge and you can't go ahead without it...
Maybe you are missing this!

           Nic


2008\12\08@045015 by William \Chops\ Westfield

face picon face

On Dec 8, 2008, at 12:15 AM, apptech wrote:

> BUT despite having by now put a significant amount of effort and  
> time into
> this and having given it a good shot there are still copious numbers  
> of
> people running around telling him to read the manual / data sheet /
> googlebase ... but nobody who has as yet said " ... well, actually,  
> yes,
> that caused me vast amounts of grief too, and it turned out to be  
> extremely
> easy after the event, but until I found out how, it was inscrutable.  
> Here's
> what I did and found ..."

I agree.  This is now an "interesting problem."  Unfortunately, I  
haven't live hardware to experiment with.  However, I found an  
interesting bit in the data sheet; section 4.2.3 (page 60):
   For enabled IoC pins, the values are compared with the old value
   latched on the last read of PORTA.
And it goes on with other verbiage that implies to me that perhaps one  
has to actually READ from the port immediately before clearing RABIF...

Try that?

BillW


2008\12\08@072334 by Alan B. Pearce

face picon face
> Hmm.  Those are sort of interesting, since the left-side symbols are
> single bits.  Does HTC actually let you do that sort of thing?

The Microchip C30 compiler also allows this, in fact it allows you to assign
a value to a bit field that is several bits wide, e.g. a 3 bit wide field in
a register can have

  ADC_Channel = 5;

2008\12\08@073606 by Alan B. Pearce

face picon face
> Hmm.  Those are sort of interesting, since the left-side symbols are
> single bits.  Does HTC actually let you do that sort of thing?

The Microchip C30 compiler also allows this, in fact it allows you to assign
a value to a bit field that is several bits wide, e.g. a 3 bit wide field in
a register can have

  ADC_Channel = 5;

2008\12\08@082338 by olin piclist

face picon face
apptech wrote:
> but nobody who has as yet said " ...
> well, actually, yes, that caused me vast amounts of grief too, and it
> turned out to be extremely easy after the event, but until I found
> out how, it was inscrutable. Here's what I did and found ..."

I honestly don't remember a problem with this stuff.  As with the vast
majority of PIC things, I recall this "just worked".  I did however sit down
and read the datasheet fully before even attempting to write the first line
of PIC code.

As for why his C code doesn't work, I don't care.  I'm not interested in
helping anyone with C.  That's my call, so please spare me any rants about C
versus ASM, etc etc.  I think everyone should start out with assembler, so
I'm not going to help enable a alternative.  I also don't want to spend time
trying to figure out what's wrong when there is a unknown (to me) compiler
between the code and the PIC.  No thanks.  Again, this is my personal choice
of how I'm willing to provide free help, so spare me the complaints.

Now if he respected the list by proper replying and trimming, posted a short
MPASM program in the message or in a attachment (no, I'm not going to chase
down some link on a web site with lots of annoying popups, spam, ads, and
who knows what else), and used a 18F and clearly said which one, I'd be
inclined to look at his code more seriously.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\08@134851 by solarwind

picon face
On Mon, Dec 8, 2008 at 8:23 AM, Olin Lathrop <RemoveMEolin_piclistKILLspamspamembedinc.com> wrote:
>(no, I'm not going to chase
> down some link on a web site with lots of annoying popups, spam, ads, and
> who knows what else), and used a 18F and clearly said which one, I'd be
> inclined to look at his code more seriously.

There is no link to chase, it has been clearly provided in the post.
Also, I thought it would be proper to post links in a pastebin rather
than put it in the mailing list itself.


--
..::[ solarwind ]::..

2008\12\08@140602 by olin piclist

face picon face
solarwind wrote:
> There is no link to chase, it has been clearly provided in the post.

That's what I meant.  I don't really want to click thru to some web page
that has annoying popups, ads, viruses, and who knows what else.  And then
if I want to comment on a few lines, I can't just do a reply.  No thanks.

> Also, I thought it would be proper to post links in a pastebin rather
> than put it in the mailing list itself.

Maybe some people prefer that.  You definitely don't want to attach large
chunks of code to a list message.  However, you shouldn't be posting large
chunks of code in the first place.  The code should be distilled down to the
minimum to cause the symptom.

Short chunks (a few 10s of lines max) can be included right in the message
so that it doesn't have to be chased down.  Of course, always make sure that
it's neatly formatted, contains no tab characters, isn't wrapped, contains
meaninful comments, and other ordinary common sense.  The best answer is
probably attaching the code as a plain text file, but don't let that be a
excuse for not paring it down to the essentials.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\08@140717 by Picbits Sales

flavicon
face
> There is no link to chase, it has been clearly provided in the post.
> Also, I thought it would be proper to post links in a pastebin rather
> than put it in the mailing list itself.
>
>
> --
> ..::[ solarwind ]::..
> --

Posting code is encouraged in this list (unlike the Ubuntu forums). The list
is archived both locally and searched by Google (after a fashion) and
posting a link to code may seem like a good idea to save bandwidth etc but
if the site that the code is hosted on is down or gets closed then the whole
thread is fairly pointless as the code is not accessible any more.

I'm not having a go in any way, shape or form as I know posting long code on
the Ubuntu forums tends to get you slapped but bear in mind this is a
mailing list and people don't always want to be clicking on external links.

Dom

2008\12\08@142123 by solarwind

picon face
Here's my code for anyone who hasn't clicked my link to the pastebin:

#include <htc.h>

typedef unsigned char byte;

__CONFIG(MCLRDIS & FCMDIS & BORDIS & PWRTDIS & WDTDIS & UNPROTECT &
IESODIS & INTIO);

void hibernate() {        
#asm
       sleep
#endasm
}

void main() {        
       
       TRISA = 0xFF;        //Port A is input
       TRISC = 0x00;        //Port C is output

       ANSEL = 0x00;        //Digital inputs
       WPUA = 0xFF;        //Pull up on PORTA
       IOCA = 0xFF;        //Interrupt On Change A - all enabled
       GIE = 0;                //(INTCON[7]) Disable global interrupts
       RABIE = 1;                //(INTCON[3]) Enable PORTA/PORTB change interrupt
       
       RABIF = 0;                //(INTCON[0]) Change interrupt flag bit - clear
       
       C1ON = 0;                //Disable comparators 1 and 2
       C2ON = 0;
       
       
       for(;;) {
               PORTC = 0xFF;        //Set PORTC high.
               hibernate();        //Sleep, PORTC is still high.
               PORTC = 0x00;        /*If the interrupt on change pin works,
                                                 PORTC should be 0x00 when I push the button
                                                 but it does NOT work.*/                
               hibernate();        //Sleep again; cycle continues...
       }
}

2008\12\10@072124 by William \Chops\ Westfield

face picon face

On Dec 8, 2008, at 1:49 AM, William Chops Westfield wrote:

> And it goes on with other verbiage that implies to me that perhaps one
> has to actually READ from the port immediately before clearing  
> RABIF...
>
> Try that?

Any update on this?

BillW

2008\12\10@085922 by Jan van Wijk

flavicon
face
On Wed, 10 Dec 2008 04:18:26 -0800, William \"Chops\" Westfield wrote:

>> And it goes on with other verbiage that implies to me that perhaps one
>> has to actually READ from the port immediately before clearing  
>> RABIF...
>>
>> Try that?
>
>Any update on this?

Haven't seen any reply on the list about this sofar ...

However, from using this feature with a PIC18F4520 I know that
reading the port is mandatory for reliable operation.
Actually clearing the interrupt flag may not be :-).

if you check the port-schematics in de the datasheet that
includes the Interrupt-On-Change logic, you will see that
for port-bits where the feature is enabled its value is compared
to a 'previous-read-value' latch, and the result for all port-bits
is ORed into the 'interrupt-on-change' interrupt flag.

So without reading, the latches will never change value.
Just clearing the flag has no effect, it will be set immediately
again as long as the actual pin values do not match the latches.

Regards, JvW

Jan van Wijk, author of DFSee; http://www.dfsee.com
-------------------------------------------------------------------------------

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...