Call to arms | Teensy + WiFi = true

[wwatson]

Just noticed that in simplePing.ino and ping.ino I did not change the ping destinations back to arduino.cc. Now fixed.
simplePing.ino line#33 should be:

constexpr char kHostname[]{"arduino.cc"};

and ping.ino line #38 should be:

constexpr char kHostname[]{"arduino.cc"};

 

[defragster]

Updated from github - cyw43_ping working:
> note: the code checked in with ..\QNEthernet_WIFI\src\qnethernet_opts.h :: ARDUINO_TEENSY41_CYW4343W 1

Looking up "arduino.cc"...
IP = 18.238.238.4
Round-trip time 18.6 ms
Round-trip time 6.5 ms
Round-trip time 15.0 ms

Does this really need to be buried so deeply - not in sketch folder?: "QNEthernet/src/qnethernet/drivers/cyw4343w/src/secrets.h"

 

[wwatson]

Updated from github - cyw43_ping working:
> note: the code checked in with ..\QNEthernet_WIFI\src\qnethernet_opts.h :: ARDUINO_TEENSY41_CYW4343W 1

Looking up "arduino.cc"...
IP = 18.238.238.4
Round-trip time 18.6 ms
Round-trip time 6.5 ms
Round-trip time 15.0 ms

Does this really need to be buried so deeply - not in sketch folder?: "QNEthernet/src/qnethernet/drivers/cyw4343w/src/secrets.h"

Glad to see you have it working. No, secret.h really does not have to be that far into the depths of QNEthernet I just had not got around to moving it yet. A person could also add the contents to the beginning of each sketch except the file is used by other files in the system. I'll play around with it...

 

[shawn]

There's some stuff I need to refactor, design-wise, so that Wi-Fi fits in better. I intend to start with a new "WiFi" class (or similar) for Wi-Fi-only things.

I'm currently in the process of working on converting everything to C++ plus templates because that will work better with the "users shouldn't have to modify a core configuration header file to make changes" philosophy. I'm figuring out what compromises should be made, what can actually be done to achieve that, what can be made to look the same as the current API, etc.

 

[wwatson]

There's some stuff I need to refactor, design-wise, so that Wi-Fi fits in better. I intend to start with a new "WiFi" class (or similar) for Wi-Fi-only things.

I'm currently in the process of working converting everything to C++ plus templates because that will work better with the "users shouldn't have to modify a core configuration header file to make changes" philosophy. I'm figuring out what compromises should be made, what can actually be done to achieve that, what can be made to look the same as the current API, etc.

I am going to leave everything alone for now until you are finished with refactoring. That will minimize any confusion that might happen...

 

[wwatson]

One other thing I forgot to mention is that cyw43_scan.ino has issues still. It will perform one or maybe two scans perfectly but will intermittently fail after that. I am looking into it. It has something to do with not resetting after each scan is performed. I think...

 

[defragster]

Just saw that secrets.h is manually included in sketch - so local copy could replace that.

NOTE: FAIL :: "\libraries\QNEthernet_WIFI\examples\cyw43_scan\cyw43_scan.ino"
Setup/begin Code of scan not the same as in ping? Code starts and seems okay, Finds Number of scan entries: 0?
Then 'press any key' take the Teensy to an odd reset? No setup() prints or CrashReport - but goes offline? TyComm cannot write? IDE 1 SerMon did show two on WiFi - but also failed after 'Press Any Key'?

Opps: was building for USB AUDIO ??? Set to Serial and it no longer does the "odd reset". But still not finding any active WiFi on Scan?

Opps? Maybe my antenna was hidden/wrong angle?:
> Number of scan entries: 46, Unfiltered scan (duplicate and hidden entries shown!)

Some ODD conflict when USB Built as AUDIO for sure. And 'Press Any Key' does not rescan succesfully. And restarting twice found ZERO and then ONE WiFi items?

start with a new "WiFi" class ... the "users shouldn't have to modify a core configuration header file to make changes"

Very cool! Building a wired QNEthernet sketch with WiFi set is not pretty

 

[shawn]

Also on my mind is multi-interface support, but that's later. (No promises and no target dates.)

 

[wwatson]

@shawn - I could not get the SNTPClient sketch to work on either WIFI or native Ethernet. If I change:

udp.send(Ethernet.gatewayIP(), kNTPPort, buf, 48))

to:

const char timeServer[] = "time.nist.gov";
udp.send(timeServer, kNTPPort, buf, 48)

It works with both WIFI and native Ethernet.

Could this have something to do with my routers firewall (that i cannot access any more)?

 

[shawn]

@shawn - I could not get the SNTPClient sketch to work on either WIFI or native Ethernet. If I change:

udp.send(Ethernet.gatewayIP(), kNTPPort, buf, 48))

to:

const char timeServer[] = "time.nist.gov";
udp.send(timeServer, kNTPPort, buf, 48)

It works with both WIFI and native Ethernet.

Could this have something to do with my routers firewall (that i cannot access any more)?

It's often the case that local routers have a time server. Some do not. This might be the reason.

 

[wwatson]

It's often the case that local routers have a time server. Some do not. This might be the reason.

Ok, thanks...

 

[shawn]

@wwatson you've inspired me to add a note to the SNTPClient example with alternative hosts.

 

[wwatson]

@shawn - I was getting intermittent crashes when I was testing some buggy FTP software for the Teensy41. Turns out that it was sending a null pointer to the SDIO driver "cardCMD53()" which did not catch it. I added a test for it. It returns a false result it a null pointer is detected.
This should not affect the rest of the code. that function is called by both SDIO read and write functions.
Looks like:

  if(buffer == nullptr) {
    if (logOutput) Serial.printf(" buffer == nullptr\n");
    return false;
  }

 

[shawn]

@shawn - I was getting intermittent crashes when I was testing some buggy FTP software for the Teensy41. Turns out that it was sending a null pointer to the SDIO driver "cardCMD53()" which did not catch it. I added a test for it. It returns a false result it a null pointer is detected.
This should not affect the rest of the code. that function is called by both SDIO read and write functions.
Looks like:

  if(buffer == nullptr) {
    if (logOutput) Serial.printf(" buffer == nullptr\n");
    return false;
  }

I'm not following. I seem to be missing context.

 

[wwatson]

I was testing an FTP driver for the TEENSY41 with QNEthernet_WIFI I was getting intermittent crash reports for a null pointer. I add code to the SDIO driver "cyw43_T4_SDIO.cpp" at about line# 372. An update...

 

[gigapod]

HI All -

First - this is a awesome project with great results. Not the easiest hardware/software problems to solve!

We were contacted recently by @Dogbone06 about this project and if SparkFun would be interested. Our answer is absolutely!

We'll have an Engineer start working on building a WiFi/Bluetooth solution based on the work performed by the community sometime in June. One of their first tasks will be connecting with this community thread.

As part of this project, we do want to have the Teensy community involved. This would include soliciting ideas, getting feedback on hardware design and sending some prototype boards to community members for testing.

On the software side, we can work with wwatson4506 and the existing repo to finish, test and document the library as needed.

And if anyone has any questions or want to provide additional information, don't hesitate to let us at sparkfun know (here, or just email me at sparkfun).

Kirk Benell
CTO - SparkFun

 

[wwatson]

@gigapod - Glad to see your interest in this project. A little background information and the state of the project at this moment. The WIFI card we used for testing was setup for WIFI only W/O Bluetooth being broken out. That may have changed. @Dogbone may know more about that and the current state of the hardware developed. Right now I only have the CYW4343W (1DX) version of the board to work with.

The first stage of driver development was using one of the Teensy4.1's 2 SDIO ports. @beermat and I did most of the development of the SDIO driver and @beermat finished the low level driver with being able to do WIFI scans. This was the first working version of the driver. I later added the ability to successfully join a network based on an SSID, Password and security type. This code can be found here. The "WiFi_scan_example' just works. The "WiFi_join_example" needs to have the SSID and password set in the "secrets.h" file found in the "src" folder.

The second stage of the came a bit later when I finally got tired of seeing the WIFI card sitting on my desk collecting dust I decided to try and implement examples found in the "picowi" library found here. I spent several months working on this. I had to adapt most of the network files to work with our driver. I managed to get most of the examples working with the WIFI card at which time I posted the library found here. This was introduced to the forum as well and seemed to spark a new interest in further development.

Next, it was decided that we should try to adapt our driver to the QNEthernet library. With help from the author of the QNEthernet library, @shawn, I went ahead and got our driver working with QNEthernet. This created some interesting situations as I had to add WIFI init and join to it. Also, I had to add the WIFI version of the ping and scan functions. This library is found here. Again most of the examples are working. Some I have had no experience with and did not test. I have also gone through the PJRC Ethernet library examples and have them working as well. Currently experimenting with some available FTP servers. Most of them work to a point but fail to transfer files either direction even using T41 wired native Ethernet. Still working on that one.

From what I have read, using the CYW43439 (1YN) version of the device is just a matter of changing the firmware uploaded to it. I am not sure if this has been done yet as I do not currently have that version of the WIFI card. @Dogbone may know if it has been tested.

Right now @shawn is refactoring the QNEthernet library and said that there is no definite timeline to finish. See post #104 and #108.

I am not a professional programmer and have no training in C or C++ programming other than the many years of hands on usage of those.
So please be gentle with me when see my parts of the code There is still a lot of debug code in the libraries. Clean up will happen eventually....

 

[Dogbone06]

@gigapod - Glad to see your interest in this project. A little background information and the state of the project at this moment. The WIFI card we used for testing was setup for WIFI only W/O Bluetooth being broken out. That may have changed. @Dogbone may know more about that and the current state of the hardware developed. Right now I only have the CYW4343W (1DX) version of the board to work with.

From what I have read, using the CYW43439 (1YN) version of the device is just a matter of changing the firmware uploaded to it. I am not sure if this has been done yet as I do not currently have that version of the WIFI card. @Dogbone may know if it has been tested.

The BT pins were never routed but that an easy task for Sparkfun to do on their design.

From what we saw the 1DX and 1YN are identical at least for the WiFi pins. I made the chips with both of them and they seem to work the same.

It's truly great that Sparkfun has the interest in this, amazing!

 

[gigapod]

@wwatson - Thanks for the detailed breakdown and history of this project. It is and will be a great help for our team at SparkFun!

While we can't be sure of all the details in the final product, starting with something that is working and can be tested with is incredibly helpful!

Our first steps will be our hardware design (which we'll review with members of this thread), and then once we have prototype boards the software work.This will be a big project, but the end result is a great addition to the Teensy community!

I'd also like to build a POE solution, but that's a further out discussion .

-Kirk

 

[sparkfro]

Howdy folks!

I'm starting work on the hardware design for this at SparkFun. I've skimmed through this thread to understand where the project is at, amazing work so far! Forgive me if I've missed any details, lots of info to take in! Also heads up that I'm new-ish to Teensy

Summary

This is my brief summary of hardware related information in this thread (I'm only working on hardware at the moment). Just putting this in one place for my own reference, but also in case it's helpful for others. Please chime in if I've missed anything important or have any incorrect information!

Boards have been tested with the 1DX (DigiKey) and 1YN (DigiKey). There was also interest in the 1XK (DigiKey). Quick comparison for reference:

Chip                     1DX                 1YN                 1XK
Product Status           To be discontinued  In production       To be discontinued
DigiKey's pricing per 1k $8.56               $5.61               $8.42
Frequencies              2.4GHz              2.4GHz              2.4GHz, 5GHz
Chipset                  CYW4343W            CYW43439            IW416
WiFi                     802.11 b/g/n 65Mbps 802.11 b/g/n 65Mbps 802.11 a/b/g/n 150Mbps
Bluetooth                5.1                 5.1                 5.2

The first board version connects to Teensy 4.1 with jumper wires. The second version uses the SD card slot, plus 1 jumper wire for the WL_ON pin. There's been suggestions to make a shield form factor.

The WiFi interface is currently being done over SDIO with the following pins on the Teensy 4.1:

CLK   23
CMD   22
D0    40
D1    41
D2    17
D3    16
INT   34
WL_ON 33

There's been suggestions to also route out the Bluetooth pins for Bluetooth support.

The Plan

Our board is most likely going to be a shield that can stack onto Teensy 4.1. Using the SD card slot was a very creative idea, though we're concerned it won't be practical for a lot of users, especially those who need the SD card slot, or those who don't want to wire up the extra GPIO. A shield should be a much more plug-and-play experience.

We'll connect pins for both WiFi and Bluetooth. I'm guessing the software for Bluetooth will be another beast to get working, but may as well just connect the pins anyways to support future software support.

The board will use a PCB trace antenna, again to maximize plug-and-play. In our experience with wireless boards, the vast majority of users just want the PCB antenna, though we could potentially include a U.FL connector for users who want/need an external antenna. TBD.

Once I have a rough initial design, will share it here so folks can pick at it and give feedback. Then we'll order prototypes and can send a handful to the folks here to test and verify the hardware design (and continue software development). After that, we can move to production!

Questions

1. Which radio chip should be used?
   1. I'm going to advocate for 1YN, since the others are "To be discontinued" and it sounds like the 1YN has been tested to work without issue.
   2. Although, 5GHz WiFi would be nice. Should we consider any other chips? Or is that just going to make software more difficult?
2. Should the final board use the pinout above for the SDIO, INT, and WL_ON pins? Should we consider any other pins?
   1. There was a comment about minimizing the number of GPIO required. Do we want to consider enabling 1-bit SDIO, or the gSPI interface?
   2. We could potentially include trace jumpers so users can change some of these pins, if desired.
   3. I'll admit that I don't quite understand how SDIO works on those pins. From what I can tell, Teensy 4.1 only breaks out one of the SDIO interfaces (uSDHC1) to the SD card slot, the other (uSDHC2) is not broken out. So how does SDIO work on those pins?
3. What pinout should be used for Bluetooth?
   1. A previous comment suggested "audio I2S signal to pins 2-5 and the UART signals to Serial7 or Serial8", is there any preference for Serial7 or Serial8?
   2. Something else I'm curious about is how the Raspberry Pi Pico W handles both WiFi and Bluetooth over just the gSPI interface. According to this post, it can't be done, but the Pico W does it. So I'm wondering if it would be possible to also do Bluetooth over SDIO to reduce the pin requirement. Worth exploring, or no?
4. Should the BT_ON pin be tied to the WL_ON pin?
   1. This is what the Pico W does. I believe it wastes more power if you're only doing one or the other, but might be nice to just keep it simple and help reduce the pin count.
5. Should the board include an optional U.FL antenna? If so, is it acceptable to require the user to reflow an SMD resistor to change the RF path?
   1. Of course more features is more better, but is there actually a widespread need for an external antenna? Keep in mind that the vast majority of wireless dev boards (ESP32, Pico W, etc.) use PCB antennas because that's what the vast majority of people actually want. Prefer to avoid adding features, cost, and complexity that only benefit a few people.
6. When we order prototypes, who needs them, and how many?
   1. Please, only folks who will actually have meaningful contributions, and only as many as needed. Prototypes can get expensive, so we don't want to be wasteful.
   2. We'll need shipping addresses at some point.
7. Who all deserves attribution for the hardware design?
   1. We license all our hardware designs under Creative Commons, please let me know how you'd like to be attributed.

Thanks all!

 

[shawn]

6. When we order prototypes, who needs them, and how many?

1. Please, only folks who will actually have meaningful contributions, and only as many as needed. Prototypes can get expensive, so we don't want to be wasteful.
2. We'll need shipping addresses at some point.

I'd love two so I can integrate all the WiFi things into the QNEthernet library. (I'm the author.) The reason I'm asking for two is so I can also test Teensy-to-Teensy communication.

 

[wwatson]

Thanks for replying.
Question:
1. Agreed. The 1YN would be the best choice.
2. uSDHC1 is broken out and so is the SDIO Interface we are using now. The pins described above are using uSDHC1. The current software can use uSCHD2 (SD card slot) by setting one parameter during initialization. SDIO pins are fixed for uSDHC1 and uSDHC2 I think.Someone else can verify this. INT, WL_ON and BL_ON can use any GPIO pin.
3. Not sure if anybody explored the Bluetooth option yet. Using gSPI on the Pico W had speed issues if I remember correctly. It would require a little additional hardware.
4. Not sure if it is a good idea to combine WL_ON and BL_ON. Initialization and timing may be different.
5. @Dogbone06 - may be able to answer this.
6. I have spent a lot of time working with this. One prototype please
7. This is easy, @Dogbone06 ...
EDIT: missing word.
EDIT2: Maybe a shield with jumpers to enable or disable WIFI connections to Teensy uSDHC1?

 

[defragster]

Thanks for replying.
Question:

Good Answers.
#1 - @Dogbone06 had to work to find the 1DX back then. 1YN was in hand IIRC -active with reduced cost.
#2 - Not sure SPI was supported? @KurtE did the work to expose SDIO/uSDHC2 support on the presented pins.
#6 - Same.

If the shield ends up large allowing trace cuts, pads, or jumpers that fit for optional pins, the user could adjust to use case.

 

[sparkfro]

I'd love two so I can integrate all the WiFi things into the QNEthernet library. (I'm the author.) The reason I'm asking for two is so I can also test Teensy-to-Teensy communication.

6. I have spent a lot of time working with this. One prototype please

#6 - Same.

1. Agreed. The 1YN would be the best choice.

#1 - @Dogbone06 had to work to find the 1DX back then. 1YN was in hand IIRC -active with reduced cost.

FWIW I poked through Murata's WiFi/Bluetooth catalog and DigiKey's product pages. 1YN is the cheapest option, and the only active 2.4GHz module. Murata has a number of modules that support 5GHz (and even 6GHz), though they're all more expensive, and I've got no clue how much extra effort the software would be. Unless anyone tells me otherwise, gonna move forward with 1YN.

2. uSDHC1 is broken out and so is the SDIO Interface we are using now. The pins described above are using uSDHC1. The current software can use uSCHD2 (SD card slot) by setting one parameter during initialization. SDIO pins are fixed for uSDHC1 and uSDHC2 I think.Someone else can verify this. INT, WL_ON and BL_ON can use any GPIO pin.

Hmm, that doesn't match my understanding. The Teensy 4.1 schematic shows pins SD_B0_n are used for the SD card slot, which is for uSDHC1. uSDHC2 uses SD_B1_n for uSDHC2, which are not broken out on the Teensy 4.1.

Maybe @KurtE can shed some light here?

Ultimately, if those pins work (23,22,40,41,17,16), then that's what matters. More just a curiosity of why those pins work with SDIO

3. Not sure if anybody explored the Bluetooth option yet. Using gSPI on the Pico W had speed issues if I remember correctly. It would require a little additional hardware.

Okay, unless someone tells me otherwise, I'll go with I2S on pins 2-5, and UART to Serial7 or Serial8 depending on which is easier to route.

4. Not sure if it is a good idea to combine WL_ON and BL_ON. Initialization and timing may be different.

I'll keep them on separate pins for the prototypes, can revisit later. Any preference on which pin to use for BT_ON?

7. This is easy, @Dogbone06 ...

@Dogbone06 Please let me know how you'd like to be attributed (eg. username, real name, etc.)

Let me know if there's anyone else who should be attributed for the hardware design!

Thanks all!

 

[wwatson]

@sparkfro - Sorry. You are correct uSDHC1 is the SD card slot and uSDHC2 is the external SDIO pins. Been awhile. I checked the driver to make sure...