Adding WiFi to Teensy 3.x

Status
Not open for further replies.
What a convoluted mess of files they have created.... Took me 20 minutes to find this and I actually gave up and was randomly opening files. Making something user friendly does not mean creating over 40 files and linking them ffs.

Included in one of the library files is this line that sets SPI speed to 12MHz.
Code:
static const SPISettings wifi_SPISettings(12000000L, MSBFIRST, SPI_MODE0);

I have no idea what the L at the end of 12000000L means, I hope its not breaking it for the Teensy.
 
So I reviewed Paul's SPI Library and I believe I need to put in the line:

Code:

SPI.beginTransaction(SPISettings(12000000, MSBFIRST, SPI_MODE0))

So I will give that a try and see if I can connect to the board.
 
Last edited:
i have the library running stock on teensy3.5 spi0, but i cant get it to run on spi1/2 even after modifying that section
 
i have the library running stock on teensy3.5 spi0, but i cant get it to run on spi1/2 even after modifying that section
Which library are you using? The one linked to in #27?

Back to: 12000000L just means it is a long constant... On some boards without it it defaulted to int16 size or max of 65535...

Note: I don't have any of the ESP8.... boards, but do have 2 ESP32s. Not sure if any support for these?

Now back to SPI. What SPI features are being used? Are you using standard SPI.transfer() or is it set up to use DMASPI? The reason I ask is I don't believe DMA SPI has been updated to work with T3.5 on SPI1 and 2 as there is only one Dmamux source for SPI1 and SPI2 (DMAMUX_SOURCE_SPI1, DMAMUX_SOURCE_SPI2), which can be either TX or RX, but can not use for both. There are a couple of threads on this. In my SPI library with async support, I (with help from TNI and others) was able to get this to work. But had to do some trickery....
But again don't know what features of SPI you are using
 
it worked on spi0, but completely locks up teensy if used on spi1/2,
If I could see the code, I will take a quick look through and see if anything obvious. As I mentioned DMA has issues. Also if it uses FIFO queue code you need to change it as well as the FIFO is 1 item deep where SPI0 is 4...
 
like without any library mods this works on teensy 3.5

Code:
  SPI.setSCK(13); SPI.setMOSI(11); SPI.setMISO(12); SPI.setCS(10); pinMode(10, OUTPUT); digitalWrite(10, HIGH); SPI.begin();
  WiFi.setPins(10, 2, 9);

10 for CS
2 for IRQ
9 for RESET
EN held HIGH

im able to open connections to http(s) sites fine.
 
never mind its working on the bench teensy, im going to try different pin setups (spi1)

okay this is really weird

works fine on a bench test teensy3.5
bring it to my setup with same pins & code and it locks up teensy.
works at the bench
this is really weird.......

im using WiFi.setPins(39, 17, 2); for both setups, with the file changed to use SPI1
*shrug*

DMM traces checked out okay

fearless, on a bench teensy 3.5 i have the library working on spi0 and spi1, i dont know why it doesnt work in my other project teensy 3.5 but, it works at the bench, didnt need to modify the 12mhz spisettings, thats left as is.
you may select an alternate port for SPI just alittle above the spisetting, by changing SPI to SPI1 in the define...

update:
hmm it works on one teensy 3.5, not the other, i pulled the T3.5 from my other project to benchtest it, it worked once with the winc1500 then never again, the other teensy works fine with it
other spi devices work fine using the same port, so something is very fishy...

same upload on both
another thing, when the winc1500 is disconnected, the library wifi101 locks up the entire teensy when booting (have not tested any arduinos), thats not really a good thing for a library to do... dunno if its a teensy issue or arduino as well, if its a global issue thats very bad for anyone who uses this library
 
Last edited:
calling wifi.status (or perhaps any other functions) will lockup the entire code shall the winc1500 ever disconnect/fail... this is a nasty nasty thing
 
I had some real issues with the Winc1500 SPI version.
I posted to Adafruit with no response.

They don't seem to support the IRQ and thus, each time they want to check for available, the software sends spi commands to the Winc1500 -
which causes more checks on available. software was thrashing as opposed to just checking the IRQ pin.

Anybody get this working.


Also, one issue I have found with many of the boards with the ESP8266 variants is that they ground CTS so that those not using hardware flow control always get data from the ESP8266.
 
adafruit no longer maintains winc1500

its a pretty good chip if the support was there, but alas, the wifi101 library that is a subversion of the adafruit deceased version has a terrible way of locking up the entire MCU if it fails or is not connected, and timeouts as much as 60secs or more which BLOCK. i stopped playing with it at that point.
 
also, richard, i mentioned that i got esp8266 running off the i2c bus with rts/cts @ 921600 baud, softwareserial just wet itself :p
 
