Forum Rule: Always post complete source code & details to reproduce any issue!
Page 7 of 7 FirstFirst ... 5 6 7
Results 151 to 172 of 172

Thread: Teensy 4.1 - Adafruit Airlift Featherwing Co-Processor FTP Server not opening Port 21

  1. #151
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,225
    Quote Originally Posted by khoih-prog View Post
    HI @mjs513

    That's good news. As I suspect, the xfer bug affects 2-ways in WiFiNINA. We already fixed just 1-way, now still have to find out and fix the other way.

    Sorry, have no time now. Can you use FTPClient_Generic as Client to test? FileZilla still has elusive issue with FTPServer

    Could you test the WiFiNINA_Generic as simple WebServer / WebClient to see if OK to xfer large files? We have to fix from here first.
    Had some time so first thing I wanted to check was WiFiNINA_Generic:
    1. Running WifiWebServer - does not work can make a connection to the T4.1/Airlift
    2. Running the WebClient sketch succeeds:

    Code:
    Starting connection to server...
    Connected to server
    HTTP/1.1 200 OK
    Date: Tue, 24 May 2022 19:20:51 GMT
    Content-Type: text/plain
    Content-Length: 2263
    Connection: close
    x-amz-id-2: 5fRMcJZFj9KYfrjUxC5J54aYUZqXBVnOgfRViHoUCej/EEwBXM5AX93GSDOr2v5xRa6wxn6GQTg=
    x-amz-request-id: 3PQ556NK58MDDWKY
    Last-Modified: Wed, 23 Feb 2022 14:56:42 GMT
    ETag: "667cf48afcc12c38c8c1637947a04224"
    CF-Cache-Status: DYNAMIC
    Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=ViUdmpAPdmo0AE8I9vh%2FJ97LZmBG8pmvRmWcA8K7Ai4xffBcQ61Y7pk6EAQzofTeaA0XmwDLxOVCM3OYpV5Qgpmly0M2dxNxJqziEvep5sLoSsrbgsBn255QIeF2LgA%3D"}],"group":"cf-nel","max_age":604800}
    NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
    Server: cloudflare
    CF-RAY: 710864191bb1b0a6-ATL
    alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
    
    
               `:;;;,`                      .:;;:.           
            .;;;;;;;;;;;`                :;;;;;;;;;;:     TM 
          `;;;;;;;;;;;;;;;`            :;;;;;;;;;;;;;;;      
         :;;;;;;;;;;;;;;;;;;         `;;;;;;;;;;;;;;;;;;     
        ;;;;;;;;;;;;;;;;;;;;;       .;;;;;;;;;;;;;;;;;;;;    
       ;;;;;;;;:`   `;;;;;;;;;     ,;;;;;;;;.`   .;;;;;;;;   
      .;;;;;;,         :;;;;;;;   .;;;;;;;          ;;;;;;;  
      ;;;;;;             ;;;;;;;  ;;;;;;,            ;;;;;;. 
     ,;;;;;               ;;;;;;.;;;;;;`              ;;;;;; 
     ;;;;;.                ;;;;;;;;;;;`      ```       ;;;;;`
     ;;;;;                  ;;;;;;;;;,       ;;;       .;;;;;
    `;;;;:                  `;;;;;;;;        ;;;        ;;;;;
    ,;;;;`    `,,,,,,,,      ;;;;;;;      .,,;;;,,,     ;;;;;
    :;;;;`    .;;;;;;;;       ;;;;;,      :;;;;;;;;     ;;;;;
    :;;;;`    .;;;;;;;;      `;;;;;;      :;;;;;;;;     ;;;;;
    .;;;;.                   ;;;;;;;.        ;;;        ;;;;;
     ;;;;;                  ;;;;;;;;;        ;;;        ;;;;;
     ;;;;;                 .;;;;;;;;;;       ;;;       ;;;;;,
     ;;;;;;               `;;;;;;;;;;;;                ;;;;; 
     `;;;;;,             .;;;;;; ;;;;;;;              ;;;;;; 
      ;;;;;;:           :;;;;;;.  ;;;;;;;            ;;;;;;  
       ;;;;;;;`       .;;;;;;;,    ;;;;;;;;        ;;;;;;;:  
        ;;;;;;;;;:,:;;;;;;;;;:      ;;;;;;;;;;:,;;;;;;;;;;   
        `;;;;;;;;;;;;;;;;;;;.        ;;;;;;;;;;;;;;;;;;;;    
          ;;;;;;;;;;;;;;;;;           :;;;;;;;;;;;;;;;;:     
           ,;;;;;;;;;;;;;,              ;;;;;;;;;;;;;;       
             .;;;;;;;;;`                  ,;;;;;;;;:         
                                                             
                                                             
                                                             
                                                             
        ;;;   ;;;;;`  ;;;;:  .;;  ;; ,;;;;;, ;;. `;,  ;;;;   
        ;;;   ;;:;;;  ;;;;;; .;;  ;; ,;;;;;: ;;; `;, ;;;:;;  
       ,;:;   ;;  ;;  ;;  ;; .;;  ;;   ,;,   ;;;,`;, ;;  ;;  
       ;; ;:  ;;  ;;  ;;  ;; .;;  ;;   ,;,   ;;;;`;, ;;  ;;. 
       ;: ;;  ;;;;;:  ;;  ;; .;;  ;;   ,;,   ;;`;;;, ;;  ;;` 
      ,;;;;;  ;;`;;   ;;  ;; .;;  ;;   ,;,   ;; ;;;, ;;  ;;  
      ;;  ,;, ;; .;;  ;;;;;:  ;;;;;: ,;;;;;: ;;  ;;, ;;;;;;  
      ;;   ;; ;;  ;;` ;;;;.   `;;;:  ,;;;;;, ;;  ;;,  ;;;;

  2. #152
    Senior Member
    Join Date
    Jan 2020
    Location
    Toronto, Canada
    Posts
    132
    I've some simple tests here and :

    1. WiFiNINA and WiFiNINA_Generic are working OK with Nano_33_IoT and Nano_RP2040_Connect (using arduino-pico core) running WiFiWebServer. Using mbed_rp2040 core => Nano_RP2040_Connect crashes while using either WiFiNINA and WiFiNINA_Generic (so terrible unreliable Arduino core now)
    2. WiFiWebClientRepeating is running OK with either WiFiNINA or WiFiNINA_Generic and either core mbed_rp2040 or arduino-pico

    So, can you check using T4.1 + Featherwing with Adafruit WiFiNINA + WiFiWebServer to see if this is hardware, pin / wiring / config issue. Then we can moving on to locate where the issue is,

    My future plan for FTP_Server will be using high level WiFiWebServer library calls, such as send(), etc.

  3. #153
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    720
    Quote Originally Posted by khoih-prog View Post
    I've some simple tests here and :

    1. WiFiNINA and WiFiNINA_Generic are working OK with Nano_33_IoT and Nano_RP2040_Connect (using arduino-pico core) running WiFiWebServer. Using mbed_rp2040 core => Nano_RP2040_Connect crashes while using either WiFiNINA and WiFiNINA_Generic (so terrible unreliable Arduino core now)
    2. WiFiWebClientRepeating is running OK with either WiFiNINA or WiFiNINA_Generic and either core mbed_rp2040 or arduino-pico

    So, can you check using T4.1 + Featherwing with Adafruit WiFiNINA + WiFiWebServer to see if this is hardware, pin / wiring / config issue. Then we can moving on to locate where the issue is,

    My future plan for FTP_Server will be using high level WiFiWebServer library calls, such as send(), etc.
    Just got home and have about an hour to setup and test. Will let you know how it turns out. Thanks for the info. Testing with the WiFiWebServer makes sense to isolate any hardware issues...

  4. #154
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,225
    Quote Originally Posted by khoih-prog View Post
    I've some simple tests here and :

    1. WiFiNINA and WiFiNINA_Generic are working OK with Nano_33_IoT and Nano_RP2040_Connect (using arduino-pico core) running WiFiWebServer. Using mbed_rp2040 core => Nano_RP2040_Connect crashes while using either WiFiNINA and WiFiNINA_Generic (so terrible unreliable Arduino core now)
    2. WiFiWebClientRepeating is running OK with either WiFiNINA or WiFiNINA_Generic and either core mbed_rp2040 or arduino-pico

    So, can you check using T4.1 + Featherwing with Adafruit WiFiNINA + WiFiWebServer to see if this is hardware, pin / wiring / config issue. Then we can moving on to locate where the issue is,

    My future plan for FTP_Server will be using high level WiFiWebServer library calls, such as send(), etc.
    And @wwatson

    First I had to modify the advanced webserver sketch to work with the adafruit WiFiNINA library:
    AdvancedWebServer-220524a.zip

    in the serial monitor after connection I see:
    Code:
    Starting AdvancedWebServer on TEENSY 4.1/4.0 with Custom WiFi using Custom WiFi Library
    WiFiWebServer v1.8.0
    Connecting to WPA SSID: ......
    
    Connecting to WPA SSID: .....
    HTTP server started @ ............
    H[WIFI] String Len = 0, extend to 2048
    in firefox:
    Click image for larger version. 

Name:	Capture.PNG 
Views:	1 
Size:	24.4 KB 
ID:	28473

    The browser updates about 4 or 5 times then looses the connection and I can not reconnect without reset the Teensy.

  5. #155
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    720
    @mjs513, @khoih-prog - Got everything setup in WiFiNINA_Generic as per p#147. Had the same result as Mike did. Connects but hangs waiting for the welcome message. We ran into this before and I will have to look back and see what we did to resolve it. Running out of time to test further tonight. Tomorrow will check it out further. I live for the weekends when I have time to play

  6. #156
    Senior Member
    Join Date
    Jan 2020
    Location
    Toronto, Canada
    Posts
    132
    @mjs513,

    It seems that there is some severe issue when using T4.1 + Featherwing + even Adafruit WiFiNINA; now you have to check if we still have the same issue with any other board you have (SAMD, nRF52, RP2040, etc.) + Featherwing. My wild guess is possibly some conflict / (Teensy core or WiFiNINA library) bug when using T4.1 + Featherwing ???

    I believe now we need the help of @PaulStoffregen or somebody having the same hardware to locate the bug.

    I'm testing the AdvancedWebServer OK with Nano_33_IoT and Nano_RP2040_Connect using WiFiNINA_Generic

    Click image for larger version. 

Name:	Selection_015.png 
Views:	1 
Size:	41.3 KB 
ID:	28474

    Click image for larger version. 

Name:	Selection_014.png 
Views:	0 
Size:	42.1 KB 
ID:	28475

  7. #157
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,225
    Quote Originally Posted by khoih-prog View Post
    @mjs513,

    It seems that there is some severe issue when using T4.1 + Featherwing + even Adafruit WiFiNINA; now you have to check if we still have the same issue with any other board you have (SAMD, nRF52, RP2040, etc.) + Featherwing. My wild guess is possibly some conflict / (Teensy core or WiFiNINA library) bug when using T4.1 + Featherwing ???

    I believe now we need the help of @PaulStoffregen or somebody having the same hardware to locate the bug.

    I'm testing the AdvancedWebServer OK with Nano_33_IoT and Nano_RP2040_Connect using WiFiNINA_Generic
    ...
    Understood but I just tried using a Adafruit M0 datalogger with the WiFiNINA library and while it connected and show some life it did not show the graph or even try to update - basically just hung:
    Click image for larger version. 

Name:	Capture.jpg 
Views:	1 
Size:	77.0 KB 
ID:	28479

    Did try and get it working with WiFiNINA Generic but could not make a connection to either the T4.1 or the Adafruit M0 board... sorry

  8. #158
    Senior Member
    Join Date
    Jan 2020
    Location
    Toronto, Canada
    Posts
    132
    Hi @mjs513

    It seems that the issue is wider than expected while using Adafruit WiFiNINA.

    Can you check, test to see if this is an SPI conflict / bad SPI-related design (seen with many SD cards) by using SPI1/SPI2 for WiFiNINA with setPins(), such as

    Code:
    #define SPIWIFI       SPI1  // The correct supported SPI port
    
    ...
    
    WiFi.setPins(SPIWIFI_SS, SPIWIFI_ACK, ESP32_RESETN, ESP32_GPIO0, &SPIWIFI);

    If OK, also try if we have similar SPI conflict issue with T4.1.

    Here, Nano_33_IoT has been running AdvancedWebServer for more than 14hrs, and still running

    Click image for larger version. 

Name:	Selection_016.png 
Views:	0 
Size:	40.7 KB 
ID:	28481

  9. #159
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    720
    @mjs513 - @ khoih-prog Well did some more testing after work tonight and SPI is working with WiFiNINA and the T4.1. sendData() and getData() do not have a problem as they are also used for all other file operations with FTP that complete successfully. The only failure is with data.connected(). I can put the same delay(100) in doStore() as in WiFiClient.cpp:
    Code:
    bool FtpServer::doStore()
    {
      // This my hack.
    /*
      uint32_t tmout = millis();
      int na = 0;
      while((millis() - tmout) != 50) {
        na = data.available();
        if(na != 0) break;
      }
      if(na == 0) {
        closeTransfer();
        return false;
      }
    */
      int na = data.available();
    
      if ( na == 0 )
      {
        if ( data.connected())
          return true;
        else
        {
          closeTransfer();
          return false;
        }
      }
    
      if ( na > FTP_BUF_SIZE )
        na = FTP_BUF_SIZE;
    delay(100);
      int16_t nb = data.read((uint8_t *) buf, na );
      int16_t rc = 0;
    
      if ( nb > 0 )
      {
         //FtpDebug << millis() << " " << nb << endl;
        rc = file.write( buf, nb );
        bytesTransfered += nb;
      }
    
      if ( nb < 0 || rc == nb  )
        return true;
    
      FtpOutCli << F("552 Probably insufficient storage space") << endl;
      file.close();
      data.stop();
      closeTransfer();
      return false;
    }
    And get the same result. Fillezilla shows a complete transfer (100%) but the transfer never completes. And at that point the sever on the T4.1 is stuck in an endless loop waiting for data.connected() to change from 1 to 0. Same problem as before with WiFiNINA and WiFiNINA_Generic. The file is never closed so when you reboot the T4.1 and reconnect Filezilla the file that was transfered show 0 bytes. Empty unclosed file. Using NativeEthernet or QNEthernet work perfectly with FTP_Server_Teensy41.

    I hope to try and find the problem with WiFiNINA this weekend. This really has me bugged

  10. #160
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,225
    @wwatson - @ khoih-prog

    Don't think its an SPI issue either since we were able to transfer files in one direction. As for using the AdvancedWebServer - not 100% sure whats going on with that. I just ran the WiFiNINA example WiFiWebServer and it works with out the Browser loosing connection but the interesting thing is how it works:

    Code:
      // listen for incoming clients
      WiFiClient client = server.available();
      if (client) {
        Serial.println("New client");
        // an http request ends with a blank line
        boolean currentLineIsBlank = true;
        while (client.connected()) {
          if (client.available()) {
            char c = client.read();
            Serial.write(c);
            // if you've gotten to the end of the line (received a newline
            // character) and the line is blank, the http request has ended,
            // so you can send a reply
            if (c == '\n' && currentLineIsBlank) {
              // send a standard http response header
              client.println("HTTP/1.1 200 OK");
              client.println("Content-Type: text/html");
              client.println("Connection: close");  // the connection will be closed after completion of the response
              client.println("Refresh: 5");  // refresh the page automatically every 5 sec
              client.println();
              client.println("<!DOCTYPE HTML>");
              client.println("<html>");
              // output the value of each analog input pin
              for (int analogChannel = 0; analogChannel < 6; analogChannel++) {
                int sensorReading = analogRead(analogChannel);
                client.print("analog input ");
                client.print(analogChannel);
                client.print(" is ");
                client.print(sensorReading);
                client.println("<br />");
              }
              client.println("</html>");
              break;
            }
            if (c == '\n') {
              // you're starting a new line
              currentLineIsBlank = true;
            } else if (c != '\r') {
              // you've gotten a character on the current line
              currentLineIsBlank = false;
            }
          }
        }
        // give the web browser time to receive the data
        delay(1);
    
        // close the connection:
        client.stop();
        Serial.println("Client disconnected");
      }
    It basically checks for the client and if available sends its data and then disconnects over and over and it works with the browser loosing connection


    EDIT: @wwatson this may be a hint on how doStor should be working - connect -send data - disconnect - reconnect. Think its forgetting to try to reconnect

  11. #161
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    720
    @mjs513 - @ khoih-prog - Something very peculiar going on. In doRetrieve() I have:
    Code:
      int spaceLeft = data.availableForWrite();
    Did a complete grep of WiFiNINA for "availableForWrite". It was not found. Where is it picking it up from??? That is why doRetrieve() is not working because spaceLeft is always 0...

    The used libraries listed in Arduino after compiling only shows WiFiNINA library. I put in Serial.prints in all of client and server available() functions and using them failed to print.

    I guess I'll start eliminating libraries till FTP_Server_Teensy411 fails to compile...

  12. #162
    Senior Member
    Join Date
    Jan 2020
    Location
    Toronto, Canada
    Posts
    132
    @wwatson,

    I guess you found out the bug when we convert to use WiFiNINA.

    The availableForWrite() is defined in QNEthernet, Ethernet_Generic libraries, etc.

    But in WiFiNINA + Teensy 4.1, it's still a virtual function, always returning 0, and defined in cores/teensy4/Print.h

    Code:
    virtual int availableForWrite(void)		{ return 0; }
    So when you still use availableForWrite() for WiFiNINA, the chain is

    WiFiNINA => WiFiClient => Teensy Client in Client.h => Teensy Stream in Stream.h => Teensy Print in Print.h

    To fix, we have to use correct function to replace this for WiFiNINA.

    Or we can write a new function availableForWrite() for WiFiNINA
    Last edited by khoih-prog; 05-27-2022 at 01:40 AM.

  13. #163
    Senior Member
    Join Date
    Jan 2020
    Location
    Toronto, Canada
    Posts
    132
    @wwatson,

    You can also try using the original doRetrieve() (without availableForWrite()) for WiFiNINA

    We've already fixed the WiFiNINA_Generic Cilent write() function, and hope it's OK to use now

    Code:
    #if USE_WIFI_NINA
    
    bool FtpServer::doRetrieve()
    {
      if ( ! dataConnected())
      {
        file.close();
    
        return false;
      }
    
      int16_t nb = file.read( buf, FTP_BUF_SIZE );
    
      if ( nb > 0 )
      {
        data.write( buf, nb );
        bytesTransfered += nb;
        return true;
      }
    
      closeTransfer();
    
      return false;
    }
    
    #else
    
    bool FtpServer::doRetrieve()
    {
      if ( ! dataConnected())
      {
        file.close();
        
        return false;
      }
      
      // Find available space in data.write() buffer.
      int spaceLeft = data.availableForWrite();
      // Get remaining bytes to read from file.
      int32_t leftToXfer = file.available();
    
      if (spaceLeft <= 0) 
      {
        return true; // Return true if no space available.
      }
    
      // Calculate read size.
      // Base the amount to read on the space available in the
      // data.write() buffer. 
      if (leftToXfer) 
      {
        int32_t nb = file.read( buf,(spaceLeft <= FTP_BUF_SIZE) ? spaceLeft : FTP_BUF_SIZE); 
        data.write(buf, nb);
        bytesTransfered += nb;
        
        return true;
      }
      
      closeTransfer();
      
      return false;
    }
    
    #endif

  14. #164
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    720
    Quote Originally Posted by khoih-prog View Post
    @wwatson,

    You can also try using the original doRetrieve() (without availableForWrite()) for WiFiNINA

    We've already fixed the WiFiNINA_Generic Cilent write() function, and hope it's OK to use now

    Code:
    #if USE_WIFI_NINA
    
    bool FtpServer::doRetrieve()
    {
      if ( ! dataConnected())
      {
        file.close();
    
        return false;
      }
    
      int16_t nb = file.read( buf, FTP_BUF_SIZE );
    
      if ( nb > 0 )
      {
        data.write( buf, nb );
        bytesTransfered += nb;
        return true;
      }
    
      closeTransfer();
    
      return false;
    }
    
    #else
    
    bool FtpServer::doRetrieve()
    {
      if ( ! dataConnected())
      {
        file.close();
        
        return false;
      }
      
      // Find available space in data.write() buffer.
      int spaceLeft = data.availableForWrite();
      // Get remaining bytes to read from file.
      int32_t leftToXfer = file.available();
    
      if (spaceLeft <= 0) 
      {
        return true; // Return true if no space available.
      }
    
      // Calculate read size.
      // Base the amount to read on the space available in the
      // data.write() buffer. 
      if (leftToXfer) 
      {
        int32_t nb = file.read( buf,(spaceLeft <= FTP_BUF_SIZE) ? spaceLeft : FTP_BUF_SIZE); 
        data.write(buf, nb);
        bytesTransfered += nb;
        
        return true;
      }
      
      closeTransfer();
      
      return false;
    }
    
    #endif
    Thank you I did see that it was defined as a virtual function. I am not very good with C++ as you can probably tell or C for that matter. I have run out of time tonight but will regroup this weekend and test...

    Edit - I guess that is why NativeEthernet QNEthernet worked.
    Last edited by wwatson; 05-27-2022 at 02:09 AM. Reason: More Comments...

  15. #165
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,225
    @wwatson - @khoih-prog

    Think I got doStore working with the following changes - this is with SimpleFTPServer if you can give it a try and let me know if it works for you.

    Code:
    bool FtpServer::doStore()
    {
      if( ! dataConnected())
      {
        file.close();
        return false;
      }
    	
      int16_t na = data.available();
      if( na == 0 ) {
    	  DEBUG_PRINTLN("NO DATA AVAILABLE!");
    #if FTP_SERVER_NETWORK_TYPE_SELECTED == NETWORK_SEEED_RTL8720DN || FTP_SERVER_NETWORK_TYPE_SELECTED == NETWORK_WiFiNINA
    	  data.stop();
    #endif
        if( data.connected()) {
          return true;
        } else
        {
          closeTransfer();
          return false;
        }
      }
    
      if( na > FTP_BUF_SIZE ) {
        na = FTP_BUF_SIZE;
      }
      int16_t nb = data.read((uint8_t *) buf, na );
      int16_t rc = 0;
      if( nb > 0 )
      {
    	    DEBUG_PRINT("NB -> ");
    	    DEBUG_PRINTLN(nb);
    
        rc = file.write( buf, nb );
        DEBUG_PRINT("RC -> ");
        DEBUG_PRINTLN(rc);
        bytesTransfered += nb;
    
    	  if (FtpServer::_transferCallback) {
    
    		  FtpServer::_transferCallback(FTP_UPLOAD, getFileName(&file), bytesTransfered);
    	  }
      }
      if( nb < 0 || rc == nb  ) {
        return true;
      }
      client.println(F("552 Probably insufficient storage space") );
      file.close();
      data.stop();
      return false;
    }

  16. #166
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,225
    @wwatson
    Just a followup to my previous post - did some more testing and seems like uploading files >500K fail for the most part. Havent found the issue yet

  17. #167
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    720
    Quote Originally Posted by mjs513 View Post
    @wwatson
    Just a followup to my previous post - did some more testing and seems like uploading files >500K fail for the most part. Havent found the issue yet
    Hi Mike,

    Been working on this all week. Today I have everything working. But to get downloads from the T4.1 to the PC I had to do a hack. The problem is WiFiNINA is not setup to check if a transfer from the T4.1 has completed or not. As stated in an above post, it does not have an 'availableForWrite()' function. The T4.1 keeps overrunning the buffer. 'data.write()' returns the number of bytes actually written. So between that and having to add a delay it's working. The problem with the delay is that it slows down the transfer rate. I can transfer a 32Meg file to completion

    I found out that nina-fw is based on the same WiFi library that I was using for the ESP8266:
    https://github.com/JiriBilek/WiFiSpiESP

    and here:
    https://github.com/JiriBilek/WiFiSpi

    I will clean up the mess with the code and attach the zip files for testing.

    Next is simpleFTPServer. But I need to walk away from this for a bit

  18. #168
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,225
    Quote Originally Posted by wwatson View Post
    Hi Mike,

    Been working on this all week. Today I have everything working. But to get downloads from the T4.1 to the PC I had to do a hack. The problem is WiFiNINA is not setup to check if a transfer from the T4.1 has completed or not. As stated in an above post, it does not have an 'availableForWrite()' function. The T4.1 keeps overrunning the buffer. 'data.write()' returns the number of bytes actually written. So between that and having to add a delay it's working. The problem with the delay is that it slows down the transfer rate. I can transfer a 32Meg file to completion

    I found out that nina-fw is based on the same WiFi library that I was using for the ESP8266:
    https://github.com/JiriBilek/WiFiSpiESP

    and here:
    https://github.com/JiriBilek/WiFiSpi

    I will clean up the mess with the code and attach the zip files for testing.

    Next is simpleFTPServer. But I need to walk away from this for a bit
    Thanks for the info. Kind of figure the availableforwrite just now when I was looking at the ESP8266 core. But I have been working on this so long I need a break - about ready to give up.

  19. #169
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    720
    @ mjs513 - Well here they are:

    Got SimpleFTPServer working as well. Just remember 'doRetrieve() and doStore()' are hacked as a workaround. In Filezilla with FTP_Server_T41 both passive and active modes work. SimpleFTPServer only works in active mode. Also Filezilla needs to have the connection limit set to 1 and the checkbox needs to be checked.
    Again when you disconnect from the FTP servers you need to reset the T4.1 or wait for the servers to timeout and disconnect the client. Haven't had time to find out why yet. There is a delay in 'doRetrieve()' function (part of the hack) the is set to 50. This can be played with. Lastley, you need to use a computer with WiFi capabilities. I tried to connect with Ethernet through my router to the T4.1 with the Adafruit Airlift Featherwing and it would not connect. I'm sure there is a way but I don't know how.

    I also included my nina firmware bin file.

    Hopefully I remembered everything Good luck testing...

    EDIT: The transfer speeds are really slow. Running about 240KB/s. With QNEthernet or NativeEthernet it's 1-2 MB/s. Curious to see what you get. I have a fairly old D-Link WiFi router. That could also be a problem. I tried setting FTP_BUF_SIZE to 2048 and 8192 to it helps a little but then the transfers become unstable. The best results are with FTP_BUF_SIZE set to 1500 and the delays set to 45-50. Going to take a break from this and update to the latest USBHost_t36 developments. Then start playing with WiFiNINA_Generic and nina_fw. By the way I am using Arduino 1.8.19 and TD1.57B1 with out the patches to cores or boards.txt.
    Attached Files Attached Files
    Last edited by wwatson; 05-30-2022 at 01:41 AM. Reason: More Info...

  20. #170
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,225
    Quote Originally Posted by wwatson
    EDIT: The transfer speeds are really slow. Running about 240KB/s. With QNEthernet or NativeEthernet it's 1-2 MB/s. Curious to see what you get. I have a fairly old D-Link WiFi router. That could also be a problem. I tried setting FTP_BUF_SIZE to 2048 and 8192 to it helps a little but then the transfers become unstable. The best results are with FTP_BUF_SIZE set to 1500 and the delays set to 45-50. Going to take a break from this and update to the latest USBHost_t36 developments. Then start playing with WiFiNINA_Generic and nina_fw. By the way I am using Arduino 1.8.19 and TD1.57B1 with out the patches to cores or boards.txt.
    Started with SimpleFTPServer and seemed to work with files up to about 6MB but then looked at your code changes to doStore and since I can not leave well enough alone changed this
    Code:
      // This my hack.
      uint32_t tmout = millis();
      int na = 0;
      while((millis() - tmout) != 50) {
        na = data.available();
        if(na != 0) break;
      }
    to this
    Code:
      // This my hack.
      uint32_t tmout = millis();
      int na = 0;
      while((millis() - tmout) != 500) {
        na = data.available();
        if(na != 0) break;
      }
    and was able to transfer a 94mb from the T4.1 to the PC. Transfer rates using 1500 was about 310Kbytes/second.

    I am using the modified versions of the nina-fw.bin and wifnina libraries that we did earlier and of course using Arduino 1.8.19 and TD1.57B1 with out the patches to cores or boards.txt same as you. Probably will change to 2048 from 1500 though.

    EDIT: If you want to DISCONNECT the T4.1 from fileZilla do the following:
    Server => Enter Custom Command => type QUIT in the box and it will disconnect

  21. #171
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    720
    Quote Originally Posted by mjs513 View Post
    Started with SimpleFTPServer and seemed to work with files up to about 6MB but then looked at your code changes to doStore and since I can not leave well enough alone changed this
    Code:
      // This my hack.
      uint32_t tmout = millis();
      int na = 0;
      while((millis() - tmout) != 50) {
        na = data.available();
        if(na != 0) break;
      }
    to this
    Code:
      // This my hack.
      uint32_t tmout = millis();
      int na = 0;
      while((millis() - tmout) != 500) {
        na = data.available();
        if(na != 0) break;
      }
    and was able to transfer a 94mb from the T4.1 to the PC. Transfer rates using 1500 was about 310Kbytes/second.

    I am using the modified versions of the nina-fw.bin and wifnina libraries that we did earlier and of course using Arduino 1.8.19 and TD1.57B1 with out the patches to cores or boards.txt same as you. Probably will change to 2048 from 1500 though.

    EDIT: If you want to DISCONNECT the T4.1 from fileZilla do the following:
    Server => Enter Custom Command => type QUIT in the box and it will disconnect
    Thanks for testing. Will try out your changes today. At least it is working for now

  22. #172
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,225
    Quote Originally Posted by wwatson
    Thanks for testing. Will try out your changes today. At least it is working for now
    Ditto here - was getting a bit frustrated.

    DELETED ORIGINAL

    UPDATE:
    Was getting really frustrated so glad you got it working.

    Anyway, made the same changes to FTP_Server_T41 and configured a new site in Filezilla and seems to working, maybe a bit slower on the transfers but both seem to be working.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •