• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 103 subscribers
  • Views 1441 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TI-RTOS for arm9 ?

ranchu
Guru 20755 points
Other Parts Discussed in Thread: OMAPL138, SYSBIOS

Hello,

I am not sure if arm can also be used with TI-RTOS.

Does TI-RTOS support using arm ?

If yes - will it support all the driver listed in 

for arm:

  • EMAC. Ethernet driver used by the networking stack (NDK) and not intended to be called directly.
  • WiFi. Used under WiFI host driver (Supports CC3100).
  • SDSPI. Driver for SD cards using an SPI (SSI) bus. This driver is used by the FatFS and not intended to be interfaced directly.
  • I2C. API set intended to be used directly by the application or middleware.
  • I2S. API set intended to be used directly by the application or middleware.
  • SPI. API set intended to be used directly by the application or middleware.
  • GPIO. API set intended to be used directly by the application or middleware to manage the GPIO interrupts, pins, and ports (and therefore the LEDs).
  • Pin. API set intended to be used directly by the application or middleware to manage the GPIO interrupts, pins, and ports (and therefore the LEDs).
  • UART. API set intended to be used directly by the application to communicate with the UART.
  • PWM. API set intended to be used directly by the application to communicate with a PWM.
  • Camera. API set intended to be used directly by the application to communicate with a camera.
  • Watchdog. API set intended to be used directly by the application or middleware to manage the watchdog timer.
  • USBMSCHFatFs. USB MSC Host under FatFS (for Flash drives). This driver is used by FatFS and is not intended to be called directly.
  • Other USB functionality. See the USB examples for reference modules that provide support for the Human Interface Device (HID) class (mouse and keyboard) and Communications Device Class (CDC). This code is provided as part of the examples, not as a separate driver.

Note that in the table in the following link it is said that wireless is not supported, so I'm not sure why these is a mismatch between these pages:

Regards,

Ran

  • 0
    TI__Guru* 96960 points
    The TI-RTOS kernel is supported the Arm9. The drivers are supplied by the processors SDK (which includes the TI-RTOS kernel...also called SYS/BIOS).

    Which device are you using? I'll move your thread to the device forum and they can answer your drivers questions. Please note, the list you supplied is for TI-RTOS with our MCU devices (e.g. CC26xx, CC13xx, CC32xx, MSP43x, TH4M, and the M3 side of the Concerto family C2000 devices).

    Todd
  • 0 in reply to ToddMullanix
    Guru 20755 points
    Hi TODD,

    I see that omapl138 examples are only for linux in arm. I undertstand that only the RTOS SDK for the dsp includes drivers.
    So, What's the best way to user TI-RTOS in arm ?
    Is it best to start with starterware for omapl138 (which includes driver) and then add above it RTOS ?

    Regards,
    Ran
  • 0 in reply to ranchu
    TI__Guru* 96960 points
    I've moved your thread to the device forum. They can give you better guidance.

    Todd
  • 0 in reply to ToddMullanix
    TI__Guru** 114410 points

    Ran,

    If you look at the TI RTOS examples built into CCS v6.1.3, you will notice that all the TI RTOS examples are also supported on ARM9 on the OMAPL138 device.  However the TI RTOS support for ARM9 is a fairly recent development which is not yet comprehended in our software development kit.

    The TI supported MCSDK1.1 for OMAPL138 assumes ARM Linux and SYSBIOS DSP usecase and the Starterware offering can be considered to be OS agnostic or non-OS based usecase. There will be some effort required to test the LLD drivers that exist on the TI RTOS on the DSP side to be tested on the ARM which is not currently been planned.

    If you could elaborate your usecase, we can try to evaluate internally and guide you on the best way forward.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Guru 20755 points

    Hi Rahul,

    Thank you very much, I got a similar answer from Titus on this issue.

    But I would please like one more suggestion on this:

    If you consider the following 2 alternatives, what do you think is a better one :

    1. start with startedware in arm, and then add above it TI-RTOS

    2. start with dsp rtos-ti in arm, and do all the relevant required changes.

    I need as a final goal to have TI-RTOS in both dsp & arm and support the following from arm:

    1. wifi

    2. uart bluetooth

    3. spi

    4. i2c

    5. gpio

    and doing the boot process ofcourse for both arm and dsp.

    Thank yuu,

    Ran

  • 0 in reply to ranchu
    TI__Mastermind 43955 points
    Hi Ran,

    When I look into the perspective of effort required on 1st option vs second option, the 1st option is better.

    1. Run the TI-RTOS on ARM9 and make sure that the sample examples are running on the target.
    2. Run the ARM examples of starterware pacakge
    3. Integrate/port the ARM examples with TI-RTOS

    The second option is a very tedious one as teh porting of the entire RTOS to ARM will be a time consuming one.
  • 0 in reply to Shankari G
    Guru 20755 points
    Shankari,

    Thank you very much!
  • 0 in reply to ranchu
    TI__Mastermind 43955 points

    You are welcome