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.

RTOS/EK-TM4C1294XL: Compatibility between standalone TivaWare lib and the one rebuilt specifically for TI-RTOS

Part Number: EK-TM4C1294XL

Tool/software: TI-RTOS

In going through the RTOS 2-day workshop from Eric Wilbur, the viewer is warned that the *Ware libraries were rebuilt specifically for use within RTOS. I'm new to TI's RTOS and it seems that there are a few situations in which directly calling the TivaWare library function calls could be a faster way to implement a particular item and would ease the complexity of learning and transitioning to the RTOS. While I really like what the RTOS has to offer, a question that remains (I've been searching for a while) unclear is how to know what parts of the TivaWare are incompatible with RTOS and even if they *are* compatible, which parts could cause conflicts. I've tried comparing the TivaWare documentation in the rtos filepath and in the standalone filepath, but they don't seem to vary much except for some versioning aspects, so I didn't find it particularly illuminating.

Since I haven't found an answer to that yet, an approach I'm considering is to:

  1. Remove any includes of the TivaWare libs that don't come directly from the tirtos_XX_XX_XX_XX path so that I know I'm only using the rtos' tiva lib
  2. Write/build the application(s)
  3. If TivaWare calls error out, dig into the rtos lib to confirm the functions exist and are being called correctly. If issues persist, seek assistance from on high (TI's Mount Olympus E2E)

If this works and that's how it has to be, so be it, but I'm wondering if someone else has already had the same concern and found a wiser solution.

  • Hello Alberto,

    I'll pass this along to the RTOS team for further comments, but to touch on a few points...

    For question 1. that would be important especially because the latest TI-RTOS for TM4C was built with a previous TivaWare version, so you wouldn't want to have cross contamination on the TivaWare. The TI-RTOS install includes the full TivaWare folder for the version used, so you should only have links to that and use those API's.

    As far as what causes conflicts and what doesn't, in general you need think about what the functions are doing within the MCU and how it may relate to the RTOS running. If you are modifying interrupts such as enabling them which modifies the vector table, then you could get in the way of how the RTOS has been configured if use TivaWare API's. An example of this being an issue came up in this thread: e2e.ti.com/.../2347913

    That's just one of many cases, but I wanted to give you some context in terms of where TivaWare can interfere with TI RTOS since you commented about wondering when a direct TivaWare library call would be more useful.
  • Hi Alberto,

    We shipped TivaWare in TI-RTOS for the following reasons
    1. It makes it easier to build the TI-RTOS examples.
    2. We ship what we tested with.
    3. We rebuilt the GCC libs with hard floating-point support.

    We list the modifications we made to TivaWare in the <TI-RTOS install dir>\products\TivaWare_C_Series-<ver>\TI-RTOS.README file. Basically we just removed some directories to make the install smaller and we rebuild the GCC driverlb, grlib and usblib. We did not change any source code.

    You are free to use any of the TivaWare calls except don't use driverlib to plug the interrupts...use the kernel's Hwi module for this. You can even have an interrupt that strictly uses driverlib calls and is not managed by the kernel. We call these zero-latency interrupts (the kernel adds zero-latency). Take a look at the SYS/BIOS User Guide for more details (and restrictions).

    Todd
  • Sorry for the delayed reply, I had to work on another project for a while. Thank you both for the replies, especially Todd - the clarity and directness is very nice! This info greatly simplifies things