GIO Interrupt using HALCoGen

Hi Angel,
HalCoGen should make it easy for you to select whether you want the interrupt generated on a rising or a falling edge, and whether you want the interrupt to be high or low priority. There are checkboxes for these options on the GIO tab.
Whether you *need* rising or falling edge interrupts for your acceleration sensor - I can't really provide any guidance. Hopefully there is a timing diagram somewhere in the datasheet of the accleration sensor that will explain what the relationship is between the interrupt request signal and whatever else you need to do next (i.e. do you talk to the acceleration sensor over UART or SPI after each interrupt request?) You should be able to pick out a rising or falling edge from this type of diagram.
The high v.s. low priority option is within the RM48L952. This option is available because each of the GPIO pins can generate an interrupt.
Now let's say one pin were connected to a critical function like a 'stop' button. And you wanted this function to be acted on by the CPU immediately, even before any other peripheral on the device like uart or timer.
Then you may have some other GIO pins connected to a button that adjusts the brightness on a display.
The delay between pushing these buttons and the CPU responding is not very critical at all.
So you could decide to use the 'High Priority' request for the stop button, and the low prority request for the display brightness buttons.
The VIM will receive these as two different interrupts even though they come from the GIO module.
The high priority GIO interrupt defaults to VIM channel 9 which is pretty high already, only requests 0-8 are higher priority, and these are for the error signalling module (ESM - critical errors detected on the device) and RTI (usually used for OS tick).
NB: this is the default priority - you can even adjust this by changing the 'CHANMAP' field but that's really overkill for what we're talking about.
Ok so that stop button is the ninth 10th highest priority interrupt by default. How about the screen brightness buttons?
They default to request 23 which is still pretty high considering that there are 95 total request levels.
But it's still lower than HET, MibSPI, LIN, ADC... And again it's the default so you can make it lower priority than this.
Hopefully that explains why there are two priority levels to choose from for the GIO. Remember also that unless you change the channel map to make both of these interrupts request on the same VIM channel, you will have two different ISR handlers. You can see that in HalCoGen by looking at the VIM RAM tab.
Anyway my suggestion for your accelerometer it to forget about interrupts for the moment, and make a simple test program that just polls the GIO pin -- to either look for the pin to read '0' then '1' (rising edge) or '1' then '0' (falling edge). Just wait in a loop until you see the pin change. Then after the edge work out what you want to do next to the acclerometer (send it a command on SPI?). When this simple test is working the way you want it to, then you can move the function into an interrupt handler. That way you break the problem into two steps - and when each step doesn't work initially (invariably this happens;) there will be fewer things to check so you'll get through the steps more quickly.