Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Wi-Fi-микросхема Atmel WINC1500
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Wireless/Optic
Страницы: 1, 2
WLESS.RU
Как известно, в ближайшее время Atmel собирается выпустить на рынок несколько продуктов из серии Wi-Fi, Wi-Fi+MCU, Wi-Fi+BT. Первым таким продуктом, доступным на нашем рынке, стала микросхема ATWINC1500 и модуль на её основе.
Так как не вся документация пока полностью вылизана, есть предложение обсуждать возникающие вопросы в отдельной теме.
Здесь будем выкладывать доступную документацию.
В общем, добро пожаловать sm.gif
Rash
Возможно ли через данный модуль передавать данные по эфиру минуя TCP-IP. Т.е. использовать его как обычный приёмопередатчик со своим протоколом общения.
ataradov
QUOTE (Rash @ Apr 16 2015, 22:03) *
Возможно ли через данный модуль передавать данные по эфиру минуя TCP-IP. Т.е. использовать его как обычный приёмопередатчик со своим протоколом общения.

Нет. Железо в теории может, но прошивка не позволяет. WILC1000 - это сырой чип, через него можно, но он и сложнее значительно.
Rash
WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.
ataradov
QUOTE (Rash @ Apr 17 2015, 03:42) *
WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.
WILC1000 поддерживается ядром Linux, а делать к нему драйверы с нуля - это с ума сойти можно. Не думаю, что к нему будут примеры для обычных МК.
Rash
Можно забрать драйвера из линукса и вставить в свой проект, было бы описание регистров модуля. Дело в том, что мне не нужен 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
Не думаю, что использование голого Wi-Fi железа для своих целей - эта такая уж хорошая идея. Если нормально не реализовывать стандарт, то все окружающие устройства будут мешать вам, а вы - им.

Ну и дальность на 54 mbps тоже оставляет желать лучшего.
Rash
дальность решается антеннами и усилителем, в последнем случае с учитывая потребление. Естественно придётся подстроится под заголовки пакетов WiFi. Но и самое последние, там где всё это используется нет других WiFi устройств. Повторюсь от WiFi нужна скорость передачи и фичи самого приёмопередатчика, если такие имеются. Но всё равно документации нет и вряд ли будет. Согласен,что WiFi чип для этих целей очень избыточен, но существует провал в сегменте радио, приёмопередатчики до 500-1000 кбит, а дальше WiFi с закрытой документацией и с большими скоростями, десятки Мбит.
novartis
Никак не получается организовать на этом модуле обмен по протоколу 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
Можете полный проект получить? Обещать ничего не могу, но если найдется время - посмотрю.
novartis
Прикрепил проект. Это пример от атмела, в котором поднимается 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
Все вожусь и вожусь с этим модулем.
Есть у winc1500 нога IRQn. Понятно, что с нее прилетает прерывание, но в документации ни слова о том, на какие события формируется прерывание.
ataradov
QUOTE (novartis @ Apr 29 2015, 09:54) *
Все вожусь и вожусь с этим модулем.
Есть у winc1500 нога IRQn. Понятно, что с нее прилетает прерывание, но в документации ни слова о том, на какие события формируется прерывание.

Это потому, что он не предназначен для использования без программной обертки поставляемой Атмелом. Вся документация только на эту обертку.
novartis
я использую программную обертку от Атмел, чуток урезанную. Но ведь есть у них документ WINC1500_SPI_Porting_Guide. С какой целью они его распространяют? В соответствии с этим документом портировал драйвера под альтеровский ниос. В ниосе я прочитал chip id wifi модуля. Дальше решил уж конкретно поднять wifi и заслать пару udp пакетов. Wifi не подымается. Никаких ошибок не выдает, вызовы функции m2m_wifi_init и m2m_wifi_connect проходят полностью, без ошибок. Но сам коннект не происходит.
ataradov
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
Я вывел ногу irqn в сигналтап, чтобы отслеживать изменения на ней, но никаких изменений так и не увидел.

