[wless.ru 0]

Как известно, в ближайшее время Atmel собирается выпустить на рынок несколько продуктов из серии Wi-Fi, Wi-Fi+MCU, Wi-Fi+BT. Первым таким продуктом, доступным на нашем рынке, стала микросхема ATWINC1500 и модуль на её основе.

Так как не вся документация пока полностью вылизана, есть предложение обсуждать возникающие вопросы в отдельной теме.

Здесь будем выкладывать доступную документацию.

В общем, добро пожаловать :)

Edited April 16, 2015 by WLESS.RU

[Rash 0]

Возможно ли через данный модуль передавать данные по эфиру минуя TCP-IP. Т.е. использовать его как обычный приёмопередатчик со своим протоколом общения.

[ataradov 0]

Возможно ли через данный модуль передавать данные по эфиру минуя TCP-IP. Т.е. использовать его как обычный приёмопередатчик со своим протоколом общения.

Нет. Железо в теории может, но прошивка не позволяет. WILC1000 - это сырой чип, через него можно, но он и сложнее значительно.

[Rash 0]

WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.

[ataradov 0]

WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.

WILC1000 поддерживается ядром Linux, а делать к нему драйверы с нуля - это с ума сойти можно. Не думаю, что к нему будут примеры для обычных МК.

 

[Rash 0]

Можно забрать драйвера из линукса и вставить в свой проект, было бы описание регистров модуля. Дело в том, что мне не нужен WIFI в чистом виде. Для этого есть более простые китайские решения, готовые модули подключаемые по RMII интерфейсу за 10-15$. Меня больше интересует высокоскоростные радиопередатчики и WIFI модули в это прекрасно попадают, но на них нет полноценной документации.

 

Объясню для чего нужно. Сейчас проект построен на базе АТ86RF212 условно на скорости 250 кбит/сек. Пользуясь опытом LwMesh написан свой стек для маршрутизации и передачи. Ходят как данные, так и голос (в закодированном виде до 2.4кбит/сек). Для хорошей ретрансляции расстановка маршрутизаторов такая, что они имеют перекрытия друг с другом от 4 до 6 роутеров. Эти перекрытия влияют на скорость обмена, что реальная скорость падает в 5-6 раз. И таким образом больше 2-х голосовых каналов получить не получается. Можно уйти на скорость 500 или 1 Мбит, что позволит иметь больше одновременных голосовых каналов, но это количество тоже не велико думаю больше 5-6 не будет. Можно попытаться резать слабый уровень настройками PDT в АТ86RF212, что бы уменьшить взаимное влияние перекрывающихся роутеров но всё равно будут коллизии. Основная проблема АТ86RF212 нет разделённого управляемого буфера RX и TX, для минимизации потерь в радиоканале. Есть ещё вариант сделать на 2-х АТ86RF212 разделённый буфер, используя одну как передатчик, другую как приёмник, но это усложнение схемотехники и сейчас враги в виде старшего руководства не дадут так сделать.

Такой канал построен на 70 устройствах в радио сети и работает в подземных тяжёлых условиях.

 

Или допустим взять высокоскоростной WIFI модуль хотя бы на 54Мбит, разделив эту скорость даже на 10, чтобы получить чистые данные, наложить туда свою логику работы, естественно с оверхедом WIFI, то это уже другая история. Можно протянуть будет такой проект.

 

 

[ataradov 0]

Не думаю, что использование голого Wi-Fi железа для своих целей - эта такая уж хорошая идея. Если нормально не реализовывать стандарт, то все окружающие устройства будут мешать вам, а вы - им.

 

Ну и дальность на 54 mbps тоже оставляет желать лучшего.

[Rash 0]

дальность решается антеннами и усилителем, в последнем случае с учитывая потребление. Естественно придётся подстроится под заголовки пакетов WiFi. Но и самое последние, там где всё это используется нет других WiFi устройств. Повторюсь от WiFi нужна скорость передачи и фичи самого приёмопередатчика, если такие имеются. Но всё равно документации нет и вряд ли будет. Согласен,что WiFi чип для этих целей очень избыточен, но существует провал в сегменте радио, приёмопередатчики до 500-1000 кбит, а дальше WiFi с закрытой документацией и с большими скоростями, десятки Мбит.

