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.
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
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..
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.
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.
This is a good overview of ISR routine creation -
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.