Jump to content

    
Sign in to follow this  
wless.ru

Wi-Fi-микросхема Atmel WINC1500

Recommended Posts

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

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

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

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

Edited by WLESS.RU

Share this post


Link to post
Share on other sites

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

Share this post


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

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

Share this post


Link to post
Share on other sites
WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.
WILC1000 поддерживается ядром Linux, а делать к нему драйверы с нуля - это с ума сойти можно. Не думаю, что к нему будут примеры для обычных МК.

 

Share this post


Link to post
Share on other sites

Можно забрать драйвера из линукса и вставить в свой проект, было бы описание регистров модуля. Дело в том, что мне не нужен 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, то это уже другая история. Можно протянуть будет такой проект.

 

 

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Никак не получается организовать на этом модуле обмен по протоколу 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;
    }
}

 

 

 

Share this post


Link to post
Share on other sites

Прикрепил проект. Это пример от атмела, в котором поднимается 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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Все вожусь и вожусь с этим модулем.

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
я использую программную обертку от Атмел, чуток урезанную. Но ведь есть у них документ WINC1500_SPI_Porting_Guide. С какой целью они его распространяют?
Чтобы портировать эту прослойку на свое железо. Если SPI запрограммирован правильно и обработчик прерывания вызывается при появлении прерывания на ножке, что все должно работать. Для этого коды самих прерываний и когда они происходят знать не нужно.

 

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

 

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this