CC3000 API

Hi,

We are Embedded Design Company and one of our project we used TI module CC3000. We need to configure that module act as a Wi-Fi using one controller with SPI interface. In this interface we know  that speed of clock signal is 16 MHz but  we don't know about how to read and write the CC3000 module configuration and  SPI command format...

Please tell me that details if any one know about that. It is very useful to our development.......

Regards,

Murugan

Hi,

Your question is very generic.

All the required information can be found on our WiKi pages: http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_for_MCU.

You can find a working environment as a reference with many example applications.

You also can take a look at the porting guide and host programming guide.

Hope it can help you and if you have more specific question please inform us.

Regards

Hi,

It doesnt seem like his question is a generic one. In fact, it is a valid question because for developing our own drivers we need to know what commands can be sent to the cc3000 along with which registers exist on this module.

There should be a document regarding how the CC3000 can be interacted with at lowest level and not using the APIs. 

Do you have this documentation? and If not why not?

For example look at the documentation for the CC2500, where you can see the registers for CC2500 and how to write to them:

http://www.ti.com/lit/ds/swrs040c/swrs040c.pdf

THANK YOU

Hi,

We don't have such document.
Our driver is doing much more than writing some registers to the chip, we don't want developers to rewrite it.

However, the driver source code is publicly available.

Thanks,
Alon

Hi David,

the user Risto Koiva started a Wiki page regarding the CC3000 Protocol http://processors.wiki.ti.com/index.php/CC3000_Protocol

Also Ian Harris reversed engineered a bit of the API http://www.embeddedadventures.com/datasheets/WRL-3000_hw_v2_doc_v1.pdf

I am as curious as everyone else in why TI won't release the data but encourages us to reverse engineer the provided source code and write the documents ourselve.

If you want to start your own driver then you may look at my code http://code.google.com/p/cc3000-non-blocking-lib/

It is far more generic than the TI code (and it does not block) but it is not complete.

Greetings

Johannes

Hi Johannes,

I agree with you, I don't understand either why TI won't release the data.

Plus the TI Employee seemed a bit rude. I think he should take some customer services skills course.

The links that you have provided are great.

Thank You!!

BR,David

@Alon

> Our driver is doing much more than writing some registers to the chip.

I am not sure, you are talking about the same software as the others in this thread?

Can you please clarify what you mean by "driver"? Do you mean the ROM software/patch "driver" (companion part to "firmware" (as ROM software and patch)).

Or do you mean the host software ("API")?

> However, the driver source code is publicly available.

Can you point to "driver source code", which is publicly available, assuming you are not meaning host source code, which is available here:

http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads

Best regards,

Martin

Alon,

What TI is not grasping is that a generic port to TI MCU code is bloated and will not work with many processors out there very easily.  This is the embedded world and hell even bits matter most of the time.  This seems like such a simple request but all we get is TI attitude.  The whole just do it our way mantra does not work for some of us.  

Flexibility will gain you customers.  

And Alon will you please explain to me how the code was written if the document does not exist.  Do you mean you guys have to untangle your web in code whenever you have a question about your own code?  If so look @ Risto's page he created, it should be a lot of help to TI engineers as well as to us.

Chad

Hi Martin,

I was refering to the host driver source code.

Thanks,
Alon

 Hi David.

I'm sorry if you found my response to be rude. It wasn't my intention.
This E2E thread is important to us.
However, as of today, we simply don't have such a document (written by TI).

The wiki links that were provided do look interesting and valuable, I wasn't aware of them.
We will look into it.

Thanks,
Alon

Hi Alon,

thanks for your answer!

Alon Srednizki said:

However, as of today, we simply don't have such a document (written by TI).

In my earlier projects we have created a lot of design documents, where we documented interfaces (in this case like the command and event description and their interactions). How does this work, if such documentation does not existing? Is the same person realizing both sides (at least of a part of the API)? Or some kind of tool which just creates both sides?

I assume creating such a document needs only a few days. But the time (and confusion) which is saved during support (e.g. here in E2E) when such a document is existing is a multiple of the creation time...not talking about the time saving by just re-using it (or only changing small things), when a new generation of the same chip is coming out.

It would be interesting how software development (especially regarding CC3000) works inside TI. I think transparency also brings understanding why and how something is working or why it is like it is now. Would it be possible for you to give more details?

Many thanks!

Best regards,

Martin

@chad ely - We respect differences of opinion and they are welcome on E2E but it is not permitted to post anything that is obscene or otherwise objectionable, or that could be used to harass, abuse or threaten others (E2E community guidelines). Accordingly anything obscene like a word in your post has been removed. While differences of opinion and frustration can happen, let's please refrain from name calling.

David, Chad, Martin,

First, I wanted to let you know that open and frank feedback is always welcome & even appreciated.

I also wanted to assure you that none of the TI engineers on this thread were intentionally trying to be rude. However, I can understand how some of the matter-of-fact responses can be percieved as such.

Please note that we do learn from the feedback and comments we recieve. This will lead to improved and more extensive customer documentation & collateral for the next generation devices being developed by Software teams.

I also wanted to add that there are some inheritent differences between TI devices like CC2500 that are based on fully customizable, Proprietary RF Standards and CC3000 which attempts to simplify WiFi & Networking Stack Integration for our customers by embedding them on the Chip. The goal of simplifying WiFi & TCP/IP stack integration in embedded applications is the driving factor in deciding the types of API & documentation that we provide to our customers. In our experince, exposing register level API details, typically compounds the compexity of using this device.

Again, we appreciate your feedback and are looking at some of the documents high-lighted in this thread, that provide details on the SPI protocol for CC3000, to ensure we are also incorporating this information in the collataeral that our software and application teams are current working on.

Adnan

Hi, I also was looking for the SPI commands that has to be sent from a Mcu to the CC3000, and the only thing I found was this:

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

I just give up and start using the TI API, since I'm using the MSP-EXP430G2 it's not a big deal not to know exactly what they're doing, but I hope this could help someone.