Call to arms | Teensy + WiFi = true

wwatson said:
Try it out. Hopefully without any major issues;)
Click to expand...
Just woke up and sipping on coffee so decided to give it a try. Downloaded 0.37 and

scanner worked faster than before
```
* # SSID RSSI Channel BSSID Security *
**********************************************************************************************
1 SpectrumSetup-D2 -83 dBm 1 2C:EA:DC:8D:55:D0 WPA2 (4)
2 4A7E1A -72 dBm 6 34:98:B5:13:F2:F2 AUTO (6)
3 Fios-2RnJp -40 dBm 6 3C:BD:C5:3F:72:F2 WPA2 (4)
4 CyberPalin -46 dBm 11 48:5D:36:7D:5D:50 AUTO (6)
5 CyberPalin-Guest -43 dBm 11 4A:5D:36:7D:5D:51 WPA2 (4)
6 Verizon_C3G7C6 -85 dBm 1 7C:7E:F9:6D:90:34 WPA2 (4)
7 SPASERVICE -79 dBm 6 8C:8B:5B:D7:11:6A WPA2 (4)
8 LF_930_6243 -81 dBm 11 A6:97:5C:B2:62:43 WPA2 (4)
9 lexi deco -84 dBm 6 D8:47:32:3E:0D:7E WPA2 (4)
10 [LG_Oven]3a82 -56 dBm 11 E2:85:4D:86:3A:82 WPA2 (4)
Scan complete
Wait for next scan...
```
chronoclocks:
```
: Loop work: ms=8199 s=8.199
7: Loop time = 1000 ms
8: Loop work: ms=9199 s=9.199
8: Loop time = 1000 ms
9: Loop work: ms=10199 s=10.199
9: Loop time = 1000 ms
10: Loop work: ms=11199 s=11.199
10: Loop time = 1000 ms
11: Loop work: ms=12199 s=12.199
11: Loop time = 1000 ms
```
ping:
```
Looking up "arduino.cc"...
IP = 3.168.102.123
1. 64 bytes from 3.168.102.123: seq=0 ttl=250 time=8 ms
2. 64 bytes from 3.168.102.123: seq=1 ttl=250 time=37 ms
3. 64 bytes from 3.168.102.123: seq=2 ttl=250 time=6 ms
4. 64 bytes from 3.168.102.123: seq=3 ttl=250 time=12 ms
```
Interesting on this one is that scanner didn't pick up my 5G network so reverted.

Will play more with UDP application later :)

Nice job @wwatson you rock!
 
Wonderful progress!

wwatson said:
Unfortunately it's going to take some programming trickery to do auto detection due to the difference in pin usage between the two boards.
Click to expand...

The boards built with the 1DX use jumper wires, right? Surely it would be trivial to ask anyone using the 1DX to move their jumper wires to match the SparkFun board, so the pins match between them.

Also, how many folks actually have boards with the 1DX? IIRC only a handful (<10?) were built, whereas there will be orders of magnitude more of the SparkFun board with the 1YN.

jmarsh said:
I thought these chips were 2.4GHz only?
Click to expand...

Correct!
 
sparkfro said:
Wonderful progress!



The boards built with the 1DX use jumper wires, right? Surely it would be trivial to ask anyone using the 1DX to move their jumper wires to match the SparkFun board, so the pins match between them.

Also, how many folks actually have boards with the 1DX? IIRC only a handful (<10?) were built, whereas there will be orders of magnitude more of the SparkFun board with the 1YN.



Correct!
Click to expand...
You are actually correct:) Had not looked at it that way. As I stated before, not many people have the 1DX version so the 1YN board will to be the one most used. Thanks for bringing that up. I will adjust my 1DX board and test. My brain is a little saturated at the moment:D I also hope to start working on the Bluetooth side of the device which will require messing with the firmware again.

Glad everything seems to be working...
 
Hi All -

I got the WiFi scan working locally with one of our boards this morning! Great work by everyone - especially @wwatson! We (SparkFun) really appreciate the effort. If there is any need for help, let Dryw or I know - we are happy to jump in.

We feel pretty confident in the board design and WiFi support, but before we build a production run, we will at least need to verify BLE/Bluetooth is functional.

Any pointers / libraries to look at for Bluetooth? We can start looking into this, but wanted to see if any one in community had started, or had an idea for a development approach.

Thanks!
-Kirk
 
@gigapod - Unfortunately I have had no experience with Bluetooth yet but I am getting ready to start exploring it. I know that there has been work done here on the forum with USBHost_36 and Bluetooth. Mostly joysticks and such I think...
 
Scan ran almost 12 hours no problem!
Occasional gets neighbor TP_LINK and a TMobile. Picked up my CELL Hotspot right away this morning!

With edit of : ...\libraries\QNEthernet_WIFI\src\secrets.h
Running SImplePING example
Code: 
Pinging arduino.cc (99.86.101.46)...
1. Time = 7 ms
As before clean Build, only ORANGE note : 7 | #pragma message("Using CYW4343W QNEthernet Driver")
 
defragster said:
Scan ran almost 12 hours no problem!
Occasional gets neighbor TP_LINK and a TMobile. Picked up my CELL Hotspot right away this morning!

With edit of : ...\libraries\QNEthernet_WIFI\src\secrets.h
Running SImplePING example
Code: 
Pinging arduino.cc (99.86.101.46)...
1. Time = 7 ms
As before clean Build, only ORANGE note : 7 | #pragma message("Using CYW4343W QNEthernet Driver")
Click to expand...
That's excellent:D I'll change that to "CYW4343x". It serves to let you know if you are using WIFI or wired Ethernet. Right now I am trying to figure out how to only include the three include files for a particular WIFI device after the program is compiled and running. There are a total of six include files, three for the CYW43439 and three for the CYW4343W. The program has to be running to be able get the card ID to decide which three include files are needed. These are the firmware, CLM and NVRAM include files. I don't want to have to include all six files if I don't need to.This would use up more memory than necessary. Also moved the CYW4343W "REG_ON" to pin 30 and the "WL_IRQ" to pi 29. It works...
 
Correct me if I am wrong but if nothing is used from a particular include file the contents of that file will not be brought in and compiled, Right?
 
wwatson said:
Right now I am trying to figure out how to only include the three include files for a particular WIFI device after the program is compiled and running.
Click to expand...

wwatson said:
Correct me if I am wrong but if nothing is used from a particular include file the contents of that file will not be brought in and compiled, Right?
Click to expand...

Not sure I fully understand your goal here. Sounds like you're trying to save on memory by auto-detecting whether the 1DX or 1YN is attached, and omitting contents for the other, yes? Are you trying to minimize the Teensy's firmware size stored in flash, or the amount of RAM used at runtime?

If you're trying to minimize the firmware size, the only way to do that would be to have the user specify which chip they're using. You have to compile the entire binary file and flash it before the Teensy can ever check what's connected. After that, it can't erase part of the flash memory, you have to completely recompile.

If you're trying to minimize the amount of RAM used, then it's a little more complicated. Does the Teensy execute from flash (XIP), or does it first copy the firmware to RAM and execute from there? If it executes from flash, same problem as above. If it uses XIP, then you just have to be careful in your code to only allocate RAM for whatever chip is detected.

Does that help?
 
@SparkFun - Sorry to confuse you I have my answer. I could not remember if an #included files contents were automatically included even if none of it's contents were used in the code. Answer is no they are not included. that means I can include the firmware files for both the 1YN and 1DX devices and only the firmware arrays associated that detected device will be loaded into flash memory. Some of the firmware array's are very large. I just did not want to take up un-necessary Flash memory. It's all good.
I have everything auto detecting now. No need to change defines for the type of device being used. I also was able to increase the SDHC speed for the 1YN from 33000 to 50000. It seems to work ok with the 1YN shield but not the 1DX board. I assume that might be due to inter connect wires being used possibly. So if the SDHC speed is set to 50000 and we compile for the 1DX board the driver will reduce the SDHC speed to 33000.
Code: 
  // NOTE: The CYW43439 and CYW4343W may have issues at 50'000 KHz clock
  //       speed if using long connecting wires.
  //       If so, reduce to 33'000 in "misc_defs.h".
  //       May be set to 33'000 below if using a CYW4343W device.
  kHzWiFiClk = KHZ_WIFI_CLK; //33'000 or 50'000.

  //Disable GPIO
  enableSDIO(false);
  //Set clock
  setWiFiclk(kHzWiFiClk); <----- Initially we must set the SDHC speed to get our card ID then adjust as necessary below.
  //Enable GPIO
  enableSDIO(true);