[novartis 0]

Никак не получается организовать на этом модуле обмен по протоколу TCP -> RTSP.

 

TCP server на winc поднял, за основу взял пример от атмела.

RTSP запросы засылает видеоплеер vlc с пк.

winc должен на них отвечать.

 

Диалог состоит из следующих запросов-ответов:

OPTIONS...

RTSP/1.0 200 OK...

 

DESCRIBE ...

RTSP/1.0 200 OK...

 

SETUP...

RTSP/1.0 200 OK....

 

PLAY.....

RTSP/1.0 200 OK....

 

 

При первом запросе от vlc происходит открытие сокета и прием запроса.

В ответ OPTIONS на него формируется ответ RTSP/1.0 200 OK....

Экспериментально установил, что после этого сокет нужно закрыть, если не закрыть, то больше vlc никаких запросов не пришлет.

 

Прилетает следующий запрос от vlc - DESCRIBE.

Отвечаю на него. Теперь сокет закрывать не нужно, иначе не прилетит SETUP.

 

Прилетает SETUP, отвечаю на него.

 

А вот дальше ничего не ловится.

Vlc не формирует PLAY.

Пробывал разные комбинации: закрывать/не закрывать сокет, не выходит.

 

 

Все тоже самое реализовывал на Qt на обычном проводном ethernet и там работало, а тут не выходит.

 

В ваершарке трафик между qt программой и vlc показывает, что первый запрос OPTIONS и ответ на него укладываются в один tcp stream, все следующие в другой tcp stream.

 

Подскажите, куда смотреть?

 

Вот код callback:

static void socket_cb(SOCKET sock, uint8_t u8Msg, void *pvMsg)
{
    static uint8_t fsock = 0;
    static uint8_t rtsp_req[2];
    uint8_t argmint[1000];
    uint16_t argmintlen = 0;
    uint16_t i = 0;
    
    switch (u8Msg) {
    /* Socket bind */
    case SOCKET_MSG_BIND:
    {
        tstrSocketBindMsg *pstrBind = (tstrSocketBindMsg *)pvMsg;
        if (pstrBind && pstrBind->status == 0) {
            printf("socket_cb: bind success!\r\n");
            listen(tcp_server_socket, 0);
        } else {
            printf("socket_cb: bind error!\r\n");
            close(tcp_server_socket);
            tcp_server_socket = -1;
        }
    }
    break;

    /* Socket listen */
    case SOCKET_MSG_LISTEN:
    {
        tstrSocketListenMsg *pstrListen = (tstrSocketListenMsg *)pvMsg;
        if (pstrListen && pstrListen->status == 0) {
            printf("socket_cb: listen success!\r\n");
            accept(tcp_server_socket, NULL, NULL);
        } else {
            printf("socket_cb: listen error!\r\n");
            close(tcp_server_socket);
            tcp_server_socket = -1;
        }
    }
    break;

    /* Connect accept */
    case SOCKET_MSG_ACCEPT:
    {
        tstrSocketAcceptMsg *pstrAccept = (tstrSocketAcceptMsg *)pvMsg;
        if (pstrAccept) {
            //printf("socket_cb: Connect accept success! rtsp_req=%d\r\n",rtsp_req[0]);
            accept(tcp_server_socket, NULL, NULL);
            tcp_client_socket = pstrAccept->sock;
            recv(tcp_client_socket, gau8SocketTestBuffer, sizeof(gau8SocketTestBuffer), 0);
        } else {
            printf("socket_cb: accept error!\r\n");
            close(tcp_server_socket);
            tcp_server_socket = -1;
        }
    }
    break;

    /* Message send */
    case SOCKET_MSG_SEND:
    {
        if (fsock==1) //для OPTIONS нужно закрыть сокет, иначе не пошлется DESCRIBE
        {
            close(tcp_client_socket);
        }
        else    
            recv(tcp_client_socket, gau8SocketTestBuffer, sizeof(gau8SocketTestBuffer), 0);
        
            
    }
    break;

    /* Message receive */
    case SOCKET_MSG_RECV:
    {
        tstrSocketRecvMsg *pstrRecv = (tstrSocketRecvMsg *)pvMsg;
        
        //при поступлении нового сообщения, размер которого превышает 0 байт, разберем это сообщение и найдем в нем RTSP запросы
        if (pstrRecv && pstrRecv->s16BufferSize > 0)
        {
            argmintlen = rtsp_parse( pstrRecv, &argmint[0], &rtsp_req[0]);
            
            fsock++;
            send(tcp_client_socket, &argmint[0], argmintlen, 0);
                        
        }
        //иначе закрываем сокет
        else
        {
            printf("socket_cb: recv error!\r\n");
            close(tcp_server_socket);
            tcp_server_socket = -1;
        }
        
    }

    break;

    default:
        break;
    }
}

 

 

 