Я запускаю стандартный пример от атмела UDP_CLIENT_EXAMPLE для winc. SPI работает, chip id считывается, версия прошивки считывается. В самом примере проходят функции m2m_wifi_init, m2m_wifi_connect. Никаких ошибок не появляется. Но в результате к роутеру модуль не подцепляется, на самом роутере он не появляется.
ataradov
QUOTE (novartis @ Apr 29 2015, 11:06) *
Никаких ошибок не появляется. Но в результате к роутеру модуль не подцепляется, на самом роутере он не появляется.
То-есть функция переданная через pfAppWifiCb вызывается с event==M2M_WIFI_RESP_CON_STATE_CHANGED и M2M_WIFI_CONNECTED == pstrWifiState->u8CurrState ?

Сама по себе m2m_wifi_connect() ничего не делает и ее успешный возврат ни о чем не говорит.
novartis
Не совсем понял насчет pfAppWifiCb.

А на счет того, что функция m2m_wifi_connect ничего не делает, я бы поспорил. Эта функция передает в вифи модуль параметры для коннекта (ssid,pwd). Я предполагаю, что она также дает команду модулю законектиться к данной вифи сети. Также я предполал, что после вызова этой функции и после того как модуль законнектится к вифи, модуль должен выставить прерывание и вызваться callback - wifi_cb. Может я и ошибаюсь насчет прерывания.
ataradov
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
Сдвинулось дело!
Понизил частоту spi с 40мгц до 20мгц и коннект состоялся - роутер сказал, что к нему подцепился winc.
Но вот нога irqn так и не дернулась. Все таки не понятно на какие события она дергается.
Буду дальше разбираться.


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

QUOTE (novartis @ Apr 30 2015, 00:16) *
а где про 12 мгц сказано?
Сказано устно разработчиками sm.gif Ну и экспериментально опробовано. Правда пробовалось с D21 в качестве мастера, у которой ноги точно в районе 12-16 МГц ограничены. Плюс я делал эксперименты на сравнительно старых прошивках.
ataradov
Я посмотрел на пример RTSP. Не знаю что именно происходит с закрытием соединения, я смотрел на пример без. В логе Wireshark видно, что VLC посылает запрос, получает ответ, закрывает соединение, создает новое соединение, посылает еще запрос, в этот раз без пути к файлу и с другой строкой User Agent. Потом VLC закрывает соединение, похоже так как не дожидается ответа на этот запрос.

Я не знаток RTSP и не могу быстро найти логов нормальной работы для сравнения. Но похоже, что нужно разбираться что происходит во втором соединении и запросе.
novartis
Разобрался с rtsp. В ответе на запрос SETUP добавил в конец /r/n. То есть в конце получилось /r/n/r/n. И после этого стал прилетать PLAY.

Еще разобрался с портированием под альтеровский ниос. Как уже писал, после того как понизил скорость spi до 20мгц, прерывание стало прилетать. Прерывание завел на кусисный pio. Повесил на него в ниосе стандартный обработчик, в конце обработчика вызываю isr() - это обработчик из атмеловских драйверов.
Атмеловский пример UDP client example полностью прошел.

Всем спасибо! Особенно ataradov за поддержку!
novartis
Опять возникли сложности wacko.gif .

В драйверах атмела есть функция 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
QUOTE (novartis @ May 25 2015, 00:15) *
Хотелось бы понять из-за чего это происходит, что это значит?
Это значит, что закончилась память под пакеты внутри модуля. Нужно ждать пока отправятся. И если долго не отправляется, то что-то сломалось sm.gif

В первую очередь стоит проверить и обновить версию прошивки на последнюю, из них баги вылизывают постоянно. В версиях до 17.0.0 у меня постоянно эти ошибки были.

QUOTE (novartis @ May 25 2015, 00:15) *
Если поднять Роутер на телефоне с андроидом 2.3
Можно подробнее, что именно и как "поднимается"?
novartis
Версия firmware - 18.0.3
Min driver ver 18.0.0
Curr driver ver 18.0.0
Вчера проверял в атмел студио, последние версии стоят.

На телефоне я включаю точку доступа. Winc коннектится к ней.

Вот в первом случае все работает, иногда пролетает дма аддр = 0, но не смертельно.

А во втором случае через 12-15 сек ломается без поворотно. А хотелось бы получить вариант задействовывания только одно телефона.
novartis
Вывел на печать dma_addr.
Получил такие цифры:
...
...
...
897860
910222
972144
972144
972144
972144
933022
910200
894442
0
0
0
0
0
...
То есть, сначала было много места, потом, бац, и нет места. Что-то ломается.
ataradov
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. Пока физически точку не отдал разработчикам - не верили, что есть баг. Будем надеяться, что эта история заставит их верить в новые баги sm.gif


QUOTE (novartis @ May 25 2015, 09:37) *
То есть, сначала было много места, потом, бац, и нет места. Что-то ломается.
Мне кажется этот dma_addr - это реальный адрес в памяти. И судить по нему как много места осталось - нельзя. Я так же не уверен сколько этой памяти под буфферы отведено.

Но кусок с 910222 позднее выделен как 910200 и 972144 выделен несколько раз подряд, то-есть до какого-то момента очередь освобождается.

Я поговорю с разработчиками и узнаю как они планируют такие вещи отлаживать.
novartis
Я кейс создал на сайте атмела, они мне ответили:
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
QUOTE (novartis @ May 25 2015, 10:36) *
ASF 3.23.1 я скачал, установил, а где брать 18.1 firmware не пойму, в атмел студио 18.0.0 предлагается.
Это может быть баг с нумерацией, думаю стоит попробовать его накатить. У меня на рабочем компе есть это обновление, но сегодня выходной.


Обратите внимание, что при обновлении нужно обязательно обновить и файлы на хосте, они опять протокол сломали.

Ну и скорее всего это не поможет.
ataradov
Описание проблемы ушло разработчикам.

Для обновления ПО нужно создать проект из примера WINC1500_FIRMWARE_UPDATE_AND_DOCUMENTATION. Но я тоже вижу только v18.0.3.

v18.1 существует, но видимо пока не опубликована.


Как выяснилось, v18.0.3 - это ошибка, на самом деле версия в последнем ASF v18.1.

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

novartis
Обновил прошивку и драйвер. Не помогло. Точно также через 12 сек падает. Пробовал уменьшать размер пачки данных, передаваемых по udp (300байт сделал, а было 970), и вводить паузу после отправки udp пакета - падает не через 12 сек, а через 40 сек.

В файлах драйвера не увидел значимых изменений. В основном лишние пробелы и табы поудаляли.

Спасибо, что передали разработчикам описание проблему. Может это и принесет результат.
ataradov
QUOTE (novartis @ May 28 2015, 01:07) *
Спасибо, что передали разработчикам описание проблему. Может это и принесет результат.
Их ответ стандартный - нужно воспроизводить на D21. Я понимаю, что это абсурд и мы не можем заставить каждого клиента покупать D21 Xpro просто чтобы багрепорты слать. Это со временем продет.

Если используется плата расширения XPro, то в зависимости от версии платы на ней либо есть разъем DEBUG UART или FTDI c USB. Нужно получить лог с этого разъема в момент падения.

И еще, что именно было изменено при порте на Microblaze?


А так же продолжайте теребить официальный саппорт. И номер кейса мне отправьте пожалуйста.
novartis
SAMD21 имеется, и разъем у него DEBUG microUSB (ну наверно там FTDI c USB). А как получить лог с этого разъема в момент падения?

При портировании под Nios (софт процессор Altera) заменил в nm_bus_wrapper_samd21.c в функции nm_bus_ioctl обращение к функции spi_rw на обращение к альтеровской функции - чтение/запись по spi. Прерывание от wnc посадил на стандартный обработчик Nios, в нем вызываю isr() - ту функцию, что вызывается у атмела. Вот в принципе и все.

Номер кейса 00017827.

ataradov
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
а, понял, может даже и получится собрать такой лог.
novartis
Снял лог с DEBUG UART,ничего интересного в нем нет, на TCP соединения две записи складываются, на UDP вообще никакой информации не добавляется. В момент падения, постоянного дма аддр =0, тоже ничего не выводится в лог.