#if INIT_DEBUG_MODE == true
  printf(SER_TRACE "SDHC bus set to 4-bit, speed set to %ldMHz\n" SER_RESET, kHzWiFiClk / 1000);
#endif
  //////////////////////////////////////////
  //End Included from SdFat init post CMD7//
  //////////////////////////////////////////
  //Set backplane window
  setBackplaneWindow(BAK_BASE_ADDR);
  u32Data u32d;
  //Read chip ID
  //This was 4 byte read in the Zero code, causes extra bytes in the buffer - only if first CMD53 executed.
  //Changing size to < 4 "fixes" it. Debug code sdio.c 3909 formats value as %4x, so use size 2
  cardCMD53_read(SD_FUNC_BAK, SB_32BIT_WIN, u32d.bytes, 2);
  m_wifi_device = u32d.uint32 & 0xFFFF;
#if INIT_DEBUG_MODE == true
  printf(SER_GREEN "*************\nCardID: %ld\n*************\n" SER_RESET, m_wifi_device);
#endif
  if(REDUCE_CYW4343W_SPEED == true) { // Force speed to 33'00  <---- Forced to 33000
    //Disable GPIO
    enableSDIO(false);
    //Set clock
    setWiFiclk(33000);
    //Enable GPIO
    enableSDIO(true);
  } else if((m_wifi_device == CYW4343W) && (kHzWiFiClk == 50000)) { <--------- else, if CYW4343W and 50000 reduce to 33000
   // Else, check if using a CYW4343W device and if SDHC speed is 50'000
   // and reset to 33'000. This may change if not using interconnect wires.
    //Disable GPIO
    enableSDIO(false);
    //Set clock
    setWiFiclk(33000);
    //Enable GPIO
    enableSDIO(true);
  }
#if INIT_DEBUG_MODE == true
    printf(SER_TRACE "SDHC bus reset to 4-bit, speed set to %dMHz\n" SER_RESET, 33000 / 1000);
#endif

We can also force the lower 33000 speed for both devices by a setting in "misc_defs.h":
Code: 
//==============================================================================
// Choose SDHC speed. 33'000 or 50'000. Default is a safe 33'000.
//==============================================================================
#define KHZ_WIFI_CLK  50000; // Max SDHC speed for CYW4343x may work at 50000 KHz
                             // with short connections to T4.1.
//==============================================================================
// Force reduce SDHC speed to 33'000. true == reduce, false == not reduce.
//==============================================================================
#define REDUCE_CYW4343W_SPEED false

I will push up the changes for testing...
 
Just caught crosspost - but this seems right?
sparkfro said:
minimize the firmware size
Click to expand...

Seems it would be the duplicate firmware. Files I saw are only 2K'ish - if the right ones.
If firmware seems it would stay on flash for transfer during startup?

Though current build of SimpleScan isn't looking huge:
Code: 
Memory Usage on Teensy 4.1:
  FLASH: code:109344, data:253956, headers:8408   free for files:7754756
   RAM1: variables:57760, code:103448, padding:27624   free for local variables:335456
   RAM2: variables:40352  free for malloc/new:483936
 
defragster said:
Just caught crosspost - but this seems right?


Seems it would be the duplicate firmware. Files I saw are only 2K'ish - if the right ones.
If firmware seems it would stay on flash for transfer during startup?

Though current build of SimpleScan isn't looking huge:
Code: 
Memory Usage on Teensy 4.1:
  FLASH: code:109344, data:253956, headers:8408   free for files:7754756
   RAM1: variables:57760, code:103448, padding:27624   free for local variables:335456
   RAM2: variables:40352  free for malloc/new:483936
Click to expand...
There are six firmware files used. Three for each of the devices, Firmware, CLM and NVRAM. the NVRAM files are small around 700 to 800 bytes. The CLM files are 3208 and 7222 bytes. Finally the biggies are 230321 and 419798 bytes. Combined that would be a pretty good hunk of flash memory being un-necessarily used if the contents of all six files were loaded. But as I finally remembered only the contents of the three used files are loaded by the compiler. There will be another firmware file for the Bluetooth as well...
EDIT: Those arrays are uploaded to the WIFI chips and basically used as an operating system. It would be interesting to try and load them from an SD card. Maybe try that later.
 
