Call to arms | Teensy + WiFi = true

wwatson said:
I had that sort of problem as well with the @Dogbone06 WIFI board using a breadboard and jumper wires. If the WIFI would not connect or was giving erratic results I just moved the wires and connectors. That always took care of the problem. I was very intermittent in nature.Moved it to a new breadboard and the problem went away. Just a thought. Still working on the GIGA weather app and the RA8876...
Click to expand...
Pretty move the wires a bit on the bread board and it started working reliably - so yep probably connection issue with breadboard - probably time to get new ones.
 
mjs513 said:
Pretty move the wires a bit on the bread board and it started working reliably - so yep probably connection issue with breadboard - probably time to get new ones.
Click to expand...
Or do like we did while playing with Cameras on the MMOD, and create a shield the plugs into the Sparkfun ATP board...
1790282137087.png

Saved us from all of the hard soldering other than the SDCard on SDIO...
Could in theory do another one that has T4.1ish footprint instead of T4, although The MMOD does not have all of the same pins as T4.1

Here is a quick and dirty update of my T4.1 card image version showing the different MMOD pin numbers...

1790282454429.png
 
Hi All -

It's been over a month, so I wanted to provide an update on the Wireless shields.

We did make one change to the board from the previous design - it now has an option to use a u.FL antenna if desired, skipping the built in PCB antenna. Basically cut a trace and plug in a u.FL antenna.

The PCBs should arrive here at SparkFun shortly, and once here, we'll get the boards schedule for production. I'd estimate product launch late this month, or early November.

We will send final boards to the same group that received the beta boards.

On the software front:

Bluetooth:
The BLE libraries are in solid shape functionally, just requiring validation on the final boards and some extensive finalization. As noted earlier, the libraries use the BTStack implementation, and leverage the BLE class wrappers developed as part of the raspberry pi pico Arduino port.

WiFi:
I took the current implementation of the QNEthernet_WIFI library from https://github.com/wwatson4506/QNEthernet_WIFI, and moved the WiFi interface around a bit to prepare the API for product launch. So, for example, you no longer need to edit the secrets.h file with your wifi credentials.

Honestly I had Ai/Claude perform most of the work, focusing on a consistent interface, not impacting the existing ethernet driver and allowing both WiFi and Ethernet work concurrently if needed. Initial tests pass, but this needs further vetting and review.

Details:
- Repository - changes on the main branch: https://github.com/gigapod/QNEthernet_WIFI
- Notes on using the WiFi functionality:https://github.com/gigapod/QNEthernet_WIFI/blob/main/WIFI_README.md
- WiFi examples where added - https://github.com/gigapod/QNEthernet_WIFI/tree/main/examples
Each of the WiFi* examples also include a README.md that provides an overview of the example.

Any feedback is welcome/encouraged on the library - we want to make sure it's easy to use and meets the needs of this community!


Once we get closer to launching the boards, I'll update this thread.

-Kirk
 
gigapod said:
Details:
- Repository - changes on the main branch: https://github.com/gigapod/QNEthernet_WIFI
- Notes on using the WiFi functionality:https://github.com/gigapod/QNEthernet_WIFI/blob/main/WIFI_README.md
- WiFi examples where added - https://github.com/gigapod/QNEthernet_WIFI/tree/main/examples
Each of the WiFi* examples also include a README.md that provides an overview of the example.
Click to expand...
Just took a quick look through the library and wow - its look good and makes sense. Like the readmes for the examples and pinouts. Will be testing again soon. In middle of getting something non-teensy working which is driving me crazy. But looking good so far. Give me a day or two. You how it goes.

I also like the ability to add an external antenna that should be helpful.
 
@gigapod - Tested all of the WiFi examples and the "EthernetAndWiFi" example on both the CYW4343W and the CYW43439. Two issues found.
Using the CYW4343W with the "WiFiConnect.ino" sketch it stalled and failed to join the network. I had to add a 1ms delay in setup:
Code: 
// Program setup.
void setup() {
  Serial.begin(115200);
  while (!Serial && (millis() < 4000)) {
    // Wait for Serial
  }
  printf("WiFiConnect\r\n");

  const uint32_t t0 = millis();
  printf("Joining \"%s\"...\r\n", WIFI_SSID);
  if (!WiFi.begin(WIFI_SSID, WIFI_PASSPHRASE)) {
    printf("begin() failed: errno=%d, status=%s\r\n", errno,
           statusName(WiFi.status()));
    return;
  }
  const uint32_t tBegin = millis();

// Not sure why this delay is needed for the CYW4343W chip?? <---------
delay(1); // Added for use with CYW4343W. Not needed on the CYW43439. <--------

  // Watch the status and link until there's an address
  wl_status_t lastStatus = WiFi.status();
  printf("[%6lu ms] status: %s\r\n", tBegin - t0, statusName(lastStatus));
  uint32_t tLink = 0;
  while ((WiFi.localIP() == INADDR_NONE) && (millis() - t0 < kTimeout)) {
    const wl_status_t status = WiFi.status();
    if (status != lastStatus) {
      printf("[%6lu ms] status: %s\r\n", millis() - t0, statusName(status));
      lastStatus = status;
    }
    if ((tLink == 0) && WiFi.linkState()) {
      tLink = millis();
      printf("[%6lu ms] link up\r\n", tLink - t0);
    }
    delay(50);  // Calls yield(), which runs the stack
  }
  const uint32_t tIP = millis();
This really is of no consequence as the CYW4343W is pretty much dead meat anyway.
The other issue is with the "EthernetAndWiFi" example on both the CYW4343W and the CYW43439. It fails with this message:
Code: 
Starting...
Starting Ethernet with DHCP...
Starting WiFi with DHCP, joining "wswn_eero"...
Assertion "single netif already set" failed at line 305 in /home/wwatson/Arduino/libraries/QNEthernet_WIFI-gigapod/src/lwip/netif.c
I have to say that I really like the way you reworked and cleaned the code. Great job on documentation as well :D
I will be testing the other examples as well.
One thing that I noticed going through the CYW4343x driver code that I completely forgot about was the fact that it is not using block mode transfers:
Code: 
//==============================================================================
// Upload firmware to CYW4343x (Using byte mode instead of block mode).
// TODO: Need to setup block mode transfers.
//==============================================================================
This would be done in this function:

Code: 
//==============================================================================
// CMD53 Read/Write
//==============================================================================
bool W4343WCard::cardCMD53(uint32_t functionNumber, uint32_t registerAddress, uint8_t * buffer, uint32_t size, bool write, bool logOutput) {
  bool return_value = false;
  bool blockMode = false;
 
  if(buffer == nullptr) {
    if (logOutput) printf(" buffer == nullptr\n");
    return false;
  }
  uint8_t opCode = 1;
  // CMD53 argument format:
  // [31]    - Read/Write flag
  // [30:28] - Function number (0-7)
  // [27]    - Block mode (0 for byte mode, 1 for block mode)
  // [26]    - OP Code (0 for R/W to fixed address, 1 for R/W to incrementing address)
  // [25:9]  - Address (17-bit address)
  // [8:0]   - Byte count (for byte mode) or block count (for block mode)
  uint32_t arg = (write << 31) | (functionNumber << 28) | (blockMode << 27) |
                 (opCode << 26) | ((registerAddress & 0x1FFFF) << 9) | (size & 0x1FF);
This might give a speed increase...
 
You must log in or register to reply here.
Back
Top