hey
iam trying to implement a state machine on a PIC16F876
Iam using timer0 to setup timed events a tick for every 13.1ms,
a tick100 for 100ms and a ticksec for 1sec. I place these in a buffer when they occur inside the interrupt service routine.

The problem is that the tick happens alot quicker obvioulsy so the buffer gets filled with tick events, then the odd tick100 and ticksec.

In normal program flow the program graps all these tick events and runs them within a few ms from the buffer. I know fundamentally my buffer idea is the problem, iam windering if anyone has done something similar or would have any advice on setting up such a scheme??

I started using a buffer because i want to put other events in the
queue, for example the keypad is scanned during the ISR aswell and this may or maynot place an event in the queue.

I was thinking of checking the buffer for example a tick event and if there is one there then dont place another one in the buffer. How does this sound? My main concern is that i dont want to spend two long in the ISR?


Thanks
Michael

 

If your event handler can't process and clear the events fast enough, then there are only two courses available. One, get a faster hardware, or two slow the events down.

The buffer idea is sound. It is commonly used in various systems.

What are you trying to do with the tick event (13.1ms one)?

 

If your event handler can't process and clear the events fast enough, then there are only two courses available. One, get a faster hardware, or two slow the events down.

The buffer idea is sound. It is commonly used in various systems.

What are you trying to do with the tick event (13.1ms one)?

At the moment i use it to read the analogue input, i use the tick100 to flash
leds and ticksec to limit the runtime of the system.
If you have any ideas how i should be implementing the buffer to run this i would appreciate it!

Thanks

 

Your current scheme is good enough. If you are able to process the tick event, clear it and read the analogue input within the allocated 13.1ms then there would be no problem. Are you saying that your processing is slower than the allocated 13.1ms so that those events end up overflowing?

 

Your current scheme is good enough. If you are able to process the tick event, clear it and read the analogue input within the allocated 13.1ms then there would be no problem. Are you saying that your processing is slower than the allocated 13.1ms so that those events end up overflowing?

I think its faster because, iam able to get the event, do whatever is associated with it, and it actually appears to be able to grap another
tick event and do everything again that is to be done. So in otherwords even though my tick events are been put in the queue every 13ms its grapping them every couple ms and running them. Although now that i've wrote it down that doesn't make sense because there shouldn't be any tick events if it was faster, i can't explain this now but it is definately running my tick events more then once in the 13ms.

The question if it is faster then the 13ms how is it able to keep going back to the buffer and grap another tick event, when infact there shouldn't have one occurred yet?

Think i'll have to take a look at my get_event() or put_event() functions.

Thanks for your response, appreciate it if you could bear with me another bit on this