Function jump, as in jumping to a function.

For example... (ignore the mix of c++ and the bad syntax, haven't used c-based programming in a bit)

void my_fuction();

void my_fuction()
{
cout << "Doggies run at midnight" << endl;
}

int main()
{
cout << "Jumping" << endl;
my_function();
return 1;
}

When the program calls my_function it would make a function jump and go to another place in the code, I believe... exactly as you described.

This can be hacked in PBASIC with GOTOs but isn't elegant in the least. So interrupts allow you to employ properly coded functions then... am I correct?

Ah. I don't think so. What you're doing is calling my_function() from within main(). What an interrupt would look like is this:
So, you wouldn't call interrupt1() or interrupt2() from anywhere in main() (although you could, if you wanted), but whenever the system received an interrupt signal, it would stop what it's doing in main(), and execute (or jump to, if you prefer) the predefined interrupt function, and then come back to main(). Another way of thinking of it might be to think of the system inserting a function call into the program at any point, depending on when it receives the interrupt signal. Whenever that signal is received, it automatically executes this predefined function.

Hrm. I just repeated myself a few times. I hope it makes some sense.

As for PBASIC, that language has subroutine functionality (through GOSUB and labels), which is sort of like a function, but it doesn't take any arguments and it doesn't return any value.

Oh, ic... an external interface triggers the interrupts, not the program itself.

I get it now... thanks.

(BTW, declaring main as void violates the language standards, technically that isn't legal. Compilers compile it anyways because people like breaking it... but exit codes are a good thing. Anyways...)

(Also, in case you were wondering where the jump part came from, I'd guess it's roots are probably in the ASM jmp instruction.)

Ah. I should have made that more clear.

Glad I could be of service, though.

(I never claimed to adhere to standards :) )

(Yeah, it is)

I wanted to answer the question as to what 10 MIPS means: absolutely nothing. MIPS is really just a meaningless relationship because it doesn't show what type of instruction was executed. It could've been a series of NOP's. It can be rather frustrating trying to figure out how fast a CPU is just by manufacturer's information.

Matt

In my Cisco Networking class, we learned all about interrupts... if someone was playing a game on the computer rather than work, my teacher would go up to him...
"Do you know what an interrupt is?"
"...interrupt?"
*hits power button* "Yes, interrupt."

Hehe, learning interrupts the hard way...

The best part is that with ATX, you don't break Windows horrible when you hit the button.


Now, about these interrupts. Do they actually mean anything to us, if the code is structured at all like last year?

Last year, you could process all you wanted, but only output once per cycle. Will it be different now, since we can control all the pins, or will it be the same? If it's switch something whenever, however, then interrupts will be cool, otherwise, they seem nice, but kinda pointless.

Also, any ideas on whether or not we'll be getting a default code to build off of if we so choose?

Random wild speculations on your questions:

1) Interrupts will be useful for external first controlled operations so they can send signals to the bot that we can act on. (Auton triggers? Perhaps _optional_ auton triggers so teams that opt to go auton will be able to get a few extra points or something.) I dunno, just wild speculation. Or Interrupts allow us to press a button and have an action immediately take place.

2) Default code will probably be provided. Especially if the thing is done in C this year, they will need to give teams something to help them out. I can't imagine them not doing that....

3) Raw I/O access seems to indicate that we will be able to pull data in and out of pins at any point in the program. For a good autonomous mode, this seems like it would kinda be neccessary.

Wild speculation that has nothing to do with your message:

4) Auton mode will probably be vastly expanded this year?

5) The game might be changed to include signals from FIRST controllers to the bot that signify special events?

6) Something is up for this year... it's going to be nifty.

Interrupts might, for example, make it easy for you to implement shaft encoding on your axles, where a change of voltage level on a pin will cause the encoder service routine to be executed (right away, not after the next block of instructions has been successfully received from the OI, as has been the case).

It will ensure that your special on-board g5-based massively-parallel 49 YHz screamer can pass data to or from the IFI CPU (The little engine that though it might be able ?). Now you can write both computers' programs in the same language... well, maybe not.

BTW, in the microchip PIC series, an interrupt causes the various processor regs to be stored, and then execution always jumps to program memory location 4 hex, so you may have to write an interrupt check-and-sort-it-out routine (in C) to go at hex 4 which will have jumps to the routine appropriate to the interrupt; probably the compiler will insert a jump around all this for start up, which always commences at 0 hex.

I have been reading about various PICs for the past couple days, and some of the higher-end processors have multiple interrupt priorities which you can set (high and low). In the PIC18 series, the interrupt vectors for high and low priority interrupts are 0x8 and 0x18, respectively. You can manually poll the interrupt flags from within an interrupt routine to determine where you're coming from (or perhaps why you're going there:p), luckilly.

I hope the compiler we're to use supports inline assembly...

Inline asm is pretty standard on good chips I think...

I'm just gonna be annoyed if it won't work on linux.

Interrupts are used when input signals can change state at random times, and you have to respond to that signal immediately.

a so so example is the keyboard on your PC. The processor has no way to anticipate when you will push a key, so that would be an interrupt

whenever you hit one, the code would stop whatever it was doing, go see what key you pressed, put that in a que or buffer somewhere, then go back to its regularly scheduled program

(thats not a really good example because the speed at which we type is extreemly slow to a processor, so it has plenty of time to go see what key you pressed, but you get the general idea)

on a bot something like a shaft encoder that puts out a pulse on each revolution - that could be an interrupt

or important things that need immediate attention, like a kill switch.

But if you want to know what an interrupt REALLY is

back when I was in engineering school, if you were walking down the hall talking to a friend and a girl walked by, that was an interrupt (we would stop talking for a second to activate the track and scan function)

and when she was gone you execute the return-from-interrupt instruction

(ah, those were the days! )

Interrupts
 

No one has mentioned the most useful purpose of interrupts: TIMERS! Every time a timer overflows (which is in the order of microsecs), an interrupt is generated. This would be important for generating PWM signals (unless the chip has special PWM outputs), as well as for "accurate" (well, more accurate than with PBASIC) dead-reckoning code.

You need an interrupt for that? I thought that was the main program loop...

You also seem to be missing the ask_number and make_conversation functions, file corruption perhaps?

I like C, this news makes me very happy :yikes: