• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 102 subscribers
  • Views 2095 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.

SYS/BIOS driver for Delfino series

Murat SABUNCU
Prodigy 40 points

Other Parts Discussed in Thread: TMS320F28335, SYSBIOS

Hello everyone,

I am currently evaluating to use SYS/BIOS with C28x Delfino series specifically TMS320F28335. I know that the processor is one of the SYS/BIOS supported processors. However, so far, I couldn't manage to find any drivers written for this processor. Is there any drivers provided that I couldnt find or does it mean that we have to write our own drivers for UART, I2C, SPI, ADC and etc.?

Can you recommend any other software or PSP that includes those drivers? Or is there any document that introduces writing our own drivers step-by-step?

To summarize, what is the eassiest way of using TMS320F28335 peripherals within SYS/BIOS?

Thanks,

Murat

  • 0
    TI__Mastermind 20480 points

    Hi Murat,

    we don't have a full RTOS SDK for the Delfino. Unfortunately, we don't have a general guide on how to develop drivers for an RTOS.

    It seems to me that you might be already familiar with SYS/BIOS. What you could do is to take a look at the Control Suite, which does have peripheral drivers that are meant to be used in a stand-alone application. To start, it should be safe to manipulate a peripheral using the peripheral drivers while you use a single task to manage that particular peripheral, this avoids some nasty problems (race-conditions).

    It's important to note that SYS/BIOS handles the interrupt controller. You need have to use SYS/BIOS Hwi/Swi APIs instead of the Control Suite APIs to handle the interrupt controller.

    Hopefully this can get you going.

  • 0 in reply to Tom Kopriva
    Prodigy 40 points

    Hi Tom,

    Thanks for the reply. It helped a lot to get things going. But I am also a bit confused with the following items.

    Tom Kopriva said:
    It's important to note that SYS/BIOS handles the interrupt controller. You need have to use SYS/BIOS Hwi/Swi APIs instead of the Control Suite APIs to handle the interrupt controller.

    Consider that I am setting up a full duplex SCI connection. With Control Suite examples what you would do is to set up interrupt registers with PIE Vector Table for things like "Receiver Data Ready" or "Transmitter FIFO Empty" etc. How that will be done in SYS/BIOS? 

    Tom Kopriva said:
    To start, it should be safe to manipulate a peripheral using the peripheral drivers while you use a single task to manage that particular peripheral, this avoids some nasty problems (race-conditions).

    Can you give a bit more detail? I can imagine getting an interrupt from the peripheral using an Hwi/Swi. Do you mean to process it in a single task?

    Thanks,

    Murat

  • 0 in reply to Murat SABUNCU
    TI__Mastermind 20480 points

    Hi Murat,

    Murat SABUNCU said:
    Consider that I am setting up a full duplex SCI connection. With Control Suite examples what you would do is to set up interrupt registers with PIE Vector Table for things like "Receiver Data Ready" or "Transmitter FIFO Empty" etc. How that will be done in SYS/BIOS?

    SYS/BIOS has modules that configures the PIE Vector Table for you. You could call a Hwi_create(vecterNum, isrFunc, params, eb) to install your ISR with a particular vector number. Note that you may have to tell the SCI peripheral that it should send a interrupt request to the PIE, which can be done using the peripheral's driver ware APIs.

    In your "isrFunc()" you need to service your SCI peripheral's "Receiver Data Ready" or "Transmitter FIFO Empty" and clear the source that caused the interrupt to be generated. Again, this step can be done using the peripheral's driver ware (e.i. Control Suite) and by referencing the F28335's TRM.

    In your case, you could create a Hwi object that calls your ISR whenever your SCI peripheral generates an interrupt signal for "Receiver Data Ready" or "Transmitter FIFO Empty" interrupt. The details on how the peripheral's interrupt is cleared and how it should be serviced is not taken care of by SYS/BIOS. For that, you can look at some stock Control Suite examples for the SCI.

    Murat SABUNCU said:

    To start, it should be safe to manipulate a peripheral using the peripheral drivers while you use a single task to manage that particular peripheral, this avoids some nasty problems (race-conditions).

    Can you give a bit more detail? I can imagine getting an interrupt from the peripheral using an Hwi/Swi. Do you mean to process it in a single task?

    [/quote]

    Sorry for making this sound confusing. Critical data process should still be done within a Hwi/Swi. What meant with this statement that you need to make sure that you control who is accessing your peripheral. You probably don't want to have multiple tasks trying to configure the SCI's control registers.

  • 0 in reply to Tom Kopriva
    Prodigy 40 points

    Hi Tom,

    This definitely solved my problem. Very appreciated for the help.

    Thanks,

    Murat

  • 0 in reply to Murat SABUNCU
    Expert 1505 points

    <<<<<The details on how the peripheral's interrupt is cleared and how it should be serviced is not taken care of by SYS/BIOS.

     

    Please explain this in reference to the check box in HWI GUI that says Automatically acknowledge PIE Interrupts. when would you not check this box and what code is always required in ISR(clearing IRQ)

  • 0 in reply to Mark Lazarewicz
    TI__Mastermind 20480 points

    Hi Mark,

    This option is specifically for the PIE controller. The PIE controller is connected between a peripheral/pin and the interrupt controller of the C28x. When you use the Hwi module for the C28x, it will automatically incorporate support to configure the PIE.

    The check box actually tells the Hwi module to clear the PIEACK bit of the PIE controller. It corresponds to the Hwi.enableAck .cfg option and is explained better in this wiki page. The original interrupt source (which goes into the PIE, from the peripheral) may still have to be cleared separately within the Hwi.

  • 0 in reply to Tom Kopriva
    Prodigy 200 points

    In an older version of the DSP/BIOS I created a GIO based SCI and (external) UART driver.  Is there something similar for SYS/BIOS and Delfino?  Do I have any hope of importing my old driver?

    Ideally is there an example GIO or equivalent driver for SCI?

    Thanks,

    jv

  • 0 in reply to Johnathan Vail
    TI__Guru* 96960 points

    Hi Johnathan,

    Which version of SYS/BIOS and Ipc are you using?

    Todd

  • 0 in reply to ToddMullanix
    Prodigy 200 points

    Umm, the short answer is the "the latest, I think".  Not sure where to find out but it might be 6.33.05.46 (on the help documents path).  This is for a TMS320F28335 chip.

    Thanks,

    jv

  • 0 in reply to Johnathan Vail
    TI__Guru* 96960 points

    GIO is still in SYS/BIOS (ti.sysbios.io.GIO).

    Todd

  • 0 in reply to ToddMullanix
    Prodigy 200 points

    Thanks for the quick followup, Todd.

    Right, the GIO feature is still there but is there an example (preferably SCI) using it?  I haven't actually tried it with the GIO but with the newer chip and the newer BIOS I don't know how much hacking I have to do to make it work.  If there was a new example using the GIO I would feel better about it or have something I could tailor easier.

    jv

  • 0 in reply to Johnathan Vail
    TI__Guru* 96960 points

    Hi Johnathan,

    Here is one from our regressions tests. Note: it does not talk to an actual peripheral.

    4718.nulliom.c

    2500.nulliom.h

    3264.empty.cfg

    2476.empty.c

    Todd

  • 0 in reply to ToddMullanix
    Prodigy 200 points

    Thank you Todd!

    This is (almost) perfect.  Absolute perfect would be some actual SCI code in there but you provided the part that I was missing.

    This is my old driver that I want to port.  There is much that is the same in yours and also some parts that are new/different and I was unclear how to start.  Now I have a map.

    jv

    3872.uartmd.c