• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 1072 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GPIO ROM API difference (123x vs 129x)

Igor Uspensky
Intellectual 670 points

Hi,

Just out of curiosity. Consider the following API functions:

ROM_GPIOIntEnable;

ROM_GPIOIntDisable;

ROM_GPIOIntStatus;

ROM_GPIOIntClear;

That functions (originated from Stellaris ROM) were dropped for tm4c123x while tm4c129x does support them again.

This actually creates unnecessary difference between 123x and 129x. Could someone at TI elaborate on the cause of such a fluctuation? It seems quite reasonable to expect future Tiva ROM revisions with more harmonized API set. Or this is unlikely?

---

regards,

    Igor

  • 0
    TI__Guru**** 244400 points

    Hello Igor

    Normally a ROM function is deprecated if there is a bug in its implementation that may not be fixed in a silicon revision. That is why we prescribe using  MAP_ functions to take care of such changes automatically. Having said that it is a very simple function to have a bug for ROM exemption/

    I would need to check back on the history of the function.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Intellectual 670 points

    Hello Amit,

    Thanks for quick response. These functions are very simple indeed and 123x is more mature (based on the number of revisions) than 129x so this looks a bit odd.

    ---

    regards,

        Igor

  • 0 in reply to Igor Uspensky
    TI__Guru**** 244400 points

    Hello Igor

    The number of revisions is not indicative of the maturity of a device, but more based on feature set, architectural change or bug fixes. So by definition if a device is in production and orderable, it is a qual'ed, char'ed and tested device.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Intellectual 670 points

    Hi Amit,

    Sorry for the confusing statement. Seems maturity is a wrong word in this context. I was intended to say that the 123x was well into its life cycle when 129x has started to emerge.

    ---

    regards,

        Igor

  • 0 in reply to Igor Uspensky
    TI__Guru**** 244400 points

    Hello Igor,

    I have not been able to get to the source of the missing API's. However to answer the question, TM4C129 now has these functions in ROM as well, based on the feedbacks we may have got at the time of TM4C123 device testing for ROM functions.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Intellectual 670 points

    Thanks for your effort, Amit!

    ---

    regards,

        Igor

  • 0 in reply to Amit Ashara
    Guru 92251 points

    Amit Ashara said:
    I have not been able to get to the source of the missing API's

    I think this post http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/260270/946585.aspx#946585 is relevant. This suggests the functions weren't removed from the TM4C123 ROM, but were omitted from the ROM.h generated for TivaWare.

  • 0 in reply to Chester Gillon
    Intellectual 670 points

    Hi Chester,

    What's the story! Thanks a lot for the link. I'd tried to use search before and can't explain the miss. Sometimes it takes long time to see the results displayed. Anyway. 

    About a year ago I'd ported one project for tm4c123something (first Tiva launchpad) switching from StellarisWare to TivaWare. That time all went very smoothly as I'd carefully followed the porting guidelines. The MAP_ defines works as advertised so the missing ROM functions are substituted with their Flash siblings from the pre-compiled TivaWare driver library.

    Moreover, I'd made an experiment to measure the code size overhead, presumably introduced by taking code from the big common library. To do so I'd extracted the functions' sources from TivaWare and compiled them to form a small dedicated library. Then the application was built using that small library instead of the common driver library.

    It turned out the difference between the app binary image sizes (the dedicated lib approach vs. the TI-recommended one) is just four bytes (for the IAR suite anyway). So the overhead was found negligible and the only outstanding question was why did they created such a mess with the renaming. Now I know. It was a side effect of re-branding campaign.

    But it looks a bit scary as the campaign is not entirely over (see the Different Name - Same Great Support sticky) so the risk of introduction of more side effects.

    ---

    regards,

        Igor