Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
10 years, 2 months ago.
CC3000 blocking behavior
I guess related to: http://mbed.org/questions/2196/cc3000-TCPSocketServeraccept-timeout/, but either it isn't working properly, or I don't get it.
I observed this in my own code, but also verified it with: http://mbed.org/users/Kojto/code/cc3000_tcp_server_demo/
By default, and when blocking is specifically set on true, it doesn't seem to block at all, and the serial terminal is showing alot of code, but besides that it does work properly. If I put it on false + a timeout, it waits for that timeout, but it never receives anything.
That it works inverted from what I would expect seems to make sense looking at the TCPSocketConnection receive code:
if (!_blocking) { TimeInterval timeout(_timeout); if (wait_readable(timeout) != 0) return -1; }
So if _blocking (which is equal to what set_blocking sets) is true, it won't block for that timeout period. Either I am missing something, or something is flipped around there.
Problem two then however is that when set to false, it never accepts any connection. I checked the wait_readable function, which in turns calls:
int ret = _cc3000_module->_socket.select(_sock_fd+1, readset, writeset, NULL, timeout);
This function is called correct as far as I can see, but it never returns anything but zero when I enable debug information.
So I wonder if I am missing something, or the blocking parameter is inverted, and if it is blocking (for a certain timeout), it doesn't seem to properly work for me (at least for the TCPSocketServer).
Question relating to:
1 Answer
9 years, 8 months ago.
Picking up this old topic.
I reworked the cc3000_tcp_server_demo a little to stop it from continuously printing and to prevent calls to set_blocking when no connection is made (the timeout can only be started when a connection is made = server.accept status >= 0).
It works fine but i noticed the real timeout time is about 4 times longer than the declared timeout (int this case, 6 seconds instead of 1.5 seconds).
#include "mbed.h" #include "cc3000.h" #include "main.h" #include "TCPSocketConnection.h" #include "TCPSocketServer.h" using namespace mbed_cc3000; /* cc3000 module declaration specific for user's board. Check also init() */ #if (MY_BOARD == WIGO) cc3000 wifi(PTA16, PTA13, PTD0, SPI(PTD2, PTD3, PTC5), "ssid", "key", WPA2, false); Serial pc(USBTX, USBRX); #elif (MY_BOARD == WIFI_DIPCORTEX) cc3000 wifi(p28, p27, p30, SPI(p21, p14, p37), "ssid", "key", WPA2, false); Serial pc(UART_TX, UART_RX); #elif (MY_BOARD == MBED_BOARD_EXAMPLE) cc3000 wifi(p9, p10, p8, SPI(p5, p6, p7), "ssid", "key", WPA2, false); Serial pc(USBTX, USBRX); #else #endif int main() { init(); /* board dependent init */ pc.baud(115200); printf("cc3000 tcp server demo. \r\n"); wifi.init(); if (wifi.connect() == -1) { printf("Failed to connect. Please verify connection details and try again. \r\n"); } else { printf("IP address: %s \r\n", wifi.getIPAddress()); } const int ECHO_SERVER_PORT = 1895; TCPSocketServer server; TCPSocketConnection client; server.bind(ECHO_SERVER_PORT); server.listen(); printf("\r\nWait for new connection...\r\n"); while (true) { // set_blocking timeout will only occur when a connection is accepted => only act when accept status > 0 int32_t status = server.accept(client); if (status >= 0) { client.set_blocking(false, 1500); // Timeout after (1.5)s printf("Connection from: %s \r\n", client.get_address()); char buffer[256]; while (true) { int n = client.receive(buffer, sizeof(buffer)); if (n <= 0) break; client.send_all(buffer, n); if (n <= 0) break; } client.close(); printf("\r\nWait for new connection...\r\n"); } } }
I don't recall much details, have to look at sources later. It can be inverted..
There were bugs reported for cc3000 , so it's always good to look at TI forum, if some specific non-functional feature has been already fixed or not.
posted by Martin Kojtal 01 Sep 2014