programming problem

[Nikster]

I am writing software for an embedded systems project. I've never used interrupts so I'm not sure how to go about it.

These are the requirements:

.: There is a LCD screen and 3 buttons Up, Down and Select

.: The system shows a menu of audio streams and lets the user select from one of them using the buttons. Once a stream is selected the system plays the stream until "Select" is pressed again. And, that's when the system closes the stream and goes back to it's selection menu. Summary : 2 screens/states. First, menu screen and play screen - Up/Down allows you to select an option in the menu screen, When Select is pressed you goto the Play screen and come back to Menu Screen when Select is pressed (while in Play Screen)

.: While in the Menu Screen, call a funtion to update menu items every 5 seconds (scan_and_update() function call)

.: 3 buttons are hooked to the micro via external interrupts and have their ISR functions defined

.: Total 4 interrupts on the system : 1 timer (5 sec) and 3 input

I'm not sure how to go about programming the interrupt driven model. If you can help with pseudo code it would be great or point to resources that have more on this.

I am using a standard C compiler that cross compiles for Atmel AVR platform.

Post if you have a question.

Thanks!!

 

[EagleKeeper]

Basic concept of interrupt driven system is that when a signal comes in, the interrupt handler grabs it and processes that data.
While this is going on, all other interrupts are locked out.
The old method (which worked for me in the 70's) had you grab the critical data and store it off in a FIFO buffer.
Then return from the interrupt handler.
The OS will then resume where it was interrupted from.

You may want to have the timer handler also analyze the data stored off by the interrupt handlers.
The interrupt handlers should be run at a higher priority than the timer.

Have the timer run at a 1 second frequency with a counter for the 5 sec mark.
Then every second process the interrupt data collected.
Depending on the frequency of the interrupts, you can do some processing within the handler, but this is not advisable due to the lockout.
The interrupt handler should save the stack before it starts to process the interrupt and restore the stack when finished.
This will allow the interrupted routine to continue on as if nothing has happened.

This is the basic theory, things may have changed in the last 30 years in terms of implimentation and language dependencies.

 

[Nikster]

Thanks!