If the chip type is being detected at runtime, storing both types of firmware in flash is unavoidable. Since if only one firmware is included, what happens when the other type of chip is detected?

I've been struggling a bit dealing with a similar issue, the main problem I have is that the sketch upload time blows out significantly because any tiny little code modification causes a complete reupload to flash, including the hefty firmware, and you find most of your tinker-time is now spent watching the teensy loader progress bar. I can't really think of a "smart" way around this besides a compile-time option to alternatively load the firmware from an SD/USB/LittleFS drive.
 
@jmarsh - You are correct. I just checked and it is pulling in the other three includes data:( With the auto detect version and uploading "SNTPClient.ino" I am seeing:
Code: 
Memory Usage on Teensy 4.1:
  FLASH: code:128944, data:682536, headers:8740   free for files:7306244
   RAM1: variables:59232, code:125136, padding:5936   free for local variables:333984
   RAM2: variables:40352  free for malloc/new:483936
data:682536 - WOW
And without auto detect (originally using defines) I am seeing:
Code: 
Memory Usage on Teensy 4.1:
  FLASH: code:128752, data:254980, headers:8456   free for files:7734276
   RAM1: variables:52064, code:124944, padding:6128   free for local variables:341152
   RAM2: variables:40352  free for malloc/new:483936
data:254980 - Big difference!! over 400000 bytes.

I am not so sure that using auto detection is worth while being that the CYW43439 shield will be the most used device. I mean you are not going to be switching back and forth between the two devices every 5 minutes. Right? Is it worth using auto detection at the expense of over 400KB of flash memory? So I will probably revert back to the original library.
Any comments?
 
wwatson said:
Repo updated.
Click to expand...
Did a sync and build (saved secrets.h) - all good with SimplePING:
Code: 
Memory Usage on Teensy 4.1:
  FLASH: code:123440, data:253956, headers:8648   free for files:7740420
   RAM1: variables:50848, code:119632, padding:11440   free for local variables:342368
   RAM2: variables:40352  free for malloc/new:483936

Good Build of cyw43_scan for ref (same as prior p#313):
Code: 
Memory Usage on Teensy 4.1:
  FLASH: code:109344, data:253956, headers:8408   free for files:7754756
   RAM1: variables:57760, code:103448, padding:27624   free for local variables:335456
   RAM2: variables:40352  free for malloc/new:483936
Will let the SCAN run until some update.

Using a netgear MESH for wifi - wondered why only two sets ... now 3 sets of 3 ... garage needed restart after an outage - it is now showing off/on like the one downstairs about -70 +/- dBm. Neighbors TP-Link -80 to -89 dBm, and TMOBILE high -70's. Scans showing 4-11 Entries - MAX would be 12 - but never all at once.

@sparkfro : FYI antenna PCB versus ... [sitting side by side of T_4.1, but reporting more neg -90 dBm?]
WiFi Scan with ESP32 C6 : Often finds all 12 and mostly at least 10 [7,8,9 not as frequent as 11-12] - using the onboard component antenna shown here:
 
wwatson said:
@gigapod - Unfortunately I have had no experience with Bluetooth yet but I am getting ready to start exploring it. I know that there has been work done here on the forum with USBHost_36 and Bluetooth. Mostly joysticks and such I think...
Click to expand...
You guys were busy last night. Just cataching up.

Its been a while since I developed anything new for USBHost but I do remember that @KurtE had modified the Arduino_BLE library to work with the Teensy 3.6/4 USBHost: https://github.com/KurtE/ArduinoBLE/commits/Teensy_USBHost/. Might take a look at that for ideas.

EDIT: https://github.com/Infineon/bluetooth-freertos/blob/master/platform/include/cybt_platform_config.h
The current versions of ArduinoBLE suuport the zephyr implementation which pulls in the transport layer from zephryr
 
Last edited:
mjs513 said:
Its been a while since I developed anything new for USBHost but I do remember that @KurtE had modified the Arduino_BLE library to work with the Teensy 3.6/4 USBHost: https://github.com/KurtE/ArduinoBLE/commits/Teensy_USBHost/. Might take a look at that for ideas.
Click to expand...
Been a long time ago on some of this as well. The USBHost support was sort of hacky. More or less imbedded a USBHost loop inside of
it... The last time I touched this library was with you and facchinm to get it to work with Zephyr on the C33?

On USBHost, I don't think we ever did any BLE support only older style Bluetooth, so for example the XBox one if updated later to
more recent firmwares would no longer work, likewise had a few Mice that only works with BLE...
 
@defragster - As far as signal strength goes there are settings in the NVRAM firmware file where that can be adjusted but one must be careful as you can actually damage the chip if you go to high with the settings as well as violating FCC regulations for the US. See post #296 towards the bottom of the post. Also the ESP32C6 is probably using a different type of antenna setup as you mentioned.
I will look at different NVRAM examples (there are quite a few) and see if we can adjust the settings in our NVRAM file.
Here is what the NVRAM file looks like:
Code: 
/*
 * $ Copyright Broadcom Corporation $
 */

/**
 * Character array of NVRAM image
 * Generated from cyw943439wlpth_rev1_0.txt
 */

const uint8_t wifi_nvram_9[] =
        "NVRAMRev=$Rev$"                                                     "\x00"
        "manfid=0x2d0"                                                       "\x00"
        "prodid=0x0727"                                                      "\x00"
        "vendid=0x14e4"                                                      "\x00"
        "devid=0x43e2"                                                       "\x00"
        "boardtype=0x0887"                                                   "\x00"
        "boardrev=0x1100"                                                    "\x00"
        "boardnum=22"                                                        "\x00"
        "macaddr=00:A0:50:b5:59:5e"                                          "\x00"
        "sromrev=11"                                                         "\x00"
        "boardflags=0x00404001"                                              "\x00"
        "boardflags3=0x04000000"                                             "\x00"
        "xtalfreq=37400"                                                     "\x00"
        "nocrc=1"                                                            "\x00"
        "ag0=255"                                                            "\x00"
        "aa2g=1"                                                             "\x00"
        "ccode=ALL"                                                          "\x00"
        "pa0itssit=0x20"                                                     "\x00"
        "extpagain2g=0"                                                      "\x00"
        "pa2ga0=-168,7161,-820"                                              "\x00"
        "AvVmid_c0=0x0,0xc8"                                                 "\x00"
        "cckpwroffset0=5"                                                    "\x00"
        "maxp2ga0=84"                                                        "\x00"
        "txpwrbckof=6"                                                       "\x00"
        "cckbw202gpo=0"                                                      "\x00"
        "legofdmbw202gpo=0x66111111"                                         "\x00"
        "mcsbw202gpo=0x77711111"                                             "\x00"
        "propbw202gpo=0xdd"                                                  "\x00"
        "ofdmdigfilttype=18"                                                 "\x00"
        "ofdmdigfilttypebe=18"                                               "\x00"
        "papdmode=1"                                                         "\x00"
        "papdvalidtest=1"                                                    "\x00"
        "pacalidx2g=45"                                                      "\x00"
        "papdepsoffset=-30"                                                  "\x00"
        "papdendidx=58"                                                      "\x00"
        "ltecxmux=0"                                                         "\x00"
        "ltecxpadnum=0x0102"                                                 "\x00"
        "ltecxfnsel=0x44"                                                    "\x00"
        "ltecxgcigpio=0x01"                                                  "\x00"
        "il0macaddr=00:90:4c:c5:12:38"                                       "\x00"
        "wl0id=0x431b"                                                       "\x00"
        "deadman_to=0xffffffff"                                              "\x00"
        "muxenab=0x11"                                                      "\x00"<---- Select Wake_ON_LAN and WAKE_ON_BLE
//        "muxenab=0x100"                                                      "\x00"
        "spurconfig=0x3"                                                     "\x00"
        "glitch_based_crsmin=1"                                              "\x00"
        "btc_mode=1"                                                         "\x00"
        "\x00\x00";

You will not get consistent scans. They will vary scan to scan. Sites will pop up randomly the disappear on the next scan. I get the same thing when doing scans on my laptop and desktops...
 
I had previously mentioned that the aerial should not be shrouded by the SD Card reader. I notice that the aerial is printed past the SD Reader hardware on the T4.1, but not past an SD card actually in the reader. I suggest some tests be carried out to confirm that having an SD Card in the reader slot does not degrade signal strength/data throughput.
 
You must log in or register to reply here.
Back
Top