Call to arms | Teensy + WiFi = true

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:
Code: 
constexpr char kHostname[]{"arduino.cc"};
and ping.ino line #38 should be:
Code: 
constexpr char kHostname[]{"arduino.cc"};
 
Updated from github - cyw43_ping working:
> note: the code checked in with ..\QNEthernet_WIFI\src\qnethernet_opts.h :: ARDUINO_TEENSY41_CYW4343W 1

Code: 
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"
 
defragster said:
Updated from github - cyw43_ping working:
> note: the code checked in with ..\QNEthernet_WIFI\src\qnethernet_opts.h :: ARDUINO_TEENSY41_CYW4343W 1

Code: 
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"
Click to expand...
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...
 
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.
 
Last edited:
shawn said:
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.
Click to expand...
I am going to leave everything alone for now until you are finished with refactoring. That will minimize any confusion that might happen...
 
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...
 
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?

shawn said:
start with a new "WiFi" class ... the "users shouldn't have to modify a core configuration header file to make changes"
Click to expand...
Very cool! Building a wired QNEthernet sketch with WiFi set is not pretty :)
 
@shawn - I could not get the SNTPClient sketch to work on either WIFI or native Ethernet. If I change:
Code: 
udp.send(Ethernet.gatewayIP(), kNTPPort, buf, 48))
to:
Code: 
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)?
 
wwatson said:
@shawn - I could not get the SNTPClient sketch to work on either WIFI or native Ethernet. If I change:
Code: 
udp.send(Ethernet.gatewayIP(), kNTPPort, buf, 48))
to:
Code: 
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)?
Click to expand...
It's often the case that local routers have a time server. Some do not. This might be the reason.
 
@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:
Code: 
  if(buffer == nullptr) {
    if (logOutput) Serial.printf(" buffer == nullptr\n");
    return false;
  }
 
wwatson said:
@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:
Code: 
  if(buffer == nullptr) {
    if (logOutput) Serial.printf(" buffer == nullptr\n");
    return false;
  }
Click to expand...
I'm not following. I seem to be missing context.
 
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...
 
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
 
@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:LOL: There is still a lot of debug code in the libraries. Clean up will happen eventually....
 
wwatson said:
@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.
Click to expand...
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!
 
@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
 
You must log in or register to reply here.
Back
Top