Hello everyone, does anyone have any idea on how to do a interrupt driven
mode of receiving
rather than polling (constantly waiting for incoming data and looping back)
using the PICs?
Thanks
You Can use the Uart irq for a serial reception.
If the data hasn't serial format, use the irq extern. For example
pin RB0 in PIC16CXX o PIC16F87XX
BS. Francisco Armenta Lopez
Project Manager
Briones Sistemas de Pesaje, S.A. de C.V.
Phone: 522-2311980
Fax: 522-2489627
ZIP: 72060
Puebla, Puebla. Mexico
-----Mensaje original-----
De: pic microcontroller discussion list
[.....PICLISTKILLspam@spam@MITVMA.MIT.EDU]En nombre de JungWhan
Enviado el: Jueves, 16 de Noviembre de 2000 08:24 a.m.
Para: PICLISTKILLspamMITVMA.MIT.EDU
Asunto: [PIC] Interrupt
Hello everyone, does anyone have any idea on how to do a interrupt driven
mode of receiving
rather than polling (constantly waiting for incoming data and looping back)
using the PICs?
Thanks
Thanks very much to all for the array size stuff, I'm using the bit array to
store my potentials and wall data, so cutting down on memory, but will put in
my project that another type of chip would be more appropriate.
For the current pic i'm going to use the dead simple 'follow-the-left-hand-
wall' technique. I've written the basic code, but at the moment its a case
of "move 1 square, stop. read sensors. go again", so I'm trying to setup an
interrupt on RB0 so that when the Left-Hand Sensor changes, I can jump to the
decision code.
As yet my program runs and compiles but doesn't do anything on a change to B0.
I've kind of pieced the code I need together from the PICCLITE manual and other
tutorials, and can see there's stuff about option registers, but nothing I've
tried has made a difference. Code to try out the interrupt is below.
void interrupt sensor()
{
int i;
PORTA=255;
for (i=40;i--;) continue;
}
main()
{
TRISA=0;
TRISB=3;
//OPTION=192; tried fiddling with this code but I'm just
//INTCON|=(1<<GIE); guessing really...
for (;;)
{
PORTA=0;
}
}
Simple stuff no doubt, but any ideas??? cheers,
john
Thanks very much to all for the array size stuff, I'm using the bit array to
store my potentials and wall data, so cutting down on memory, but will put in
my project that another type of chip would be more appropriate.
<using HiTech PICC-LITE under MPLAB for a PIC16F84A>
For the current pic i'm going to use the dead simple 'follow-the-left-hand-
wall' technique. I've written the basic code, but at the moment its a case
of "move 1 square, stop. read sensors. go again", so I'm trying to setup an
interrupt on RB0 so that when the Left-Hand Sensor changes, I can jump to the
decision code.
As yet my program runs and compiles but doesn't do anything on a change to B0.
I've kind of pieced the code I need together from the PICCLITE manual and other
tutorials, and can see there's stuff about option registers, but nothing I've
tried has made a difference. Code to try out the interrupt is below.
void interrupt sensor()
{
int i;
PORTA=255;
for (i=40;i--;) continue;
}
main()
{
TRISA=0;
TRISB=3;
//OPTION=192; tried fiddling with this code but I'm just
//INTCON|=(1<<GIE); guessing really...
for (;;)
{
PORTA=0;
}
}
Simple stuff no doubt, but any ideas??? cheers,
john
I know this issue has passed the revue a dozen times already, however, I
can't find any usefull things from the archives.
I have two motion sensors which put out two PWM signals each. I want to
measure the length of those four PWM signals (this is the action
anglular data of the sensors). Now, with the PIC16F874 I use, I have two
options: use a capture register or use interrupt on change. Problem with
the capture is, I only have two. From the IOC ports RB7:RB4, there are
four. However, I remember a lot of words of caution when using the IOC
feature. If I have those four digital input signals only on those ports,
can I use this safely? And what were the all-too-familiar problems with
Interrupt on Change again?
I use interrupts on change in combination with 2
rotary encoders. PB7 together with PB0 and PB6 with
PB1.
No prob's at all. Use the internal pull-ups. Enable
the Interupt on Change and Global Interupt.
When an interupt occurs you have to check whole portb.
>
>
> I know this issue has passed the revue a dozen times
> already, however, I
> can't find any usefull things from the archives.
>
> I have two motion sensors which put out two PWM
> signals each. I want to
> measure the length of those four PWM signals (this
> is the action
> anglular data of the sensors). Now, with the
> PIC16F874 I use, I have two
> options: use a capture register or use interrupt on
> change. Problem with
> the capture is, I only have two. From the IOC ports
> RB7:RB4, there are
> four. However, I remember a lot of words of caution
> when using the IOC
> feature. If I have those four digital input signals
> only on those ports,
> can I use this safely? And what were the
> all-too-familiar problems with
> Interrupt on Change again?
>
>
> Best Regards,
>
> Claudio
>
> --
> http://www.piclist.com#nomail Going offline? Don't
> AutoReply us!
> email KILLspamlistservKILLspammitvma.mit.edu with SET PICList
> DIGEST in the body
>
>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts http://uk.my.yahoo.com
> Hello all,
> I know this issue has passed the revue a dozen times already, however, I
> can't find any usefull things from the archives.
> I have two motion sensors which put out two PWM signals each. I want to
> measure the length of those four PWM signals (this is the action
> anglular data of the sensors). Now, with the PIC16F874 I use, I have two
> options: use a capture register or use interrupt on change. Problem with
> the capture is, I only have two. From the IOC ports RB7:RB4, there are
> four. However, I remember a lot of words of caution when using the IOC
> feature. If I have those four digital input signals only on those ports,
> can I use this safely? And what were the all-too-familiar problems with
> Interrupt on Change again?
> Best Regards,
> Claudio
Another IOC question: what happens if a pin on portb changes while i'm busy
with the interrupt handler from a previous pin change? I'm using four timed
PWM modulated signals which could come very close together, so the chance of
collosion is quite high.
> Another IOC question: what happens if a pin on portb changes
> while i'm busy with the interrupt handler from a previous pin
> change? I'm using four timed PWM modulated signals which
> could come very close together, so the chance of collosion is
> quite high
It might be better if you connect your signals to four general pins
and OR the four signals together into b0 and use the INT function.
When an INT occurs, poll the signal pins to find out which one
caused it. If signals really do come that close (ie closer than you
can process them in an ISR) then there'll have to be some sort
of flagging or logging so that events can be processed at a time
when you know it can be done without interruption
Polling the complete portb won't be any faster then any other port? If two
interrupts come that close, the second one is lost, isn't it? If this is the
case, it's of no use if I connect the signal lines to other ports, by using
IOC I've lost port B anyway.
So I think I just have to take a possible collision into account when
processing the numbers. And at 100 Hz I have some measurements
to spare, so that's ok :)
To Kevin:
I'm not following you completely (I'm more of a s/w guy). Is this the same
technique as to converting all those digital lines into one (or more) analog
line(s), putting it through an A/D and then convert back to the individual
signals?
If you feed the PWM signal into an RC (low pass) filter like so :-
PWM O----/\/\/\----+----o ANALOG IN
|
=
|
GND O--------------+----o GND
With the time constant of the filter say 10 times greater than the
period of the PWM, the DC level at the analog in will be proportional to
the duty cycle.
Therefore, rather than counting the period using interrupts, timers, or
capture module, you could measure the analog input voltage using the
build in A2D module. Seeing as you wish to measure 4 PWM signals, you
have enough A2D to do this.
Examples:
PWM constantly 0V
This will not charge the capacitor at all, and the A2D will read 0V
PWM constantly +5B
This will charge the capacitor to +5V, and the A2D will read +5V
PWM at 50% duty cycle
This will charge the capacitor up half the time, and discharge it the
other half. The A2D will read arounbd 2.5V
Instead of using IOC on PortB, why not multiplex the four inputs to either
one or both CCP modules? You could use a cheap CMOS multiplexer (4051/4052)
or roll your own with a few logic gates.
The CCP interrupt could take care of switching the multiplexer to the
correct channel and store the previous result in an appropriate variable, so
it would be essentialy invisible to your main loop code.
I do not think you can reliably use the interrupt on change feature to
support this requirement. Here is my thinking:
1: an interrupt occurs because, for example RB7 changes
2: your interrupt handler clears the interrupt-on-change interrupt flag.
3: your interrupt handler reads PORTB to determine which pin changed.
4: just as your interrupt handler is reading PORTB, RB5 also changes, but
the 'interrupt-on-change-bug' means that the new value of RB5 will neither
be seen by your read, nor will it set the interrupt-on-change interrupt flag
again.
This is my understanding of how this works. However, I have never used the
interrupt-on-change feature myself, so I could be wrong.
> So I think I just have to take a possible collision into account when
> processing the numbers. And at 100 Hz I have some measurements
> to spare, so that's ok :)
Ah... if this is really only 100Hz then I would definitely handle it by
polling in a timer interrupt.
What you want to do is clear the interrupt flag right after you
save the registers at the beginning of the ISR and determine that
the source of the interrupt was the interrupt-on-change. As soon
as you finish processing the interrupt check the flag again to
see if ANOTHER interrupt occured during processing. If so, handle
it by doing a GOTO to the place where you initially cleared the
flag in the interrupt before. If the flag is NOT set, then
you exit the ISR in the usual way. This will catch as many
interrupts as possible, but ANY method is going to fail if
the interrupts come in so fast you can't process them!
It's only 100 Hz, but every pulse has a width with a 14 bit resolution. So a
simple pulse counter won't do. I have to have the start and stop time of
that pulse, in as high a resolution as possible. I want to use timer0
without prescaler and it's a 20 Mhz PIC, so that's a 5 Mhz counter. That's
why I have to do it in an interrupt, if it's in the main code, i can't do
anything else.
So the sport is to clear the int check flag and get a poll of the port as
close together as possible, check the isr flag again on my way out of the
isr and just hope for the best :) That way, only an interrupt in two or
three instruction cycles could be lost.
> So I think I just have to take a possible collision into account when
> processing the numbers. And at 100 Hz I have some measurements
> to spare, so that's ok :)
Ah... if this is really only 100Hz then I would definitely handle it by
polling in a timer interrupt.
My guess is he is using the 4 inputs to read two quadrature encoders.
These encoders output a square wave that is 90 degress out of phase and
from that information it's possible to determine both speed and
direction. An analog solution won't work nor will setting the the
outputs as inputs.
Hey, it's rude to talk about someone else in 3rd person while he is in
the room!
FYI; it's about the ADXL202 tilt sensor output. An ADXL202 has two tilt
sensor axis, each with a DCM which generates a PWM modulated signal.
Normal operations of the chip will result in a DC between 25% and 75%,
maybe even a smaller range. Zero g is 50% DC, 1 g is a 12.5% DC change.
The DC signals of the two axis are both centered around the center of
the pulse. It is therefore not strickly necessary to measure all 4 lines
at the same time, although measuring every pulse would be nice.
As we need two of those, we have 4 PWM outputs. The resolution of the
DCM in the ADXL chip is 14 bits, although this is higher then the
internal signal. But with Timer0 this is easily obtained on a 20 Mhz
chip.
To Bob:
Nice idea, easy to implement, no expensive components either. Only con
is that it reduces the frequency by a factor 4.
> If two interrupts come that close, the second one is lost, isn't it?
Yes, but the faster you can detect a signal (and process later)
the fewer you'll lose, so the ISR would have to be as short as
possible.
If you absolutely want to guarantee never missing a signal you'll
need some form of sample and hold that needs to account for
the worst case - all four signals arriving simultaneously. The s&h
can be digital (eg monostable). Each signal has a s&h that will
flip as a flag that an event has happened. As soon as the s/w
has finished working on the previous event you can move on to
the new one. As the PIC is looking serially at dynamic parallel
signals I don't think you have much choice. The other option is
parallel processing. Assign each signal a (small) PIC of its own
> Reading the specs 10 times haven't lit up the bulb in my brainless head. :-)
Here is the root of problems :) You urgently need to uppgrade cpu in your head
from bulb based half a centure outdated design to something modern, pentium
based possibly ? :) Less amount of energy will be enough to power it up :)
William "Chops" Westfield escreveu:
> 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
Yes, it is perfectly legal and compiles to bsf and bcf instructions.
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/
mitvma.mit.edu with SET PICList DIGEST in the body