Thanks tonton81--I'll give the spi settings a try with the WINC 1500. I'm using the ITEAD Intelligent Systems Libs for the ESP 8266, but it does not play well with the OSC libs UTP protocols that I got worked out with WiFi 101 and WiFi UDP. I wonder if you could post the Libs for the Esp 8266 i2c bus. Thanks
 
you need the uart adaptor that goes on the i2c bus, you can connect 16 of them per I2C port, so, teensy 3.5 has 3 i2c busses, theoretically you can add 48 uarts on teensy 3.5

the adaptor is from sandboxelectronics, and has 64byte FIFO with automatic rts/cts flow control (disabled by default)
MOD-000020.main_.jpg

there are maybe 1 or 2 other libs on the net that support it, however, the one i wrote which uses the stream class treats it like a normal uart, ex. Serial7, myUart, orWhatever
if your looking for rts+cts support on it, none of the public libraries have that support, but mine does, and as well, I also added automatic recovery (yes, thats right, you can hot plug it and it restores your baud rates and reconfigures the chip)
the rts+cts is automatic as well, meaning, if you dont use it, no biggie.

115200 tested on adafruit ultimate gps, 115200 tested on serial 7" lcd, 115200 tested on BT dongles, 921600 tested on esp
if you plan to do SSL on esp8266 over uart, don't...pages can exceed 40KB traffic which, doesnt stop the uart adaptor, but causes the esp8266 to restart itself as it's buffer is only 4/8KB max. Regular Http is fine as I used the normal library commands
I havn't made it public yet, never done any releases yet, just been coding in the past time looking for alternatives to more uarts.. maybe if you leave a trail of cookie crumbs it might fall out of my pocket on the way there :)

there is another guy working on an spi protocol for ESP, where the ESP is the slave, and the arduino is the MASTER, he's using the same syntaxs as the notmal libraries for esp8266, so this might be pretty good if it pans out, however, he didn't add SSL yet and I brought it up at his github, hopefully he can get that worked out, because, I aint putting no dead trailing winc1500's in my setups until they fix that lockup bug. I don't care about the "timeouts", I can throw that crap in another thread and it can take whatever time it needs to finish without slowing down the other threads :)

I'm also working on a quad uart SPI chip as well, there is a firmware bug in it which is nasty as heck, hopefully it can be ressolved, and I will make a uart library for it using the stream class

I make it real easy :)

Code:
//initializer

#include <i2c_t3.h>
#include "I2CUart.h"
i2cUart huzzah = i2cUart(144, 2); // huzzah   <--- 144 == chip address (1 of 16 addresses), 2 == Wire2 port
i2cUart bt = i2cUart(146, 2); // BT
.
.
.//setup
.
  huzzah.begin(921600);
  bt.begin(115200);
.
.
.
.
.loop
.
  while ( Serial.available() > 0 ) bt.write(Serial.read());
  if ( bt.available() > 0 ) Serial.print((char)bt.read());
  // while ( Serial.available() > 0 ) huzzah.write(Serial.read());
  if ( huzzah.available() > 0 ) Serial.print((char)huzzah.read())
;
 
Last edited:
Well I tried the firmware check sketch from Wifi 101 with the following pins on a Teensy 3.6:
SPI.setSCK(13);
SPI.setMOSI(11);
SPI.setMISO(12);
SPI.setCS(10);
pinMode(10, OUTPUT);
digitalWrite(10, HIGH);
SPI.begin();

WiFi.setPins (10,34,33); //CS, IRQ, RST

Very frustrating as the program hangs at:

WiFi 101 shield.

Oh well.
 
So I got a new Teensy 3.5, hooked it up per above specs, and got it to work! All sketches work and most importantly, my large program running a custom built high wattage laser rig under OSC control. Thanks for the help, guys.
 
So I got a new Teensy 3.5, hooked it up per above specs, and got it to work! All sketches work and most importantly, my large program running a custom built high wattage laser rig under OSC control. Thanks for the help, guys.

Are you suggesting that the WinC1500 worked for you with Teensy 3.5 but not with Teensy 3.6? Or perhaps there was something wrong with your 3.6 board?
 
I believe I put 5 volts on one of the 3.6 lines and fried that port. Teensy 3.5 is 5 volt complient and so was not an issue. Just happy that it is working.
 
I want to revise something I said earlier "I had some real issues with the Winc1500 SPI version."

That was incorrect. I am having no problems with T3.2 and Winc1500 SPI version.

I was/are having problems with the SPI version of the nrf51 based BLE Friend from Adafruit due to their software, but having no problems with the UART version of the nrf51 based BLE Friend from Adafruit.

Sorry,

Richard
 
Status
Not open for further replies.
Back
Top