how to use interrupts??

hey guys i was wondering how to use interrupts on the vex controller i scanned through the packet to find them but i didnt catch it so if any of you would help me that be great!!
i just need to know how they work and maybe how to use em in a programming situation.

i think you need easyC PRO for this, all i know about interrupts is that they check the pins our output data to the pins between normal cycles of the program, they do this so fast it seems like 2 things are happening at once, if you drag in a user code block theres probably a simple line of code to do this

check the help file

you dont have to have easy c pro you can have v1 , v2 , or pro the interupts are used for the ultrasonic sensor and the optical shaft encoder

so is there any occasion where i would really want to use an interrupt in a built robot?

well for an ultrasonic sensor, light sensor, bump sensor, etc… this is useful because then you dont have to stop what youre doing just to read a sensor

Sorry to say it but most of whats been said here is not entirely correct. There are several ways you can use interrupts. To use them you need to program to the robot. (The default code may have some already built in, check in the Inventors manual) To program the robot you need either MpLab or EasyC, any version. I can’t tell you exactly how to do it now, I will send this off to the coder of our team and you will have a response by the end of tomorrow. Yes there is the occasion that you would want to use interrupts.

The "interrupts are special input ports.

When a signal is asserted at/on one of them, special circuitry in the computer is activated. That circuitry causes the microprocessor to very quickly attempt to “interrupt” whatever code it is executing and switch to executing what is commonly known as an interrupt service routine (ISR). Once the ISR is done, the microprocessor typically returns to executing whatever code got interrupted by the ISR.

The ISR is typically a very short snippet of code that does something that is both simple and urgent, like read and store the current value of a timer so that the value can later be used to compute the distance to an object based on the travel time of an ultrasonic pulse.

None of the EasyC icons (except perhaps something in EasyC Pro (I don’t have it)) will let you create a customized ISR. Some of the functions represented by those icons do use interrupts (Encoder, Ultrasonic), but that use is hidden from you.

Typically folks who write ISRs are MPLAB/C18 users with good backgrounds in programming, or who have gotten some specialized hand-holding or training from a mentor/teacher. ISRs aren’t terribly hard to use, but they are a poor choice for a total rookie to tackle in their first (or second) project.

PS: I said above that the microprocessor attempts to interrupt whatever it is executing so that it can service an interrupt. The reason that it isn’t guaranteed to be able to immediately interrupt that code is that some stretches of code invoke specialized instructions that prevent the code from being interrupted. Programmers use those instructions to protect sections of code that might give incorrect results if they were interrupted one or more times at unpredictable times/locations.

so an interrupt is more like an emergency thing, if its not that bad i could use checking inputs and stopping whatever the robot is doing?

Close, but not quite. You are on the right track.

Interrupts are used for urgent things. Emergencies require the computer’s attention urgently, but so does the job of counting each interrupt generated by a rapidly spinning encoder (90 (or maybe 180) interrupts per revolution), or checking the clock to record what time an ultrasonic echo arrives.

If the computer doesn’t attend to both of these simple jobs very quickly, then the results seen by the ordinary routines in your software will be wrong (encoder outputs will be missed/uncounted and the distance reported by the ultrasonic routine will be too far and/or simply declared invalid by other parts of the ultrasonic routines).

Emergency situations detected by something outside the computer are one time when an interrupt is a good tool for getting the computer’s attention quickly. Ordinary situations that require very quick responses are also times to consider using interrupts.

It’s the speed of the required response that is the key to deciding if using an interrupt is necessary; not the importance of the situtation besing detected. Often fast responses are required outside of emergencies, and often emergencies are detected (and responded to) quickly enough using non-interrupt I/O.

PS: By “fast” I mean as fast as is possible for whatever computer you are using. Most of the things FTC/Vex robots do with switches or to steer need response times on the order of a few tens of milliseconds. That is pretty slow in the world of computers; even when dealing with PIC microcontrollers.

