Quote:
Originally posted by Ian W.
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?
|
They mean a ton to us. Have you tried to implement a shaft encoder with the basic stamp alone? Wouldn't it be nice if you didn't have to ASK the sensor for data all the time, and you could just be TOLD when the sensor tripped?
Quote:
|
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.
|
I think you fell into the same trap many people fell into. First's default code is only an example that does I/O once per cycle through mainloop: There's absolutely nothing stopping you from reading in more data or writing out more data during the same iteration of the main loop. We implemented quite a few subroutines in our code that wrote data out to an external basic stamp and read it back in (External stamp was only counting clicks on a shaft encoder). In theory, if they gave you enough interrupts you could have a nearly empty main loop and do *everything* you need in interupt handling routines. And you'd probably be a lot better off, too, as you'd be only executing code you needed to execute at that particular time. About the only thing it would still be wise to poll would be the joystick axis.
Quote:
|
Also, any ideas on whether or not we'll be getting a default code to build off of if we so choose?
|
I'd be surprised if they didn't give some example default code. Quite a few teams rely on the default code.
__________________
Team 677 - The Wirestrippers - Columbus School for Girls and The Ohio State University
EMAIL:
mccune@ling.ohio-state.edu
...And all you touch and all you see
Is all your life will ever be...