Teensy 3 and Adafruit CC3000 breakout

Status
Not open for further replies.
P

pkourany

Active member
I am connecting my Teensy 3 to an Adafruit CC3000 breakout board. I downloaded the latest Teensyduino and I am using the Arduino 1.05 IDE. I also downloaded the latest CC3000 library from Adafruit's github.

When I try and compile the Sendtweet sample sketch, I get an error:

​
SendTweet:360: error: 'strchr_P' was not declared in this scope

I did a google search and no one else is mentioning this problem.

I looked in the Teensy pgmspace.h file and could not find strchr_P defined anywhere. The sketch uses this in its urlEncode function and the string that is encoded is in PROGMEM and therefore the need for strchr_P. I there a reason this function is not defined? Does anyone have a quick fix?

Thanks!
 
Paul,

I was able to compile the project and run it on the Teensy 3 but I get the weirdest problem. The SendTweet sketch has a couple of calls for dns lookup (cc3000.getHostByName) of a time server and the twitter api site. The first time server lookup to pool.ntp.org returns a valid IP (I checked with nslookup on my PC) but when the code gets to looking up api.twitter.com, the call returns the same IP as the time server lookup. Any subsequent calls do the same thing.

Short of rebuilding my Arduino 1.05 IDE and teenyduino environment, I have no idea what the issue is?

Can you help?

Thanks!
 
Paul,

I ran the SendTweet sketch again but this time using an Arduino Pro Mini running at 3.3v/8Mhz with IDE 1.54 and the SAME THING occurs. The ip lookup works the first call, then the next returns the same IP regardless of what url is given. Is this a defect in the module or in the code?

BTW, I first ran the buildtest sketch to make sure SPI was working. That ran fine.
 
Ok, so now I ran the SendTweet sketch on an UNO setup EXACTLY as indicated in the Adafruit tutorial. I got the same issues - the first dns lookup works the all others after that return the same IP. So then I reflashed the CC3000 with version 1.24 of its firmware and that went very well. However, it did not fix the dns issue!

So now I am suspecting my DLINK DIR655 router. I played with some settings but no luck. Has anyone got the SendTweet sketch working recently, especially on an UNO or Teensy 3?

Can anybody throw me a bone here?

:(:(
 
I have the adafruit CC3000 breakout running on UNO and mega. So how did you connect it to teensy 3? Are you powering it at 3.3v?
I powered breakout from independent 3.3v supply (common ground), but I can't get the CC3000 to initialise using various library sketches. I'm using pins 3,5 and SPI (10-13) on teensy 3.1. I've even tried the simple SPI test below which hangs waiting for CC3000 to initialize...
https://github.com/cmagagna/ArduinoCC3000Test
 
manitou, I am using on teensy 3.0. I am using a separate 5v supply for the cc3000 breakout board, and I could not get the board to even register in the serial monitor if I used pin3. I changed that to pin 2 and it fired up. I used a copy of the adafruit cc3000 lib from Pauls GitHub, and the test suite run just fine, as does giving the board a static IP.

https://github.com/PaulStoffregen/Adafruit_CC3000_Library
CLK to pin 13
MISO to pin 12
MOSI to pin 11
CS to pin 10

VBEN to pin 5
IRQ to pin 2 // and remember change the code in the standard sketch from pin 3 to pin 2 :)
 
Last edited:
mortonkopf said:
manitou, I am using on teensy 3.0. I am using a separate 5v supply for the cc3000 breakout board, and I could not get the board to even register in the serial monitor if I used pin3. I changed that to pin 2 and it fired up. I used a copy of the adafruit cc3000 lib from Pauls GitHub, and the test suite run just fine, as does giving the board a static IP.

https://github.com/PaulStoffregen/Adafruit_CC3000_Library
Click to expand...

so you are powering breakout at 5v? I thought the teensy 3.0 was not 5v tolerant.
 
yes, I could easily being doing something very wrong…

I am assuming that the cc3000 never outputs a 5v signal.

Please let me know if I am about the see a blue dragon escaping.
 
Last edited:
mortonkopf said:
yes, I could easily being doing something very wrong…

Please let me know if I am about the see a blue dragon escaping.
Click to expand...

Hmm, looking at the schematic, I think breaktout only shifts 5v to 3v (74HC4050) and does not shift 3.3v to 5v, so maybe no smoke, but i'm electronically challenged. I guess my trying to power breakout at 3.3v fails because regulator is expecting 5v ...
 
From the breakout board docs on the adafruit site, the 3.3v connection is output only. (Sorry if I misunderstood your connection method)

3.3v is an output from the breakout board's voltage regulator -
we won't be connecting anything to it in this tutorial.
Click to expand...
 
OK, powering CC3000 with 5v from independent power supply (common ground) and example sketches work on teensy 3.1
 
fabulous. And no dragons. Now, if you can just figure out how to update an octows2811 led array over wifi ...
 
mortonkopf said:
fabulous. And no dragons. Now, if you can just figure out how to update an octows2811 led array over wifi ...
Click to expand...

I've run a few benchmarks (UDP and TCP) on CC3000. The default RX/TX buffers (131 bytes?) are limiting. if you try to send more than 80 or so bytes in a UDP sendto, the CC3000 will hang. Similarly for TCP send/write. The small buffers are needed so the examples can run on UNO. Eventually, i'll experiment with increasing the size of the buffers. I haven't gotten TCP servers to work yet ...
 
Looks like the connection question is already answered, but just to be sure, I connected Teensy3's VIN pin, which has 5V from the USB, to the power input on Adafruit's CC3000 breakout. Their breakout board has a 3.3V regulator, so the CC3000 runs on 3.3V even when powered from 5V. It outputs 3.3V signals. The breakout board has a buffer chip that can accept 5V or 3.3V signals on the inputs (MOSI, SCK, CS).

I'm curious to hear how the CC3000 works for moving more data. Sounds like some code changes are needed. Maybe we can get Adafruit to accept a pull request that increases those sizes on boards that have more RAM? Unfortunately, it sounds like you're going to have to go through a process of fiddling or digging deeper into how it really works.
 
PaulStoffregen said:
Looks like the connection question is already answered, but just to be sure, I connected Teensy3's VIN pin, which has 5V from the USB, to the power input on Adafruit's CC3000 breakout. Their breakout board has a 3.3V regulator, so the CC3000 runs on 3.3V even when powered from 5V. It outputs 3.3V signals. The breakout board has a buffer chip that can accept 5V or 3.3V signals on the inputs (MOSI, SCK, CS).

I'm curious to hear how the CC3000 works for moving more data. Sounds like some code changes are needed. Maybe we can get Adafruit to accept a pull request that increases those sizes on boards that have more RAM? Unfortunately, it sounds like you're going to have to go through a process of fiddling or digging deeper into how it really works.
Click to expand...

Ahh, I was still thinking 3.3v at 300ma requiring independent power, but since CC3000 wants 5v, I can use Vin as you suggest. (I did see 300+ma consumed by CC3000).

It may be hard to get CC3000 to move data fast. First, the CC3000 indicates "ready" via the IRQ signal, so you can't just start streaming SPI data at it. Second, there are a lot of command-and-control bytes sent for each UDP transmission, and a bit of handshaking as well. Below are snapshots of a UDP echo -- teensy sends 8 bytes and gets 8 bytes back.
wifiechot.jpg
wifiechor.jpg
The SPI clock is running at 8mhz. The time between the end of transmit and the start of receive was 3.013ms. Channel 3 is CS, and channel 4 is IRQ from the CC3000. In the first (transmit) png, the third SPI event is the recvfrom() request to the CC3000. The logic analyzer data is actually from a run on a mega2560.
 
Last edited:
SPI DMA should be possible (or fast SPI) and in fact the TI has logic analyzer snapshots of SPI with DMA in
http://processors.wiki.ti.com/index.php/CC3000_Serial_Port_Interface_(SPI)
and that document suggests 4mbs should be possible with 8mhz SPI. SPI is spec'd to 16MHz so faster might be possible.

With the tiny (131 byte) default TX/RX buffers for the CC3000 (needed for memory-challenged UNO), you can't get very high data rates. I experimented with setting the RX/TX buffer size to 1300 in cc3000_common.h. I was able to send UDP packets of up to 200 bytes at 19 mbs (megabits/sec). Alas, if I send a 256 byte UDP packet, the CC3000 hung (and no packets showed up at the receiver). I have posted to Adafruit to see if they have ideas about using bigger buffers...
 
I think the problem with sending big packets is a bug in SpiWriteDataSynchronous() in ccspi.cpp. The index of the SPI.transfer() loop is uint8_t loc -- not big enough.

Changing the declaration to uint16_t fixed the big packet problem. I was able to send and receive 1000 byte UDP packets.

On mega2560 1000-byte (20 pkts) sends achieved about 2mbs (megabits/sec) and no-loss recv was 3mbs.
On teensy 3.0, send rate was 3.3mbs and recv rate was 3.7mbs.
 
Last edited:
I have hacked the CC3000 library to test teensy3* at SPI rates of 12 and 16 mhz. CC3000 SPI is spec'd up to 16 mhz. My UDP and TCP tests worked at the higher speeds (though still having trouble with teensy 3.1 TCP receive test??). I have some test results on DUE (12 mhz SPI) and mega2560, and some estimates of throughput if DMA (or fast SPI) were provided. Also maple (9 mhz SPI) initialized the CC3000 (maple library needs work). Current testresults are at

https://github.com/manitou48/DUEZoo/blob/master/cc3000.txt

For comparison wired-Ethernet performance data is in the same github directory, wizperf.txt
 
Smartconfig

Hello,
i am using the adafruit cc3000 library with a teensy 3.1.
I am running a sketches with a client and server to send osc with udp, when using the smartconfig reconnect (cc3000.begin(false, true))
the connection get broken in both way every 5 sec for about 500 ms .
The problem isn't happening when i don't use smartconfig but then the connection on the AP is really long without using the non volatile memory ( i think its about 30 second against 4 second with the smartconfig)

Does someone have an idea of what could be the problem ?

thank you!
 
Status
Not open for further replies.
Back
Top