|
|
  |
Wi-Fi-микросхема Atmel WINC1500, и модуль на её основе |
|
|
|
Apr 16 2015, 13:19
|
Частый гость
 
Группа: Участник
Сообщений: 117
Регистрация: 21-03-15
Пользователь №: 85 807

|
Как известно, в ближайшее время Atmel собирается выпустить на рынок несколько продуктов из серии Wi-Fi, Wi-Fi+MCU, Wi-Fi+BT. Первым таким продуктом, доступным на нашем рынке, стала микросхема ATWINC1500 и модуль на её основе. Так как не вся документация пока полностью вылизана, есть предложение обсуждать возникающие вопросы в отдельной теме. Здесь будем выкладывать доступную документацию.В общем, добро пожаловать
Сообщение отредактировал WLESS.RU - Apr 16 2015, 13:25
--------------------
|
|
|
|
|
Apr 18 2015, 11:35
|
Знающий
   
Группа: Свой
Сообщений: 639
Регистрация: 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, то это уже другая история. Можно протянуть будет такой проект.
|
|
|
|
|
Apr 24 2015, 18:53
|

Местный
  
Группа: Свой
Сообщений: 375
Регистрация: 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; } }
|
|
|
|
|
Apr 25 2015, 16:15
|

Местный
  
Группа: Свой
Сообщений: 375
Регистрация: 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 мегабайт )
Кол-во скачиваний: 86
|
|
|
|
|
Apr 29 2015, 17:58
|

Профессионал
    
Группа: Участник
Сообщений: 1 014
Регистрация: 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 проходят полностью, без ошибок. Но сам коннект не происходит. Что значит "коннект не происходит"?
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|