Don’t get the mistaken impression that using interrupts for all sensory inputs is a wise plan or that your robot will suddenly perform better if you did that. Use ordinary polling of the Analog/Digital I/O and of the receiver’s outputs for 99% of what you do, and you will be fine. Only use interrupts when your TIMING CALCULATIONS show you that they are necessary.

thnks man that makes sense

If what you were looking for was a general explanation of interrupts, then Blake has already given you an impressive bank of knowledge and you probably need nothing more. However, if you are interested in using interrupts (for shaft encoders or sonic sensors), I would happily give you some code as an example for autonomous procedures using such sensors. And do not worry, EasyC makes it really easy to utilize them. I could also help you if your programming in C18 (the language that MPLAB compiles) - it’s just a bit messier.
Hope I can help you out.

I would be interested in code… I have not written an Interrupt Service Routine (ISR) since 1989 when I wrote a MS-DOS Terminal program in Turbo (Borland) C 2.00…

Also this thread, Interrupt variables in MPLAB needs some assistance… I looked at the file user_routines_fast in the VexUserCode project and found some of the answers…

* FUNCTION NAME: InterruptHandlerLow
* PURPOSE:       Low priority interrupt handler
* If you want to use these external low priority interrupts or any of the
* peripheral interrupts then you must enable them in your initialization
* routine.  Innovation First, Inc. will not provide support for using these
* interrupts, so be careful.  There is great potential for glitchy code if good
* interrupt programming practices are not followed.  Especially read p. 28 of
* the "MPLAB(R) C18 C Compiler User's Guide" for information on context saving.
* CALLED FROM:   this file, InterruptVectorLow routine
* ARGUMENTS:     none
* RETURNS:       void
#pragma code
#pragma interruptlow InterruptHandlerLow save=PROD /* You may want to save additional symbols. */

void InterruptHandlerLow ()     
  unsigned char int_byte;       
  if (INTCON3bits.INT2IF && INTCON3bits.INT2IE)       /* The INT2 pin is RB2/DIG I/O 1. */
    INTCON3bits.INT2IF = 0;
  else if (INTCON3bits.INT3IF && INTCON3bits.INT3IE)  /* The INT3 pin is RB3/DIG I/O 2. */
    INTCON3bits.INT3IF = 0;
  else if (INTCONbits.RBIF && INTCONbits.RBIE)  /* DIG I/O 3-6 (RB4, RB5, RB6, or RB7) changed. */
    int_byte = PORTB;          /* You must read or write to PORTB */
    INTCONbits.RBIF = 0;     /*     and clear the interrupt flag         */
  }                                        /*     to clear the interrupt condition.  */

The Interrupts for 3-6 ALL appear in the INTCONbits structure…

well i got the general idea thanks for offering the code but right now im still goin basic not into those type of sensors yet… so thanks anyways man i appreciate it

I’m sorry to say I only have experience with the shaft encoders when it come to handling the interrupts. But if that suits your fancy I’d be happy to attach some code that uses encoders. I would just edit the default vex code for MPLAB and attach an archive of the project folder. Tell me if you want it.

Sure… every little bit of code helps…

True! Interrupts are used for intense, immediate needs.

They are advantageous in more ways then a few.

To make it simple, polling for data changes may miss data due to timing.

Polling is also a very wasteful use of instruction and CPU time.

Let’s imagine that you are waiting for a friend to pick you up at a busy corner. You have a choice. Nowadays, you can watch each car go by or you can wait for your friend to sends you a text or pushing on his horn.

Waste of time is waiting and watching. Most effecient is having him send a message. That is an interrupt.

And yes, to prevent other portions of the ‘loop’ from slowing down, you keep the interrupt processing routine very small, doing only as little as possible.

Speaking from the RS232/20ma days of PPD-11/44 unibus mini and terminal communication days. Enq, ack, sync, nak and binary machinery code, yes, I did those. Thankfully, I don’t have to anymore…

But interrupts, yes, I do believe it is worthwhile to understand them. I would not be telling the truth if I said that I understand the VEX version of them. I haven’t tried them, yet.