[quote user="Bruno Saraiva"]It appears that you will have to argue with your colleague who's written the Tivaware User Guide[/quote]Thank you for pointing me at that part of the Tivaware User Guide. To be honest, my comment about the use of GPIOIntRegister() was that function didn't add any extra software overhead to the interrupt handler. I.e. GPIOIntRegister() doesn't add any software interrupt dispatch logic. As you mention I didn't consider any hardware overhead in moving the Vector Table from flash to ram. Also, since I am not a TI employee am unable to directly talk to the author of the Tivaware User Guide. [quote user="Bruno Saraiva"]So, which statement is true? I would love to adopt only run-time registrations in our company's codes, but the text above has been making us edit the startup file for each project.[/quote]The statement from the Tivaware User Guide makes a vague statement about a small latency without quantifying the expected value of the latency. The ARM Cortex-M4 Interrupt latency documentation says: [quote]There is a maximum of a twelve cycle latency from asserting the interrupt to execution of the first instruction of the ISR when the memory being accessed has no wait states being applied. When the FPU option is implemented and a floating point context is active and the lazy stacking is not enabled, this maximum latency is increased to twenty nine cycles. The first instructions to be executed are fetched in parallel to the stack push .[/quote]The ARM documentation that the first interrupt handler instructions are executed in parallel to the stack push implies that the interrupt handler table fetch has occurred before the stack push occurs, which is at odds with the Tivaware User Guide. That discrepancy between the ARM and Tivaware documentation suggests a measurement should be performed to see what the difference in interrupt latency is for a vector table in flash .vs. ram.
↧