[ataradov 0]

Можете полный проект получить? Обещать ничего не могу, но если найдется время - посмотрю.

[novartis 0]

Прикрепил проект. Это пример от атмела, в котором поднимается tcp server, добавил всего два файла fapi.c и fapi.h.

В fapi.c реализован парсер rtsp запросов и формирование rtsp ответов, до ума не довел еще.

Если укажите точно такие же ip адреса: ip winc = 192.168.1.25 и ip пк = 192.168.1.6, то никаких правок в код вносить не придется.

На пк достаточно запустить vlc, в нем открыть url: rtsp://192.168.1.25:8554/test.sdp

В ваершарке посыплются tcp пакеты.

MYWINC1500_TCP_SERVER_electr.zip

[novartis 0]

Все вожусь и вожусь с этим модулем.

Есть у winc1500 нога IRQn. Понятно, что с нее прилетает прерывание, но в документации ни слова о том, на какие события формируется прерывание.

[ataradov 0]

Все вожусь и вожусь с этим модулем.

Есть у winc1500 нога IRQn. Понятно, что с нее прилетает прерывание, но в документации ни слова о том, на какие события формируется прерывание.

Это потому, что он не предназначен для использования без программной обертки поставляемой Атмелом. Вся документация только на эту обертку.

[novartis 0]

я использую программную обертку от Атмел, чуток урезанную. Но ведь есть у них документ WINC1500_SPI_Porting_Guide. С какой целью они его распространяют? В соответствии с этим документом портировал драйвера под альтеровский ниос. В ниосе я прочитал chip id wifi модуля. Дальше решил уж конкретно поднять wifi и заслать пару udp пакетов. Wifi не подымается. Никаких ошибок не выдает, вызовы функции m2m_wifi_init и m2m_wifi_connect проходят полностью, без ошибок. Но сам коннект не происходит.

[ataradov 0]

я использую программную обертку от Атмел, чуток урезанную. Но ведь есть у них документ WINC1500_SPI_Porting_Guide. С какой целью они его распространяют?

Чтобы портировать эту прослойку на свое железо. Если SPI запрограммирован правильно и обработчик прерывания вызывается при появлении прерывания на ножке, что все должно работать. Для этого коды самих прерываний и когда они происходят знать не нужно.

 

Я в своих портах выкидываю реакцию на прерывание, так как все, что делает его обработчик - это установка флага. Опрос этого флага происходит позже из основной программы. Я на месте опроса просто ножку опрашиваю вместо флага. Результат аналогичен, но не нужно бодаться с контроллером прерываний на каждом МК.

 

В соответствии с этим документом портировал драйвера под альтеровский ниос. В ниосе я прочитал chip id wifi модуля. Дальше решил уж конкретно поднять wifi и заслать пару udp пакетов. Wifi не подымается. Никаких ошибок не выдает, вызовы функции m2m_wifi_init и m2m_wifi_connect проходят полностью, без ошибок. Но сам коннект не происходит.

Что значит "коннект не происходит"?