реклама на сайте
подробности

 
 
5 страниц V   1 2 3 > »   
Reply to this topicStart new topic
> Wi-Fi-микросхема Atmel WINC1500, и модуль на её основе
WLESS.RU
сообщение Apr 16 2015, 13:19
Сообщение #1


Частый гость
**

Группа: Участник
Сообщений: 111
Регистрация: 21-03-15
Пользователь №: 85 807



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

Сообщение отредактировал WLESS.RU - Apr 16 2015, 13:25


--------------------
Go to the top of the page
 
+Quote Post
Rash
сообщение Apr 17 2015, 05:03
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 630
Регистрация: 5-09-05
Пользователь №: 8 231



Возможно ли через данный модуль передавать данные по эфиру минуя TCP-IP. Т.е. использовать его как обычный приёмопередатчик со своим протоколом общения.
Go to the top of the page
 
+Quote Post
ataradov
сообщение Apr 17 2015, 05:07
Сообщение #3


Знающий
****

Группа: Участник
Сообщений: 945
Регистрация: 8-01-07
Из: San Jose, CA
Пользователь №: 24 202



QUOTE (Rash @ Apr 16 2015, 22:03) *
Возможно ли через данный модуль передавать данные по эфиру минуя TCP-IP. Т.е. использовать его как обычный приёмопередатчик со своим протоколом общения.

Нет. Железо в теории может, но прошивка не позволяет. WILC1000 - это сырой чип, через него можно, но он и сложнее значительно.
Go to the top of the page
 
+Quote Post
Rash
сообщение Apr 17 2015, 10:42
Сообщение #4


Знающий
****

Группа: Свой
Сообщений: 630
Регистрация: 5-09-05
Пользователь №: 8 231



WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.
Go to the top of the page
 
+Quote Post
ataradov
сообщение Apr 17 2015, 14:42
Сообщение #5


Знающий
****

Группа: Участник
Сообщений: 945
Регистрация: 8-01-07
Из: San Jose, CA
Пользователь №: 24 202



QUOTE (Rash @ Apr 17 2015, 03:42) *
WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.
WILC1000 поддерживается ядром Linux, а делать к нему драйверы с нуля - это с ума сойти можно. Не думаю, что к нему будут примеры для обычных МК.
Go to the top of the page
 
+Quote Post
Rash
сообщение Apr 18 2015, 11:35
Сообщение #6


Знающий
****

Группа: Свой
Сообщений: 630
Регистрация: 5-09-05
Пользователь №: 8 231



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

Go to the top of the page
 
+Quote Post
ataradov
сообщение Apr 19 2015, 06:42
Сообщение #7


Знающий
****

Группа: Участник
Сообщений: 945
Регистрация: 8-01-07
Из: San Jose, CA
Пользователь №: 24 202



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

Ну и дальность на 54 mbps тоже оставляет желать лучшего.
Go to the top of the page
 
+Quote Post
Rash
сообщение Apr 19 2015, 06:53
Сообщение #8


Знающий
****

Группа: Свой
Сообщений: 630
Регистрация: 5-09-05
Пользователь №: 8 231



дальность решается антеннами и усилителем, в последнем случае с учитывая потребление. Естественно придётся подстроится под заголовки пакетов WiFi. Но и самое последние, там где всё это используется нет других WiFi устройств. Повторюсь от WiFi нужна скорость передачи и фичи самого приёмопередатчика, если такие имеются. Но всё равно документации нет и вряд ли будет. Согласен,что WiFi чип для этих целей очень избыточен, но существует провал в сегменте радио, приёмопередатчики до 500-1000 кбит, а дальше WiFi с закрытой документацией и с большими скоростями, десятки Мбит.
Go to the top of the page
 
+Quote Post
novartis
сообщение Apr 24 2015, 18:53
Сообщение #9


Местный
***

Группа: Свой
Сообщений: 363
Регистрация: 9-10-09
Из: Свердловский регион
Пользователь №: 52 845



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



Go to the top of the page
 
+Quote Post
ataradov
сообщение Apr 24 2015, 18:59
Сообщение #10


