Correct way to implement a state machine in an ISR

[SuMa_296631]

Just getting started with the PSoC5LP (although I have used other devices for many years) and I'm not sure the best way to implement a state machine inside my ISR.

   

The situation is that I have a UART that is talking to a WiFi device that transfers 'packets' in each direction between the processor and the device. I want to set up a state machine (on the Rx side) that looks for the start of a packet, builds the packet (taking into account 'escape' values etc.) and sets a flag (for now) to indicate a packet has been received.

   

As the ISR code is the only thing that needs to know about the state values, buffers etc. with a couple of access functions, I would normally declare these things at the top of the ISR C file. As the ISR code is re-written by the IDE, I can see where I should put the definitions so they are maintained across the new versions. However I want to be able to initialise the state machine and typically that code whould go into the xx_ISR_Start() or xxx_ISR_Enable() functions but they do not have the code protection mechanisms in them.

   

The alternative is to add my own 'init' function but I cannot see how to add the declaration into the ".h" file as, again, there do not seem to be any of the code protection markers. (I could use 'extern' declarations but I think they are ugly in that I could update the header/c files and forget to update the 'extern' declaractions.)

   

What is the way this is supopsed to be done?

   

Thanks

   

Susan

[HeLi_263931]

You can put the ISR function in your own file. Then you use the xx_ISR_StartEx(&function_name) function to provide its address to the ISR component.

   

Define the function prototype using CY_ISR_PROTO(function_name), and the implementation with CY_ISR(function_name). The initialization can be done in the main() function then.

[ETRO_SSN583]

Re state machines -

               

http://www.cypress.com/?rID=44402     AN62510 - Implementing State Machines with PSoC® 3, PSoC 4, and PSoC 5LP

   

http://www.cypress.com/?rID=52365     State machines using LUTs Video

           

To implement a C ISR -

               

http://www.cypress.com/?rID=38267     AN54460 - PSoC® 3, PSoC 4, and PSoC 5LP Interrupts

       

CY_ISR_PROTO(MyIntFunc);      // Prototype declaration

   

then

   

CY_ISR(MyIntFunc)                         // Interrupt function definition

   

{

   

// Place code here

   

}

       

In  initialization part of the program

       

isr_StartEX(MyIntFunc);               // Start Interrupt with my handler

       

CY_ISR-macro have a look into the "System Reference Guide" under Help -> Documentation..

       

Regards, Dana.

[SuMa_296631]

 Thanks Hli and Dana.

   

I had through of using a separate file but with all of the 'handles' provided in the default ISR files (except for the ones I think I needed!) I thought that it was supposed to be used for this.

   

I had read the App Note on implementing ISRs but it does not really cover anything other than very simple cases. I *know* that an ISR should be 'simple' but I was lookingfor a better (i.e. less error prone) way of communicating between the ISR and the rest of the code.

   

Dana, thanks for those links to usign an LUT - I'll check those out.

   

Susan

[HeLi_263931]

The ISR should do only the minimum amount of work. Anything thats not really timing critical should be done outside of it (in the main loop). Typically one uses some boolean or int flags (defined as volatile), that get set in the ISR and are evaluated in the main loop.

[ETRO_SSN583]

This is a good overview of ISR routine creation -

           

          http://www.embedded.com/design/programming-languages-and-tools/4397803/Interrupts-short-and-simple--...

       

Regards, Dana.

[SuMa_296631]

 As I said, I know that an ISR shuld be simple. While I am just learnign abotu the PSoC devices (and liking what I see more and more) I am 'well known' on another microcontroller forum for pushing the "short and fast" line for ISRs.

   

However I do recognise that there can be extenuating circumstances sometimes in which case the "fast" should override the "short", and running a state machine can be one of them. You can get quite a few 'states' in a switch statement that each can have a few lines of code with together make up a long(ish) ISR routine, but any particualr code path is itself 'short' and therefore 'fast'.

   

Anyway, I now have the code working so thank you to everyone.

   

My next problem is that the device I should be talking to did not come with any firmware (despite the data sheet's insistance that it did!!!!) but that is another story for another company's support forum.

   

Susan