Wi-Fi Combo Forum Discussions
text.format{('custom.tabs.no.results')}
From the monitoring tools I see in an RFCOMM connection between the WICED and an Android phone, the RFCOMM server on the WICED grants only 1 credit but when I monitored an RFCOMM link between two Android phones I see that the server on one of the Android phone is granting 6 credits to the other Android phone. More credit means more back to back transmission; 6 credit corresponds to the transmission of 6 packets back to back. More back to back transmission can improve the overall throughput.
A credit represents the number of packets that a device can send at a time. Each packet transmission uses a credit, when the credit reaches zero the receiver must grant more credit in order to enable the transmitter to send more packets.
Since the RFCOMM is a credit based protocol what parameter needs to be modified in the WICED studio to increase the RFCOMM credit? Certainly there is an upper limit for the credit, but currently it is set to 1. There should be some room to tune it higher than 1.
The Android phones are using the Broadcom Wifi/BT chips which is similar to the Cypress reference design.
Thanks.
Show LessThe module I am using is the EMW3162, which consists of STM32F205 and CYW43362.
When I use the TFTP example, the test file transfer speed is about 100KByte/s, but I hope the speed can reach 2Mbyte/s. What should I do?
I use the iperf example to test UDP throughput of about 18Mbps and TCP throughput of 12Mbps. Is this normal? Can CYW43362 not work at 72Mbps?
Can someone help me, thank you.
Show LessHello,
We're thinking to use CYW54907. And i‘m considering how we would mount such small-pitch component. In component datasheet specified to look at document Broadcom „Wafer-scahle chip-sized package overview and assembly guidelines for design, implementation, and manufacturing recommendations and guidelines“ (document number PACKAGING-AN3vv-R). But i can‘t find this document. Where can i get this component? Also need final datasheet with all mounting, soldering guidelines for CYW54907, becasuse datasheet (you can check it in attachment) provided in the net is preliminar.
Show LessAs a follow on to this thread here: Re: SPI DMA and memory to memory DMA example for CYW43907
By using 43907, SPI DMA as well as memory to memory DMA is not possible in application layer. Actually, my application is moving lots of data from SPI then on the internet. Is 43907 suitable for such application ? Or, any other methods using 43907 or other chips that can recommended ?
Thanks.
Show LessI found the system time is inaccurate, it's slower...
Here is how I test it: (Test with freeRTOS build)
1. The sntp sync will set and print the new time
So I add below code to show the time before updating by sntp:
--- a/43xxx_Wi-Fi/libraries/protocols/SNTP/sntp.c
+++ b/43xxx_Wi-Fi/libraries/protocols/SNTP/sntp.c
@@ -318,7 +318,10 @@ wiced_result_t sync_ntp_time( void* arg )
else
{
wiced_utc_time_ms_t utc_time_ms = (uint64_t)current_time.seconds * (uint64_t)1000 + ( current_time.microseconds / 1000 );
+ wiced_iso8601_time_t old_iso8601_time;
+ wiced_time_get_iso8601_time( &old_iso8601_time );
+ WPRINT_LIB_INFO( ("Old time is: %.27s\n", (char*)&old_iso8601_time) );
/* Set & Print the time */
wiced_time_set_utc_time_ms( &utc_time_ms );
2. Build snip.sntp_get_time with below changes:
A simple test is change TIME_SYNC_PERIOD to (1 * days) and check the timestamp output after 1 day.
3. A more practice test is adding below code to your real projects:
sntp_start_auto_time_sync( TIME_SYNC_PERIOD );
What I observed is seconds to minutes diff shown by Old time and Current time.
Show LessOur product uses an STM32F4xx with the 4343W chip. And our firmware uses ThreadX and NetX.
We have the firmware ported and running on every Wiced SDK version from 4.0 up to the most recent 6.2.
BUT we recently discovered that as of v6.1 (where NetX changed from 5.5 to 5.10), we are now getting spontaneous TCP disconnects from the NetX library.
More specifically, we have code that sits in a loop and does a simple get against our server every 3 seconds. Our code built with v6.0 works very reliably and will run that loop all day if we let it. Same code updated for v6.1 (no significant API changes) makes it through the first minute or two of such gets, but eventually we get the internal_wiced_tcp_disconnect_socket_callback() callback from NetX. And the socket stays down for between 20 seconds and 2 minutes, and then reconnects and starts working again.
We have checked the server is sending keep-alive, and we have checked our server logs and see no difference between the working 6.0 case and the failing 6.1 case. We have also reviewed all the applicable (visible) diffs for libraries/protocols/HTTP_client and WICED/network (particularly NetX) and have not found any changes that seem related.
Has anyone else encountered (and hopefully debugged) this issue?
I should add that we've checked and the issue is still there in SDK v6.2.x.
Show Less- SDK: WICED-SDK 6.2
- USBX: Ver5.8
We're trying to use the CYW43907's USB function as a USB ethernet device, and we found USBX supports the USB-CDC-ECM class (wiced-sdk\libraries\drivers\USB\USBX\ver5.8\usbx_device_classes\ux_device_class_cdc_ecm.h)
But when we add the code to compile with these APIs, some error happens.
Cannot found #include "ux_network_driver.h"
Cannot found the reference for "_ux_device_class_cdc_ecm_entry"
It seems the USBX library in WICED-SDK is a lite version, not contained these functions.
How we can get a full function USBX library to support this USB-CDC-ECM?
Show LessHello
I have upgraded the SDK from 5.0 to 6.1 and It adds ~100k bytes of data in the micro-controller without explanation.
Can some one help me out to understand the usage of MBEDTLS as it occupies lot of space on my hardware ?
Can I reduce it ?
Module WICED 5.0 :
Module 6.1
Show Less