WLESS.RU
Apr 16 2015, 13:19
Как известно, в ближайшее время Atmel собирается выпустить на рынок несколько продуктов из серии Wi-Fi, Wi-Fi+MCU, Wi-Fi+BT. Первым таким продуктом, доступным на нашем рынке, стала микросхема
ATWINC1500 и модуль на её основе.
Так как не вся документация пока полностью вылизана, есть предложение обсуждать возникающие вопросы в отдельной теме.
Здесь будем выкладывать доступную документацию.В общем, добро пожаловать
Возможно ли через данный модуль передавать данные по эфиру минуя TCP-IP. Т.е. использовать его как обычный приёмопередатчик со своим протоколом общения.
ataradov
Apr 17 2015, 05:07
QUOTE (Rash @ Apr 16 2015, 22:03)

Возможно ли через данный модуль передавать данные по эфиру минуя TCP-IP. Т.е. использовать его как обычный приёмопередатчик со своим протоколом общения.
Нет. Железо в теории может, но прошивка не позволяет. WILC1000 - это сырой чип, через него можно, но он и сложнее значительно.
WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.
ataradov
Apr 17 2015, 14:42
QUOTE (Rash @ Apr 17 2015, 03:42)

WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.
WILC1000 поддерживается ядром Linux, а делать к нему драйверы с нуля - это с ума сойти можно. Не думаю, что к нему будут примеры для обычных МК.
Можно забрать драйвера из линукса и вставить в свой проект, было бы описание регистров модуля. Дело в том, что мне не нужен 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
Apr 19 2015, 06:42
Не думаю, что использование голого Wi-Fi железа для своих целей - эта такая уж хорошая идея. Если нормально не реализовывать стандарт, то все окружающие устройства будут мешать вам, а вы - им.
Ну и дальность на 54 mbps тоже оставляет желать лучшего.
дальность решается антеннами и усилителем, в последнем случае с учитывая потребление. Естественно придётся подстроится под заголовки пакетов WiFi. Но и самое последние, там где всё это используется нет других WiFi устройств. Повторюсь от WiFi нужна скорость передачи и фичи самого приёмопередатчика, если такие имеются. Но всё равно документации нет и вряд ли будет. Согласен,что WiFi чип для этих целей очень избыточен, но существует провал в сегменте радио, приёмопередатчики до 500-1000 кбит, а дальше WiFi с закрытой документацией и с большими скоростями, десятки Мбит.
novartis
Apr 24 2015, 18:53
Никак не получается организовать на этом модуле обмен по протоколу 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
Apr 24 2015, 18:59
Можете полный проект получить? Обещать ничего не могу, но если найдется время - посмотрю.
novartis
Apr 25 2015, 16:15
Прикрепил проект. Это пример от атмела, в котором поднимается 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 пакеты.
Нажмите для просмотра прикрепленного файла
novartis
Apr 29 2015, 16:54
Все вожусь и вожусь с этим модулем.
Есть у winc1500 нога IRQn. Понятно, что с нее прилетает прерывание, но в документации ни слова о том, на какие события формируется прерывание.
ataradov
Apr 29 2015, 16:56
QUOTE (novartis @ Apr 29 2015, 09:54)

Все вожусь и вожусь с этим модулем.
Есть у winc1500 нога IRQn. Понятно, что с нее прилетает прерывание, но в документации ни слова о том, на какие события формируется прерывание.
Это потому, что он не предназначен для использования без программной обертки поставляемой Атмелом. Вся документация только на эту обертку.
novartis
Apr 29 2015, 17:10
я использую программную обертку от Атмел, чуток урезанную. Но ведь есть у них документ WINC1500_SPI_Porting_Guide. С какой целью они его распространяют? В соответствии с этим документом портировал драйвера под альтеровский ниос. В ниосе я прочитал chip id wifi модуля. Дальше решил уж конкретно поднять wifi и заслать пару udp пакетов. Wifi не подымается. Никаких ошибок не выдает, вызовы функции m2m_wifi_init и m2m_wifi_connect проходят полностью, без ошибок. Но сам коннект не происходит.
ataradov
Apr 29 2015, 17:58
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 проходят полностью, без ошибок. Но сам коннект не происходит.
Что значит "коннект не происходит"?
novartis
Apr 29 2015, 18:06
Я вывел ногу irqn в сигналтап, чтобы отслеживать изменения на ней, но никаких изменений так и не увидел.
Я запускаю стандартный пример от атмела UDP_CLIENT_EXAMPLE для winc. SPI работает, chip id считывается, версия прошивки считывается. В самом примере проходят функции m2m_wifi_init, m2m_wifi_connect. Никаких ошибок не появляется. Но в результате к роутеру модуль не подцепляется, на самом роутере он не появляется.
ataradov
Apr 29 2015, 18:58
QUOTE (novartis @ Apr 29 2015, 11:06)

Никаких ошибок не появляется. Но в результате к роутеру модуль не подцепляется, на самом роутере он не появляется.
То-есть функция переданная через pfAppWifiCb вызывается с event==M2M_WIFI_RESP_CON_STATE_CHANGED и M2M_WIFI_CONNECTED == pstrWifiState->u8CurrState ?
Сама по себе m2m_wifi_connect() ничего не делает и ее успешный возврат ни о чем не говорит.
novartis
Apr 30 2015, 04:17
Не совсем понял насчет pfAppWifiCb.
А на счет того, что функция m2m_wifi_connect ничего не делает, я бы поспорил. Эта функция передает в вифи модуль параметры для коннекта (ssid,pwd). Я предполагаю, что она также дает команду модулю законектиться к данной вифи сети. Также я предполал, что после вызова этой функции и после того как модуль законнектится к вифи, модуль должен выставить прерывание и вызваться callback - wifi_cb. Может я и ошибаюсь насчет прерывания.
ataradov
Apr 30 2015, 04:39
QUOTE (novartis @ Apr 29 2015, 21:17)

Не совсем понял насчет pfAppWifiCb.
pfAppWifiCb - это член в структуре, через которую происходит инициализация callback-а (в вашем случае это видимо wifi_cb). Поиск по программе должен найти это место, так как сам по себе wifi_cb без регистрации вызваться не будет. У меня под рукой сейчас нет исходников и слишком поздно и лениво качать что-либо.
QUOTE (novartis @ Apr 29 2015, 21:17)

А на счет того, что функция m2m_wifi_connect ничего не делает, я бы поспорил.
Под "ничего не делает" я подразумевал, что успешный код завершения от нее не говорит об успешном присоединении, только о правильности параметров.
А вообще я бы рекомендовал начать с D21 Xpro. А так выходит слишком много переменных - новое железо с новым процессором.
novartis
Apr 30 2015, 07:07
Сдвинулось дело!
Понизил частоту spi с 40мгц до 20мгц и коннект состоялся - роутер сказал, что к нему подцепился winc.
Но вот нога irqn так и не дернулась. Все таки не понятно на какие события она дергается.
Буду дальше разбираться.
Дергается irqn, это я не туда смотрел сначала.
Все, осталось обработчик прерывания в ниосе задействовать.
ataradov
Apr 30 2015, 07:09
QUOTE (novartis @ Apr 30 2015, 00:07)

Понизил частоту spi с 40мгц до 20мгц и коннект состоялся - роутер сказал, что к нему подцепился winc.
Рекомендованная максимальная частота - 12 МГц. Выше - там ни процессор внутренний не справляется ни пропускной полосы ножек не хватает для нормальной передачи сигнала.
novartis
Apr 30 2015, 07:16
В даташите написано 48мгц максимум для spi, а где про 12 мгц сказано?
ataradov
Apr 30 2015, 07:26
QUOTE (novartis @ Apr 30 2015, 00:16)

В даташите написано 48мгц максимум для spi,
Это хорошо, что сейчас есть DS

. Когда я впервые с этим модулем игрался его не было. Так что это может быть и так, но ПО внутри точно на 48 МГц данные не сможет принять.
QUOTE (novartis @ Apr 30 2015, 00:16)

а где про 12 мгц сказано?
Сказано устно разработчиками

Ну и экспериментально опробовано. Правда пробовалось с D21 в качестве мастера, у которой ноги точно в районе 12-16 МГц ограничены. Плюс я делал эксперименты на сравнительно старых прошивках.
ataradov
Apr 30 2015, 16:31
Я посмотрел на пример RTSP. Не знаю что именно происходит с закрытием соединения, я смотрел на пример без. В логе Wireshark видно, что VLC посылает запрос, получает ответ, закрывает соединение, создает новое соединение, посылает еще запрос, в этот раз без пути к файлу и с другой строкой User Agent. Потом VLC закрывает соединение, похоже так как не дожидается ответа на этот запрос.
Я не знаток RTSP и не могу быстро найти логов нормальной работы для сравнения. Но похоже, что нужно разбираться что происходит во втором соединении и запросе.
novartis
May 2 2015, 19:01
Разобрался с rtsp. В ответе на запрос SETUP добавил в конец /r/n. То есть в конце получилось /r/n/r/n. И после этого стал прилетать PLAY.
Еще разобрался с портированием под альтеровский ниос. Как уже писал, после того как понизил скорость spi до 20мгц, прерывание стало прилетать. Прерывание завел на кусисный pio. Повесил на него в ниосе стандартный обработчик, в конце обработчика вызываю isr() - это обработчик из атмеловских драйверов.
Атмеловский пример UDP client example полностью прошел.
Всем спасибо! Особенно ataradov за поддержку!
novartis
May 25 2015, 07:15
Опять возникли сложности

.
В драйверах атмела есть функция hif_send. Эту функцию вызываем, когда отправляем данные по udp. Сперва в ней читается регистр 0x150400, ответ заполняет переменную dma_addr. Дальше, если dma_addr!=0, то данные отправляются, а если дма аддр равен нулю, то выдается Failed to alloc rx size.
Иногда у меня пролетает, что дма аддр равен нулю.
Хотелось бы понять из-за чего это происходит, что это значит?
Также имеется и более фатальная ситуация с этим дма аддр.
Если поднять Роутер на телефоне с андроидом 2.3, законнектить к нему winc и другой телефон с андроидом 4.0, то при отправке udp данных с winc на андроид 4.0, то все работает долго и стабильно.
Если поднять Роутер на телефоне с андроидом 4.0. Законнектить к нему winc и с winc отправлять udp данные на телефон-Роутер, то примерно через 12-15 секунд начинает постоянно вылетать dma_addr=0 и это уже не обратимо.
ataradov
May 25 2015, 07:23
QUOTE (novartis @ May 25 2015, 00:15)

Хотелось бы понять из-за чего это происходит, что это значит?
Это значит, что закончилась память под пакеты внутри модуля. Нужно ждать пока отправятся. И если долго не отправляется, то что-то сломалось

В первую очередь стоит проверить и обновить версию прошивки на последнюю, из них баги вылизывают постоянно. В версиях до 17.0.0 у меня постоянно эти ошибки были.
QUOTE (novartis @ May 25 2015, 00:15)

Если поднять Роутер на телефоне с андроидом 2.3
Можно подробнее, что именно и как "поднимается"?
novartis
May 25 2015, 08:42
Версия firmware - 18.0.3
Min driver ver 18.0.0
Curr driver ver 18.0.0
Вчера проверял в атмел студио, последние версии стоят.
На телефоне я включаю точку доступа. Winc коннектится к ней.
Вот в первом случае все работает, иногда пролетает дма аддр = 0, но не смертельно.
А во втором случае через 12-15 сек ломается без поворотно. А хотелось бы получить вариант задействовывания только одно телефона.
novartis
May 25 2015, 16:37
Вывел на печать dma_addr.
Получил такие цифры:
...
...
...
897860
910222
972144
972144
972144
972144
933022
910200
894442
0
0
0
0
0
...
То есть, сначала было много места, потом, бац, и нет места. Что-то ломается.
ataradov
May 25 2015, 17:35
QUOTE (novartis @ May 25 2015, 01:42)

Версия firmware - 18.0.3
Да, это последняя.
QUOTE (novartis @ May 25 2015, 01:42)

На телефоне я включаю точку доступа. Winc коннектится к ней.
С воспроизведением этого тут могут быть проблемы, так как мобильные операторы отключают эту возможность в телефонах. Нужно будет разлоченый телефон искать.
QUOTE (novartis @ May 25 2015, 01:42)

А во втором случае через 12-15 сек ломается без поворотно. А хотелось бы получить вариант задействовывания только одно телефона.
У меня точно такая же беда была с точкой D-Link. Пока физически точку не отдал разработчикам - не верили, что есть баг. Будем надеяться, что эта история заставит их верить в новые баги

QUOTE (novartis @ May 25 2015, 09:37)

То есть, сначала было много места, потом, бац, и нет места. Что-то ломается.
Мне кажется этот dma_addr - это реальный адрес в памяти. И судить по нему как много места осталось - нельзя. Я так же не уверен сколько этой памяти под буфферы отведено.
Но кусок с 910222 позднее выделен как 910200 и 972144 выделен несколько раз подряд, то-есть до какого-то момента очередь освобождается.
Я поговорю с разработчиками и узнаю как они планируют такие вещи отлаживать.
novartis
May 25 2015, 17:36
Я кейс создал на сайте атмела, они мне ответили:
What is the firmware version your using now.? Please try with 18.1 firmware version available in ASF 3.23.1 if your not using updated.
ASF 3.23.1 я скачал, установил, а где брать 18.1 firmware не пойму, в атмел студио 18.0.0 предлагается.
Жаль в кейсе про 12-15сек ничего не написал.
ataradov
May 25 2015, 17:40
QUOTE (novartis @ May 25 2015, 10:36)

ASF 3.23.1 я скачал, установил, а где брать 18.1 firmware не пойму, в атмел студио 18.0.0 предлагается.
Это может быть баг с нумерацией, думаю стоит попробовать его накатить. У меня на рабочем компе есть это обновление, но сегодня выходной.
Обратите внимание, что при обновлении нужно обязательно обновить и файлы на хосте, они опять протокол сломали.
Ну и скорее всего это не поможет.
ataradov
May 26 2015, 20:52
Описание проблемы ушло разработчикам.
Для обновления ПО нужно создать проект из примера WINC1500_FIRMWARE_UPDATE_AND_DOCUMENTATION. Но я тоже вижу только v18.0.3.
v18.1 существует, но видимо пока не опубликована.
Как выяснилось, v18.0.3 - это ошибка, на самом деле версия в последнем ASF v18.1.
Так что можно пробовать ее установить, есть хороший шанс, что все заработает, так как эта версия прошла полное тестирование на совместимость с тучей эталонных устройств.
novartis
May 28 2015, 08:07
Обновил прошивку и драйвер. Не помогло. Точно также через 12 сек падает. Пробовал уменьшать размер пачки данных, передаваемых по udp (300байт сделал, а было 970), и вводить паузу после отправки udp пакета - падает не через 12 сек, а через 40 сек.
В файлах драйвера не увидел значимых изменений. В основном лишние пробелы и табы поудаляли.
Спасибо, что передали разработчикам описание проблему. Может это и принесет результат.
ataradov
May 28 2015, 15:30
QUOTE (novartis @ May 28 2015, 01:07)

Спасибо, что передали разработчикам описание проблему. Может это и принесет результат.
Их ответ стандартный - нужно воспроизводить на D21. Я понимаю, что это абсурд и мы не можем заставить каждого клиента покупать D21 Xpro просто чтобы багрепорты слать. Это со временем продет.
Если используется плата расширения XPro, то в зависимости от версии платы на ней либо есть разъем DEBUG UART или FTDI c USB. Нужно получить лог с этого разъема в момент падения.
И еще, что именно было изменено при порте на Microblaze?
А так же продолжайте теребить официальный саппорт. И номер кейса мне отправьте пожалуйста.
novartis
May 28 2015, 16:48
SAMD21 имеется, и разъем у него DEBUG microUSB (ну наверно там FTDI c USB). А как получить лог с этого разъема в момент падения?
При портировании под Nios (софт процессор Altera) заменил в nm_bus_wrapper_samd21.c в функции nm_bus_ioctl обращение к функции spi_rw на обращение к альтеровской функции - чтение/запись по spi. Прерывание от wnc посадил на стандартный обработчик Nios, в нем вызываю isr() - ту функцию, что вызывается у атмела. Вот в принципе и все.
Номер кейса 00017827.
ataradov
May 28 2015, 17:08
QUOTE (novartis @ May 28 2015, 09:48)

SAMD21 имеется, и разъем у него DEBUG microUSB (ну наверно там FTDI c USB). А как получить лог с этого разъема в момент падения?
Разъем должен быть на самой плате расширения с модулем WINC1500. Существует 2 версии - первая с разъемом micro-USB, вторя - без, но 3 контактами под UART (скорее всего у вас такая). На ней есть отверстия для пайки помеченные как DEBUG UART (RX, TX, GND). Модуль постоянно валит отладочную информацию в этот порт. Достаточно подключить USB-to-UART адаптер и настроить COM-порт на 115200 8N1.
novartis
May 28 2015, 17:10
а, понял, может даже и получится собрать такой лог.
novartis
Jun 1 2015, 03:24
Снял лог с DEBUG UART,ничего интересного в нем нет, на TCP соединения две записи складываются, на UDP вообще никакой информации не добавляется. В момент падения, постоянного дма аддр =0, тоже ничего не выводится в лог.
Решил все таки проверить на SAMD21 как udp себя ведет. Открыл проект с примером от Атмел udp example. Там 10 удп засылок, сделал бесконечный цикл. Еще там пауза между засылками была, убрал ее. Вообщем точно также выскакивает дма аддр = 0.
Подконнектился к домашнему вифи роутеру Netgear jwr2000. Сначала вроде ничего, полет нормальный, иногда дма аддр проскакивали. Потом увеличил размер удп засылок, было байт 15, сделал 1400. Стало и на этом роутере отваливаться.
Если раньше у меня еще были сомнения, вдруг это я чего нахимичил в плис, spi не так дергаю, в коде атмела чего поломал, то теперь сомнений нет - косяк в их модуле, в их коде!
ataradov
Jun 1 2015, 03:32
QUOTE (novartis @ May 31 2015, 20:24)

Если раньше у меня еще были сомнения, вдруг это я чего нахимичил в плис, spi не так дергаю, в коде атмела чего поломал, то теперь сомнений нет - косяк в их модуле, в их коде!
У меня и раньше сомнений не было

. Проблема убедить, но я над этим работаю. Они просто еще ни одного продута, который идет широкой публике не выпускали, так что они пока не знают, что такие проблемы им придется решать, а не отбрыкиваться тем, что покупаете мало. А кто будет покупать много, если оно не работает?
То-есть пример на D21 работает с Android 4.0 как нужно, а на Android 2.3 и Netgear jwr2000 - нет?
PS: я подписался на ваш кейс, но активно вмешиваться не буду. Я хочу посмотреть как официальный суппорт это разрулит.
novartis
Jun 1 2015, 05:22
D21 с андроид 4 почти сразу падает, с netgear с маленькими пакетами работало, с большими пакетами - упало. С андроидом 2.3, с которым у меня плиска нормально работает, забыл проверить(
ataradov
Jun 1 2015, 05:30
QUOTE (novartis @ May 31 2015, 22:22)

D21 с андроид 4 почти сразу падает, с netgear с маленькими пакетами работало, с большими пакетами - упало. С андроидом 2.3, с которым у меня плиска нормально работает, забыл проверить(
Несовместимость с одним устройством - я еще могу понять, но несколько сразу - это очень странно.
Единственная разница, которую я вижу - это настройки страны в AP. Правда не знаю на что именно они влияют, скорее всего только на мощность. Не думаю, что их можно изменить в телефоне, но у Netgear точно настройка должна быть. Можно попробовать с ней поиграться.
Пришлите проект для D21, я попробую тут воспроизвести.
novartis
Jun 1 2015, 07:04
У товарища ASUS PADFON, также дма аддр = 0,отваливается.
Вот проект для D21. Тот, с которым работал, дома, этот на память восстановил, может и ошибки будут. Основа - пример из атмел студио, с обновлениями до 18.1.1.
Я внес изменения в main_samd21.c:
- убрал ограничение в 10 удп пакетов,
- убрал паузу между засылкой пакетов,
- увеличил размер засылаемого удп сообщения (buff[1400])
Еще в ASF/common/components/WiFi/winc1500/driver/source/m2m_hif.c в функции hif_send добавил принтф, если дма аддр = 0.
Нажмите для просмотра прикрепленного файла
novartis
Jun 1 2015, 16:29
строчка из hif_send:
Код
ret = nm_read_reg_with_ret(0x150400,(uint32 *)&dma_addr);
Вот читаем мы из winc регистр 0x150400, тем самым узнаем дма аддр, а может можно прочитать еще какой регистр и узнать сколько места есть в буфере, ведь по сути просто где то заканчивается место?
ataradov
Jun 1 2015, 16:49
QUOTE (novartis @ Jun 1 2015, 09:29)

Вот читаем мы из winc регистр 0x150400, тем самым узнаем дма аддр, а может можно прочитать еще какой регистр и узнать сколько места есть в буфере, ведь по сути просто где то заканчивается место?
Все эти регистры не документированы и о них знать не положено. Все должно работать с предоставленным API. Это по-идее, конечно. Я пытаюсь сделать так, чтобы интерфейс был документирован и не менялся, но пока без особых успехов.
Я позже сегодня попробую погонять новую прошивку. Но у меня есть подозрение, что 1400 байт может быть слишком много. Хотя я пробовал слать звук чрез 1024-байтные пакеты и все работало.
Ну и 0 - это индикация, что пока что нет места. Это нормально при плотном потоке. А вот то, что оно зависает так на долго - это не нормально.
novartis
Jun 1 2015, 17:16
Код
Все эти регистры не документированы и о них знать не положено. Все должно работать с предоставленным API.
Ну я думал, может вы знаете эти регистры. Было бы не плохо помимо индикации, что пока нет места, еще иметь индикацию - вот скоро место закончится. Нам бы такая индикация может и помогла.
Размеры посылок я пробовал всякие, и 1400, и 500, и 220 байт. Результат один и тот же.
Спасибо вам за ответы, проект горит.
ataradov
Jun 1 2015, 20:08
Я смотрю на этот пример и офигеваю. Пр смыслу sock_bind_state будет снова 1 после приема ответа от прилагаемого питоновского скрипта.
Вот только прем начинается после
QUOTE
printf("socket_cb: sendto success!\r\n");
и у меня они никогда не выполняется, так что в логе только
QUOTE
-- SAMD21_XPLAINED_PRO --
-- Compiled: Jun 1 2015 13:27:52 --
(APP)(INFO)Chip ID 1502b1
(APP)(INFO)Firmware ver : 18.1.1
(APP)(INFO)Min driver ver : 18.1.1
(APP)(INFO)Curr driver ver: 18.1.1
wifi_cb: M2M_WIFI_RESP_CON_STATE_CHANGED: CONNECTED
wifi_cb: M2M_WIFI_REQ_DHCP_CONF : IP is 192.168.0.109
socket_cb: bind success!
main: message sent
Это с оригинальным кодом. Ваш пример забивает буфферы тут похоже, так как запросов уходит много, но они не подтверждаются.
Я продолжаю ковыряться.
ataradov
Jun 1 2015, 22:16
И так, несколько наблюдений:
1. В приложении WINC1500_SIMPLE_UDP_EXAMPLE логика ожидает, что событие SOCKET_MSG_SENDTO произойдет, и в то же время индикация отключается во время открытия сокета:
QUOTE
setsockopt(tx_socket, SOL_SOCKET, SO_SET_UDP_SEND_CALLBACK, &u32EnableCallbacks, 0);
Эту строку нужно убрать.
2. Можно попробовать извлечь побольше информации изменив M2M_LOG_LEVEL на M2M_LOG_DBG в src\ASF\common\components\wifi\winc1500\common\include\nm_common.h
3. Я не могу воспроизвести проблему, поэтому для синхронизации, я прилагаю проект с более простой логикой. Этот просто шлет броадкасты сразу после подключения и ничего не принимает. Для начала, изменяйте только параметры сети в main.h и ничего больше.
novartis
Jun 2 2015, 17:29
Здравствуйте.
Запустил ваш проект, изменил только SSID и пароль. Законнектился к телефону Филипс Андроид 4.0 (без симкарты).
У меня виснет.
Вот лог:
Код
-- WINC1500 UDP client example --
-- SAMD21_XPLAINED_PRO --
-- Compiled: Jun 2 2015 22:12:38 --
(APP)(INFO)Chip ID 1502b1(APP)(INFO)Firmware ver : 18.1.1
(APP)(INFO)Min driver ver : 18.1.1
(APP)(INFO)Curr driver ver: 18.1.1wifi_cb: M2M_WIFI_RESP_CON_STATE_CHANGED: CONNECTED
wifi_cb: M2M_WIFI_REQ_DHCP_CONF : IP is 192.168.43.241
main: message sent
socket_cb: sendto success!
main: message sent
socket_cb: sendto success!
main: message sent
socket_cb: sendto success!
...
вроде все норм, пакеты шлются (секунды 2)
....
main: message sent
socket_cb: sendto success!
ent
socket_cb: sendto success!
main: failed to send status report error! -14
...
начинают пролетать ошибки (секунды 2)
...
main: message sent
socket_cb: sendto success!
main: message sent
socket_cb: sendto success!
main: message sent
socket_cb: sendto success!
main: failed to send status report error! -14
...
d status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
main: failed to send status report error! -14
...
все - зациклился, постоянно выдает эту ошибку
А теперь веселая часть поста.
Вставляю в этот телефон сим-карту. Включаю на телефоне передачу данных - мобильный интернет.
Стартую этот же проект - и вуаля - все летает, все работает, пакеты шлются бес конца и края. Иногда пролетает main: failed to send status report error! -14, но изредка и не фатально.
На нашем проекте с плиской все тоже стало более менее работать с включенным мобильным интернетом.
Как он влияет на winc, понять не могу.
ataradov
Jun 2 2015, 18:25
Похоже воспроизвел с Nexus 7 2013. Тоже падает все через несколько минут/секунд работы. Проверить с подключением не могу на нем правда.