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.

Checking system clock inside custom library built for TM4C123x AND TM4C129x

Gents,

For the past weeks I have been properly organizing several of my projects, which by accident of nature were mostly built in a rush and were a mess of copy/paste accross different circuit boards.

Long story short, I am now "post-writing" libraries for some of the sensors, communication protocols, etc. They are all CCS Static Libraries, TivaWare based.

Most of these functionalities require to know the system clock, to configure the likes of SSI, I2C, UART and other clocks.

I can easily pass the system_clock to the library, in one of the typical initialization functions - something like InitCommLib(sysclock, portnumber). The main applications already store the value on the typical g_ui32_systemclock variables, no problem: on TM4C123x boards I'd use SysCtlClockGet(), and on 129x's it is the returned value from SysCtlClockFreqSet().

It is just not elegant that a library can't figure out the system's clock by itself... 

They say good code is code that works. If that's true, I should go do something else. But...

Question is: I don't think I can add, inside the static library, compile conditionals like #ifdef TARGET_IS_TM4C123 use one one method, else use the other, correct? Hence, any of you have an elegant suggestion around this?

Cheers,

  • Bruno Saraiva said:
    They say good code is code that works.

    But the converse is not true.  Just because code works it is not necessarily good code.

    I don't think passing the system clock speed to the library init is a bad thing. In fact I think it's a reasonably clean solution and with a little abstraction can be quite effective indeed. Instead of passing a speed pass a pointer (const naturally) to a structure that contains all such information.  You may start out with clock and then add values for other items such as maybe flags to indicate specific workarounds needed.

    alternately you could create a library that just contained a few routines (like clock setting/getting) that had to be compiled differently for different processors and compile separate libraries for each processor type.  Similar to compiling different libraries for different memory models.

    Robert

  • Hello Bruno,

    Instead of using the define TARGET_IS_TM4C123, you can use CLASS_IS_TM4C123 or CLASS_IS_TM4C129 as a checl

    Regards
    Amit
  • Amit, that would still require the #ifdef check which is what I understand Bruno is trying to avoid needing in the library.

    Robert
  • Hello Robert,

    No. The CLASS_IS_TM4C123 would be treated as an inline macro.

    Regards
    Amit
  • Ah,

    Although I don't think there is such a thing as an inline macro. There are macros and there are inline functions. The later not being supported by all C compilers yet since it is a relatively new addition to the C standard.

    Robert
  • Hello Robert,

    There are other as well in some of the driverlib header file.

    Regards
    Amit
  • Gents,

    Tested the CLASS_IS_TM4C123 suggestion today. This macro further expands to SYSCTL_DID0 and other derivated, similar names.

    Despite obvious, it took me a lot of ransacking to find where were those folks defined...

    So, just as a reminder, besides:

    #include "inc/hw_types.h"

    Add also:

    #include "inc/hw_sysctl.h"

    Bottom line: the solution does work like a charm for my need.

    Bruno