On Interrupts and an implementation approach

[mop]

At a loss on an ideal implementation approach as it relates to an interrupt handler. Information outlined in RequestBit is what I'd like to implement.
Some background info. RequestBit (the very first time) will be called from within a 20 hertz processing routine. I'll then 'ignore' 20 Hz calls via a flag that I'll set inside the 20Hz routine and in turn send a bit command, wait 2ms for the device to respond with the interrupt then continue to send bit commands via synchorize with the interrupt. if the interrupt does not happen within the 2 ms. .... see below for more.
if some could point me in the right direction, i'd appreaciate it. Pseudo code will work. Thanks in advance.



// so now. RequestBit gets called ONCE the very first time from the 20 Hz routine

void RequestBit()
{
CMDWORD.CmdData.Ocw2_Device_Mode = 1; // Bit
RequestData((_CMDWORD_UNION*)CMDWORD.CMDWORD_ARRAY,
&OCMDWORDSTATUS); // Send Bit Command


1. Send bit command per above
2. Wait 2 ms for the device to send the interrupt.
3. If no interrupt within the 2 ms, send the bit command again, then wait 2ms. If yet again no interrupt within the 2 ms, then give up. Send Standby command
4. On the other hand, if interrupt happened within the 2ms. The interrupt routine (below) will be called, which in turn calls RequestBit. Simply put, synchronize with the interrupt and send bit commands. If after sometime we’ve been synchronizing and suddenly ‘lost’ the interrupt. Give up. I.e. Send Standby command. Ensure that ‘any’ spurious interrupt that happens after we send the standby command gets ignored.


}



interrupt Interrupt_0(void)
{
RequestBit();
}


void RequestStandby()
{
CMDWORD.CmdData.Ocw2_Device_Mode = 0; // Standby
RequestData((_CMDWORD_UNION*)CMDWORD.CMDWORD_ARRAY,
&OCMDWORDSTATUS); // Send
Sby

}

[Kdr Kane]

It sounds a little dangerous with the way you're trying to do it. You may be trying to keep the program from going into an endless loop because the interrupt will be calling itself?

I'm not sure. I'm just trying to get something out of what you put up there.

If you are going to use a timer outside of your interrupt routine, then check the status of a flag. SET the flag with the timer if it was in RESET. Let the interrupt routine RESET the flag. In your timer routine, keep count of the times since SET was last needed. When find the interrupt routine is "idle" and not resetting the flag, then you set your "standby" flag.

[mop]

i did think in terms of 'item' 3 per your response. that'll ensure theres no abritration issues, ie. 'stuff' getting stepped on. put another way, if i was commanding the device to do BIT via synchronization then i command device to go to standby - perhaps becasue i did not receive the interrupt within the 2ms then any spurrious interrupt that might have happened after commanding device to standby will be ignored via the 'flag'.

this should much more elegant that the 'semaphore' i was trying to implement

[galathaea]

I think KdrKane has given the correct direction to go, but I will try to give a little bit more information from what I can make of the original example.

First, you almost always want to separate your control routines from your response routines. This is particularly critical in device drivers (which is what I am assuming your post is concerning). What this means is that your Interrupt_0 routine should only do what is necessary to handling the interrupt (which I take to be send bit request commands or reading the device buffer -- this part is a little confusing). There should definitely be other control routines whose jobs include registering/deregistering your interrupt handler, setting up the timer interrupt, and similar duties.

I think the confusing part of your post is that you routine appears to be dealing with two different types of interrupts: those generated from the device dealing with data transfer and those concerned with timer events. I am sorry if I am misreading, but it appears you want to distinguish between these two events so that you make decisions as to whether the device should be in transfer or standby mode. However, I only see one interrupt handler. My suggestion would be to separate out all distinct interrupts, as it would take more processing time to figure out which type of call was occuring inside a catch-all handler than knowing that based on function call, and it will make your design much simpler.

So my suggestions in general would be to separate control from handlers and make distinct interrupt handlers..

[mop]

galathaea, the device i'm communicating with has - in effect three modes. Standby, BIT and Stare. The communication protocol is 20 Hz messaging. ie I send commands at 20 Hz. I'll receive a response from the device 3.5 ms later. More to the point. The "hard' part (new out of college and never 'REALLY' messed with interrupts) is the mode "BIT". When commaded to do BIT, I now need to synchronize with the Interrupt from the device. So now when doing BIT, I essentially 'ignore' the 20Hz running in the background and send BIT command predicated upon the interrupt that the device should send back within 2ms +/- 50 microseconds upon receipt of a BIT command.

I agree that perhaps the ideal way is to use my 20Hz processign to set a flag. reset the flag the interrupt. in short use the 20Hz processign to check for timeouts (ie did i get the interrupt). Trouble is. 50ms seem like a mighty long time when the interrupt should come back in 2ms. I suppose i'll know more when i start integration.

Thanks for the advice