Решил все таки проверить на SAMD21 как udp себя ведет. Открыл проект с примером от Атмел udp example. Там 10 удп засылок, сделал бесконечный цикл. Еще там пауза между засылками была, убрал ее. Вообщем точно также выскакивает дма аддр = 0.
Подконнектился к домашнему вифи роутеру Netgear jwr2000. Сначала вроде ничего, полет нормальный, иногда дма аддр проскакивали. Потом увеличил размер удп засылок, было байт 15, сделал 1400. Стало и на этом роутере отваливаться.

Если раньше у меня еще были сомнения, вдруг это я чего нахимичил в плис, spi не так дергаю, в коде атмела чего поломал, то теперь сомнений нет - косяк в их модуле, в их коде!
ataradov
QUOTE (novartis @ May 31 2015, 20:24) *
Если раньше у меня еще были сомнения, вдруг это я чего нахимичил в плис, spi не так дергаю, в коде атмела чего поломал, то теперь сомнений нет - косяк в их модуле, в их коде!

У меня и раньше сомнений не было sm.gif. Проблема убедить, но я над этим работаю. Они просто еще ни одного продута, который идет широкой публике не выпускали, так что они пока не знают, что такие проблемы им придется решать, а не отбрыкиваться тем, что покупаете мало. А кто будет покупать много, если оно не работает?

То-есть пример на D21 работает с Android 4.0 как нужно, а на Android 2.3 и Netgear jwr2000 - нет?

PS: я подписался на ваш кейс, но активно вмешиваться не буду. Я хочу посмотреть как официальный суппорт это разрулит.
novartis
D21 с андроид 4 почти сразу падает, с netgear с маленькими пакетами работало, с большими пакетами - упало. С андроидом 2.3, с которым у меня плиска нормально работает, забыл проверить(
ataradov
QUOTE (novartis @ May 31 2015, 22:22) *
D21 с андроид 4 почти сразу падает, с netgear с маленькими пакетами работало, с большими пакетами - упало. С андроидом 2.3, с которым у меня плиска нормально работает, забыл проверить(


Несовместимость с одним устройством - я еще могу понять, но несколько сразу - это очень странно.

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

Пришлите проект для D21, я попробую тут воспроизвести.
novartis
У товарища 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
строчка из hif_send:
Код
ret = nm_read_reg_with_ret(0x150400,(uint32 *)&dma_addr);


Вот читаем мы из winc регистр 0x150400, тем самым узнаем дма аддр, а может можно прочитать еще какой регистр и узнать сколько места есть в буфере, ведь по сути просто где то заканчивается место?
ataradov
QUOTE (novartis @ Jun 1 2015, 09:29) *
Вот читаем мы из winc регистр 0x150400, тем самым узнаем дма аддр, а может можно прочитать еще какой регистр и узнать сколько места есть в буфере, ведь по сути просто где то заканчивается место?


Все эти регистры не документированы и о них знать не положено. Все должно работать с предоставленным API. Это по-идее, конечно. Я пытаюсь сделать так, чтобы интерфейс был документирован и не менялся, но пока без особых успехов.

Я позже сегодня попробую погонять новую прошивку. Но у меня есть подозрение, что 1400 байт может быть слишком много. Хотя я пробовал слать звук чрез 1024-байтные пакеты и все работало.

Ну и 0 - это индикация, что пока что нет места. Это нормально при плотном потоке. А вот то, что оно зависает так на долго - это не нормально.
novartis
Код
Все эти регистры не документированы и о них знать не положено. Все должно работать с предоставленным API.

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

Размеры посылок я пробовал всякие, и 1400, и 500, и 220 байт. Результат один и тот же.

Спасибо вам за ответы, проект горит.
ataradov
Я смотрю на этот пример и офигеваю. Пр смыслу 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
И так, несколько наблюдений:
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
Здравствуйте.
Запустил ваш проект, изменил только 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
Похоже воспроизвел с Nexus 7 2013. Тоже падает все через несколько минут/секунд работы. Проверить с подключением не могу на нем правда.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.