• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 1672 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.

Porting CC3000: Examples of CC3000 driver code ported to non-TI MCUs?

Peter Fenn
Intellectual 315 points
Other Parts Discussed in Thread: MSP430FR5739

Besides the posted MSP430 and Stellaris examples, on the CC3000 Wi-Fi for MCU Wiki page are also the following broken links:

- Can anyone advise the new addresses for these pages?
- Any examples of CC3000 host driver code ported to non-TI Microcontrollers would be welcome :-)
  • 0
    TI__Intellectual 1735 points

    Hi

    TI's third party PDE company is developing for non-TI platforms.

    You can contact them directly.

    The non-TI platforms SPI implementation differs mainly in the SPI are, so TI platforms SPI implementation provides a sufficient example.

    Reagrds

  • 0
    TI__Prodigy 545 points

    Peter:

    Please feel free to contact us at this mailing list  and we can get you some further information on the references you mention - cc3000_mcu_request@list.ti.com

    Regards,

    Dana

  • 0 in reply to Dana Myers49791
    Intellectual 315 points

    Dana

    Thanks for your earlier comment in this thread. I did send email to cc3000_mcu_request@list.ti.com last week (4/4/2012) but no assistance forthcoming....

    I find it hard to believe that customers are forced to go to a 3rd party (PDE - Pacific Design Engineering) to get further assistance on porting the cc3000 host driver to another processor?

    Please advise

    Thankyou, regards

    Peter 

  • 0 in reply to Peter Fenn
    Intellectual 620 points

    Peter,

    Porting the CC3000 Host driver is not difficult at all. The main part that must be modified, assuming that endianess is not a problem, are the SPI.c file, the GPIO calls in the initDriver and a few other functions. For the SPI.c, it simply means providing equivalent SPI communications functionality as what the MSP430 offers, which is very common.

    The host driver project and files are mostly portable across platforms and usually can be simply recompiled for the intended platform and the output library file incorporated to the main project.

    Which platform do you want to port it to?

    Regards,
    Gustavo

  • 0 in reply to GustavoL
    Intellectual 315 points

    Gustavo

    Thanks for your reply. The CC3000 host-driver code is being ported to Xilinx Microblaze (FPGA-based) processor.

    Any tips that you may have in this regard would be welcome :-)

    Peter

  • 0 in reply to Peter Fenn
    Intellectual 620 points

    Peter,

    A lot of the relevant info is available here:

    http://processors.wiki.ti.com/index.php/CC3000_Host_Driver_Porting_Guide

    http://processors.wiki.ti.com/index.php/CC3000_Host_Programming_Guide

    I am taking as an example the sensor application.

    The connection from the Microblaze to the CC3000 is SPI + 2 GPIOs (WLAN_EN and IRQ).

    ===========================

    IRQ line is an input to the microblaze and its interrupt handling should be done in

    an IRQ handler similar to what is done in spi.c lines 620 to 665. All you need is to place the actual code into your IRQ handler.

    Related functions that should be modified:

    ReadWlanInterruptPin()

    WlanInterruptEnable()

    WlanInterruptDisable()

    SpiCleanGPIOISR() in spi.c should clear the flag for the pin

    SpiPauseSpi should disable the IRQ Interrupt

    SpiResumeSpi should enable the IRQ interrupt

    ==========================

    For the GPIOs, WLAN_EN is just a microblaze output that should be toggled High or Low .

    WriteWlanPin() just toggles WLAN_EN high or low

    ========================

    The SPI interface is just SIMO, SOMI, SCK, and CSn.

    Take a look at

    init_spi() function needs to be changed so that the SPI interface is properly initialized. The Microblaze should be a master with 3-wire system (CSn is separate) and a clock of 1 to 16MHz.

    The definition of clock polarity and phase are:

    Data is changed on the first UCLK edge and captured on the following edge.

    Clock polarity : The inactive state is low.

    For CSN, the respective I/O control is done through defines at the top of spi.c:

    #define ASSERT_CS()          (P1OUT &= ~BIT3)

    #define DEASSERT_CS()        (P1OUT |= BIT3)

    Change these to toggle CS as needed (it's active low, that is, it is low when it is asserted).

    SpiWriteDataSynchronous needs to be modified. UCB0TXBUF = *data; writes whatever data is pointing to via spi, while UCB0RXBUF doesn't seem to do anything with the data read.

    SpiReadDataSynchronous is similar to above except data read is placed in data[i]

    ========================

    initDriver() needs to be changed so that the clock initialization is removed.

    ========================

    Unsolicited event timer should be created and should be properly used in:

    It's a simple timer that fires every 500ms

    unsolicicted_events_timer_init()

    unsolicicted_events_timer_disable()

    =========================

    __delay_cycles(6000000); or similar msp430 specific commands should be modified to create delays
    in whatever way you want. These should be blocking delays.

    6000000 cycles is about 0.24 seconds.

    ==========================

    buffers spi_buffer and wlan_tx_buffer should just be put in memory (I assume microblaze has enough). Remove those macros and pragma definitions around those two buffers

    ==========================

    There are other things in the software to be changed. For example switch handling and LEDs. You could start from the independent host driver, and look at how the sensor application calls the APIs.

    Regards,
    Gustavo

  • 0 in reply to GustavoL
    Prodigy 60 points

    Gustavo,

    I need to interface the CC3000 module to our existing platforms based on Renesas microcontrollers.

    Is it possible to access the information of the deleted web pages about interfacing the CC3000 to Renesas micros?

    Lucio

  • 0 in reply to Lucio Macellari
    TI__Mastermind 23565 points

    Lucio,

    Could you send an email to cc3000_mcu_request@list.ti.com, please?

    Thanks,

    Miguel

  • 0 in reply to GustavoL
    Prodigy 80 points

    Sir 

    We are trying to port CC3000 to LPC2148.

    We have followed the steps mentioned above.

    but there are a few problems

    1)I donot find the following functions defined anywhere:

    "

    ReadWlanInterruptPin()

    WlanInterruptEnable()

    WlanInterruptDisable()

    "

    I saw a callback in wlan_init().

    I understand i have to define my function in the callback.Is that so?

    2) WriteWlanPin(): toggles some defined value.Where do I port it to the GPIO which I would like to?


    3)initDriver(): I cannot find the function.

    4)I cannot find the following functions.

    unsolicicted_events_timer_init()

    unsolicicted_events_timer_disable()

    I have got the files from the following link :http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads#CC3000_Platform_Dependent_Downloads.

    I request you to clarify the issues at the earliest.

  • 0 in reply to varun nalam
    TI__Expert 5295 points

    Hi,

    Some of the functions you list above are defined in "board.c" under the application's sources, some in the the application main file (basic_wifi_application.c)

    Please download the basic wifi applications, all the functions are defined there.

    Basic wifi application for MSP430FR5739 as a reference can be found under: http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads

    http://www.ti.com/litv/zip/swrc265B