Main Site Documentation

Cheap Wifi Chip, the TI CC3000


#1

Ok boy and girls, now we may be in business… $10 for a WiFi chip! I’ve been eyeing this (the TI CC3000) chip for a while, but the low level SPI command API is not provided by TI, they only provide a driver for their devices. But now, an open-source Arduino driver has been written and that will likely be a do-able port. Particularly, in combination with mIP.

Looking at this driver, it looks like a great simplification! All I need for mIP are the raw packets out of the driver and I’m in business.


#2

Look what I found on my desk… Would you like one? :slight_smile:


#3

@ Valkyrie-MT - how serious are you about this? We really like to see this working with mIP.


#4

Yay! Gimme, gimme, gimme!


#5

Quite serious, but I have to review this Arduino code more thoroughly first. The enc28j60 was also an SPI based controller, so I am comfortable with the concept of writing a driver like this. I bought a cc3000 months ago, but when I looked at the docs, it was missing the low level details and the code they provide is VERY complex. I even enquired about it a month ago on TI’s site: http://e2e.ti.com/support/low_power_rf/f/851/t/267605.aspx but I had already seen all the docs they suggested.

I’ll probably start with porting the commands to join the network. If I can do that, I’ll try porting the whole thing, as Apache 2.0 of course. Supposedly, this code is so small/simple, it can run on an AT-Tiny…

So, if you guys have made the modules, obviously you have been thinking of porting the TI driver into the .NET MF firmware with LWIP…

@ Aron, yes I would love to buy one. Can I buy one of those devices off you? It’s easy enough to wire up SPI, but I greatly prefer the simplicity of the Gadgeteer sockets.


#6

Why would you want to use mIP with it? It’s got a built-in TCP/IP stack that’s going to be way faster than a managed stack.

TI provides a fairly easy-to-port library for the module. I didn’t have any issues getting it working in my project.

Frankly, I’m really surprised it took this long for someone to port it to Arduino – just provide a couple SPI functions and a GPIO interrupt. Easy.


#7

Please tell us more about your project. I bought one of these months ago with the plans of making a module but haven’t had the time to even break the seal on it. I am very eager for this to be available as a cheap WiFi module.


#8

Wow Jay! That’s awesome. So you integrated the C code into the NETMF firmware and exposed all the TCP stack methods and objects to be available to the managed code? And that was easy?

Do you have a link to TI’s easy-to-port library?

P.S. The thread descibing the Arduino port is here: http://forum.arduino.cc/index.php?PHPSESSID=99dhekjqthvp22gcd7fooslo03&topic=164007.30


#9

This is for a native project, not NETMF. But you could easily copy and paste the TI driver into an interop library and have a few interop functions that call library code. You’d have to write a NativeEvent for receiving data, but otherwise, it’d be pretty straightforward.

As for communicating with the CC3000, you’d call HAL_GPIO and HAL_SPI functions. You need one interrupt handler for the IRQ pin, but the HAL_GPIO interrupt methods are easy to get going. Again, I think if you’re working in .NET, the trickiest thing is to get events fired from C into managed.

It was in my original post, but I accidentally put quotes around the link. Here it is:
http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads#Platform_Independent_Downloads


#10

Jay brings up a good points, but we need a managed API. This device already has a TCP stack. The issue will be to wrap it in a .NET API. Preferably, one that is similar or the same as the standard .NET one. Stefan did something similar with the RN-XV here http://forums.netduino.com/index.php?/topic/3436-rn-xv-wifly-module-driver/

Having said that, it still does not deter me in the least. I want to see this thing work with no compromises. I just ordered and received my first Arduino. I intend to make it work there with the arduino library and make sure I understand how it communicates with the help of my logic analyzer. Then, I’ll rewrite in managed code. In fact, it makes a lot of sense to make it all managed code, particularly if we use the embedded TCP stack.


#11

It’d be way easier to just use the TI reference implementation and keep it in C. The library is really well-designed; it only needs a few SPI/GPIO functions to be plugged in.

I’m not sure what .NETMF’s TCP/IP implementation provides, but the reference SDK uses a BSD-style interface. It’s pretty easy to use.

The CC3000 is also fairly chatty – something to think about, especially if you want the (slow) managed framework to have to babysit it.

I’d avoid looking at that Arduino code; stick with the TI reference implementation.


#12

@ Aron - That is quite a exciting photograph. I suppose it is a glimpse of something to expect in the near future? Are you at liberty to share any more info?.. like when do you expect it to hit the market and what features will be supported?


#13

Actually, the Arduino code is essentially the TI reference implementation with the SPI I/O stuff worked out for the Arduino.


#14

Does it still make sense to develop a driver for the CC3000 by myself or is GHI developing a CC3000 driver for the gadgeteer platform?
The pictures Aron posted look like GHI is doing something in this direction…

Would be nice to get some information :slight_smile:


#15

I hope that Aron’s pictures are an indication that we’ll see an offering from GHI soon :slight_smile:


#16

I am working on a managed driver right now. I don’t know if GHI has an independent effort or not. My driver will be Apache 2.0 open source and will likely be published on Codeplex once it starts to work. Currently I can connect to Wifi and send a UDP message using a socket. I expect all the basic functions to be working within the next month.

If you’re interested in helping, I can get you a drop of the current code base. It’s all C#.


#17

3 new boards coming out from Adafruit based on the CC3000

Anxiously awaiting the Gadgeteer version …


#18

On what boards will it be working, any gadgeteer board with an S(PI)-Type connector ?