• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 30 subscribers
  • Views 785 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.

CCS/TM4C123GH6PM: Comparison of Programming Model : 'Direct Register Access Model' versus 'Software Driver Model'

Prashant Dandriyal
Intellectual 790 points
Part Number: TM4C123GH6PM

Tool/software: Code Composer Studio

Hello.

I have been using TI microcontrollers for some of the recent projects at University. By default, I was advised to use the 'Software Driver Model' (which I didn't realise at that time that there were alternatives too). Then, on referring to the TIVAWARE Peripheral Driver Library, I realised that the same applications could also be implemented using the 'Direct Register Access Model'. 

I already did some programming using the software driver model, but sometimes I feel that perhaps it could be done easily using the 'Direct Register Access Model' .

Please tell me the merits of both these models and which one should I persue?

  • 0
    TI__Guru*** 135355 points

    Hello Prashant,

    If by 'Software Driver Module' you mean TivaWare's driverlib, then that is the best means to problem TM4C MCU's.

    Simply put, the driverlib from TivaWare is a TI developed and tested software library that allows for simplified control of the peripherals via API's. These API's use direct register commands to handle the MCU and all functions have been tested to ensure proper operation by TI so you don't have to muddle your way through learning about how to program the registers for each peripheral.

    The only benefits of driver register programming (often abbreviated as DRM, for Direct Register Modification) are:

    1) In occasional application where every cycle count matters, DRM is more efficient and runs faster, but this is seldom useful

    2) Programming the occasional register that TivaWare doesn't have a suitable API for (like enabling SPI loopback for example)

    Beyond that, TivaWare should always be used.

    For the E2E forums its also worth knowing that our official stance is we will not support applications that forgo using TivaWare to instead do DRM programming as we have spent a lot of time and energy to make the driverlib robust and won't 're-invent' the wheel by trying to debug something that TivaWare offers bug free to begin with.