Interrupt limitations?

[randomperson]

hmm... this just kind of occured to me..

Im sure everyone will agree that one of the things about the new controller is the capabilities of interrupts. However... something popped in my head...

Ok, yes we can now find exactly when something is happening by being interrupted... but we still cant send out data more than every 17ms (or 25 for the edubot). So we can find out something is happening right now, but we cant do anything about it until a long time afterwards... lol. And naturally it will be very useful for when we're counting how many times something happens too...Hmm... which reminds me of another pet peeve about the controller..

The whole thing where we have to send data every X ms otherwise the controller resets.. I mean, even in PBASIC I never had trouble meeting the time requirement but at times it could be annoying. They should have something like a port we can read stuff from or whatever.. yeah, im just rambling about that. I don't really know how they could implement it any other way. But the time thing bothers me nonetheless. Yes, I realize that its useful for if you write code that goes crazy during competition then it can reset the controller back to a sane state but nonetheless..

One thing I am very thankful for though is the fact that we have timers in the processor... much yay about that!

Ok, I just realized that I really don't have much of a point in this post but ill post it nonetheless... any thoughts on this?

[Andrew]

hmm... this just kind of occured to me..

Ok, yes we can now find exactly when something is happening by being interrupted... but we still cant send out data more than every 17ms (or 25 for the edubot). ill post it nonetheless... any thoughts on this?

Some of the inputs (digital and analog) can be read directly and some of the outputs (definitely digital and I think PWM) can be written directly without going through the communication to the master uP. You'll have to dig through the default code to find which ones allow this.

If you plug through the timer code that IFI put together (http://www.innovationfirst.com/FIRSTRobotics/white_papers.htm), you will find out how to output a digital out every n millisec. I've run those mods (with some additional mods of my own, of course) and 'scoped out a 10 msec sample time. It was very reliable (ie no periodic glitches due to overflow or other stuff interrupting the low priority interrupt).

[Rickertsen2]

[QUOTE=randomperson]which reminds me of another pet peeve about the controller..

The whole thing where we have to send data every X ms otherwise the controller resets.. [QUOTE]

Thats the great thing about interrupts. You can set up a timer triggered interrupt to send/recieve data, so that you don;t have to worry about time limits. It works like this. You keep two copies of the data to be sent. A timer is set up to send/ recieve the data every x ms. One copy is sortof a working copy, which is not ready to be sent and the other is a copy which is ready to be sent. when you are done with the working copy, you disable interrupts, copy the working copy to the other one and re-enable interrupts. A similar system is used on computer video cards.