• State TI Thinks Resolved
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 32 views
  • Users 0 members are here
Support feedback
Options
Options
Related

F29H850DM: Driver library have no ISR handler

Muppidi Satish Kumar
Prodigy 130 points

Part Number: F29H850DM
Other Parts Discussed in Thread: F29-SDK

Hello,

I am working on F29H85x SOM module. When I try to interface UART module for my application, I am not able to find ISR from driver file (uart.h). What I expect is, driver file should have ISR (Say for UART) where this ISR read the interrupt souce and invoke respective callbacks (Transmit complete, Receive completed, Receive timeout, UART errors). Is it really not available in driver file or Am I missing something.  

  • 0
    TI__Mastermind 27530 points

    The UART driver file (uart.h) does not contain predefined ISR functions. This is by design in our driverlib approach for the F29H85x family.

    We do, however, provide several out-of-box software examples in the SDK to help show use-cases and ISR implementations as well as generally aid quicker software development. For example, please look at uart_ex4_echoback.c in the F29-SDK driverlib examples, which:

    • Shows proper ISR structure e.g. UART_getInterruptStatus(), UART_clearInterruptStatus()
    • Demonstrates data handling loop e.g.UART_isDataAvailable() and UART_readCharNonBlocking()
    • Includes required UART_clearGlobalInterruptFlag() call

    Regarding driverlib - this provides the peripheral APIs to be used in ISR implementation within an application as:

    • ISR naming and usage is application-specific
    • Different applications may need different interrupt handling logic
    • The driver focuses on providing hardware abstraction, not application-specific ISR code

    So the driverlib intentionally doesn't include ISR definitions. Users implement ISRs using the driverlib APIs as shown above.

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    Prodigy 130 points

    Okay, I understand. But 

    Allison Nguyen said:
    ISR naming and usage is application-specific

    This is somehow not convincing me. Because, Peripheral ISR especially for UART Interrupt handling should contain 

    Check for Interrupt source --> Is error flag set-->Call user error call back, Same way checking for Tx and Rx interrupt in aligned with the current state of the UART and call respective callbacks.

    And also, if User needs to send group of bytes (> FIFO size), then ISR would have checked if user requested number of bytes are completed or not. If completed, call end of Tx callback otherwise send bytes to Tx FIFO. Similarly for Rx. All these can be maintained in single ISR. There is more scope to provide single ISR for all the UARTs by maintaining instances for each UART.

    I see, the driver file gap is not only limited to the ISR. Some useful APIs for transmitting variable length of data in interrupt mode, DMA mode which are non-blocking mode. For example, when we use DMA, there is no provision for sending variable message length. Developer needs to reconfigure the DMA for length field. The DMA configuration is limited to fixed length. driver library API should have implemented with this functionality too.

    Individual user can implement this ISR on their own. But it requires robust handling. Developer like me would be very happy if TI provides this ISR, so that developer can focus more on application part and avoiding most of the bugs. 

    The example code you told  uart_ex4_echoback.c have ISR but it does not have error handling. For some sort of errors this example may go in undefined state and probably external reset might be needed.

    PC: My explanation here is to let TI know the opportunity to improve driver library files. Not meant to criticizing.