Знающий
****

Группа: Участник
Сообщений: 945
Регистрация: 8-01-07
Из: San Jose, CA
Пользователь №: 24 202



Можете полный проект получить? Обещать ничего не могу, но если найдется время - посмотрю.
Go to the top of the page
 
+Quote Post
novartis
сообщение Apr 25 2015, 16:15
Сообщение #11


Местный
***

Группа: Свой
Сообщений: 363
Регистрация: 9-10-09
Из: Свердловский регион
Пользователь №: 52 845



Прикрепил проект. Это пример от атмела, в котором поднимается 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 ( 9.16 мегабайт ) Кол-во скачиваний: 72
Go to the top of the page
 
+Quote Post
novartis
сообщение Apr 29 2015, 16:54
Сообщение #12


Местный
***

Группа: Свой
Сообщений: 363
Регистрация: 9-10-09
Из: Свердловский регион
Пользователь №: 52 845



Все вожусь и вожусь с этим модулем.
Есть у winc1500 нога IRQn. Понятно, что с нее прилетает прерывание, но в документации ни слова о том, на какие события формируется прерывание.
Go to the top of the page
 
+Quote Post
ataradov
сообщение Apr 29 2015, 16:56
Сообщение #13


Знающий
****

Группа: Участник
Сообщений: 945
Регистрация: 8-01-07
Из: San Jose, CA
Пользователь №: 24 202



QUOTE (novartis @ Apr 29 2015, 09:54) *
Все вожусь и вожусь с этим модулем.
Есть у winc1500 нога IRQn. Понятно, что с нее прилетает прерывание, но в документации ни слова о том, на какие события формируется прерывание.

Это потому, что он не предназначен для использования без программной обертки поставляемой Атмелом. Вся документация только на эту обертку.
Go to the top of the page
 
+Quote Post
novartis
сообщение Apr 29 2015, 17:10
Сообщение #14


Местный
***

Группа: Свой
Сообщений: 363
Регистрация: 9-10-09
Из: Свердловский регион
Пользователь №: 52 845



я использую программную обертку от Атмел, чуток урезанную. Но ведь есть у них документ WINC1500_SPI_Porting_Guide. С какой целью они его распространяют? В соответствии с этим документом портировал драйвера под альтеровский ниос. В ниосе я прочитал chip id wifi модуля. Дальше решил уж конкретно поднять wifi и заслать пару udp пакетов. Wifi не подымается. Никаких ошибок не выдает, вызовы функции m2m_wifi_init и m2m_wifi_connect проходят полностью, без ошибок. Но сам коннект не происходит.
Go to the top of the page
 
+Quote Post
ataradov
сообщение Apr 29 2015, 17:58
Сообщение #15


Знающий
****

Группа: Участник
Сообщений: 945
Регистрация: 8-01-07
Из: San Jose, CA
Пользователь №: 24 202



QUOTE (novartis @ Apr 29 2015, 10:10) *
я использую программную обертку от Атмел, чуток урезанную. Но ведь есть у них документ WINC1500_SPI_Porting_Guide. С какой целью они его распространяют?
Чтобы портировать эту прослойку на свое железо. Если SPI запрограммирован правильно и обработчик прерывания вызывается при появлении прерывания на ножке, что все должно работать. Для этого коды самих прерываний и когда они происходят знать не нужно.

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

QUOTE (novartis @ Apr 29 2015, 10:10) *
В соответствии с этим документом портировал драйвера под альтеровский ниос. В ниосе я прочитал chip id wifi модуля. Дальше решил уж конкретно поднять wifi и заслать пару udp пакетов. Wifi не подымается. Никаких ошибок не выдает, вызовы функции m2m_wifi_init и m2m_wifi_connect проходят полностью, без ошибок. Но сам коннект не происходит.
Что значит "коннект не происходит"?
Go to the top of the page
 
+Quote Post

5 страниц V   1 2 3 > » 
Reply to this topicStart new topic
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 21st November 2017 - 10:19
Рейтинг@Mail.ru


Страница сгенерированна за 0.01765 секунд с 7
ELECTRONIX ©2004-2016