Wi-Fi-микросхема Atmel WINC1500, и модуль на её основе Опции

[WLESS.RU]

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

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

[Rash]

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

[ataradov]

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

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

[Rash]

WILC1000 - наверное то, что нужно. Подождём документации и примеров для работы.

[ataradov]

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 пакеты.
 MYWINC1500_TCP_SERVER_electr.zip ( 9.16 мегабайт ) Кол-во скачиваний: 86

[novartis]

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

[ataradov]

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

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

[novartis]

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

[ataradov]

я использую программную обертку от Атмел, чуток урезанную. Но ведь есть у них документ WINC1500_SPI_Porting_Guide. С какой целью они его распространяют?

Чтобы портировать эту прослойку на свое железо. Если SPI запрограммирован правильно и обработчик прерывания вызывается при появлении прерывания на ножке, что все должно работать. Для этого коды самих прерываний и когда они происходят знать не нужно.

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

В соответствии с этим документом портировал драйвера под альтеровский ниос. В ниосе я прочитал 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]

Никаких ошибок не появляется. Но в результате к роутеру модуль не подцепляется, на самом роутере он не появляется.

То-есть функция переданная через 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]

Не совсем понял насчет pfAppWifiCb.

pfAppWifiCb - это член в структуре, через которую происходит инициализация callback-а (в вашем случае это видимо wifi_cb). Поиск по программе должен найти это место, так как сам по себе wifi_cb без регистрации вызваться не будет. У меня под рукой сейчас нет исходников и слишком поздно и лениво качать что-либо.

А на счет того, что функция m2m_wifi_connect ничего не делает, я бы поспорил.

Под "ничего не делает" я подразумевал, что успешный код завершения от нее не говорит об успешном присоединении, только о правильности параметров.

А вообще я бы рекомендовал начать с D21 Xpro. А так выходит слишком много переменных - новое железо с новым процессором.

[novartis]

Сдвинулось дело!
Понизил частоту spi с 40мгц до 20мгц и коннект состоялся - роутер сказал, что к нему подцепился winc.
Но вот нога irqn так и не дернулась. Все таки не понятно на какие события она дергается.
Буду дальше разбираться.


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

[ataradov]

Понизил частоту spi с 40мгц до 20мгц и коннект состоялся - роутер сказал, что к нему подцепился winc.

Рекомендованная максимальная частота - 12 МГц. Выше - там ни процессор внутренний не справляется ни пропускной полосы ножек не хватает для нормальной передачи сигнала.

[novartis]

В даташите написано 48мгц максимум для spi, а где про 12 мгц сказано?

[ataradov]

В даташите написано 48мгц максимум для spi,

Это хорошо, что сейчас есть DS . Когда я впервые с этим модулем игрался его не было. Так что это может быть и так, но ПО внутри точно на 48 МГц данные не сможет принять.

а где про 12 мгц сказано?

Сказано устно разработчиками Ну и экспериментально опробовано. Правда пробовалось с D21 в качестве мастера, у которой ноги точно в районе 12-16 МГц ограничены. Плюс я делал эксперименты на сравнительно старых прошивках.

[ataradov]

Я посмотрел на пример RTSP. Не знаю что именно происходит с закрытием соединения, я смотрел на пример без. В логе Wireshark видно, что VLC посылает запрос, получает ответ, закрывает соединение, создает новое соединение, посылает еще запрос, в этот раз без пути к файлу и с другой строкой User Agent. Потом VLC закрывает соединение, похоже так как не дожидается ответа на этот запрос.

Я не знаток RTSP и не могу быстро найти логов нормальной работы для сравнения. Но похоже, что нужно разбираться что происходит во втором соединении и запросе.

Сообщение отредактировал ataradov - Apr 30 2015, 16:32

Прикрепленные файлы

 wo_close.zip ( 1.67 килобайт ) Кол-во скачиваний: 30

 

[novartis]

Разобрался с rtsp. В ответе на запрос SETUP добавил в конец /r/n. То есть в конце получилось /r/n/r/n. И после этого стал прилетать PLAY.

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

Всем спасибо! Особенно ataradov за поддержку!

[novartis]

Опять возникли сложности .

В драйверах атмела есть функция 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]

Хотелось бы понять из-за чего это происходит, что это значит?

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

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

Если поднять Роутер на телефоне с андроидом 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]

Версия firmware - 18.0.3

Да, это последняя.

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

С воспроизведением этого тут могут быть проблемы, так как мобильные операторы отключают эту возможность в телефонах. Нужно будет разлоченый телефон искать.

А во втором случае через 12-15 сек ломается без поворотно. А хотелось бы получить вариант задействовывания только одно телефона.

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

То есть, сначала было много места, потом, бац, и нет места. Что-то ломается.

Мне кажется этот 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]

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]

Спасибо, что передали разработчикам описание проблему. Может это и принесет результат.

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

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

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


А так же продолжайте теребить официальный саппорт. И номер кейса мне отправьте пожалуйста.

Сообщение отредактировал ataradov - May 28 2015, 15:30

[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]

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]

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

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

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

PS: я подписался на ваш кейс, но активно вмешиваться не буду. Я хочу посмотреть как официальный суппорт это разрулит.

[novartis]

D21 с андроид 4 почти сразу падает, с netgear с маленькими пакетами работало, с большими пакетами - упало. С андроидом 2.3, с которым у меня плиска нормально работает, забыл проверить(

[ataradov]

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.
 WINC1500_SIMPLE_UDP_EXAMPLE_18.1.1_____me.zip ( 2.25 мегабайт ) Кол-во скачиваний: 73

[novartis]

строчка из hif_send:

Код

ret = nm_read_reg_with_ret(0x150400,(uint32 *)&dma_addr);

Вот читаем мы из winc регистр 0x150400, тем самым узнаем дма аддр, а может можно прочитать еще какой регистр и узнать сколько места есть в буфере, ведь по сути просто где то заканчивается место?

[ataradov]

Вот читаем мы из winc регистр 0x150400, тем самым узнаем дма аддр, а может можно прочитать еще какой регистр и узнать сколько места есть в буфере, ведь по сути просто где то заканчивается место?

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

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

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

[novartis]

Код

Все эти регистры не документированы и о них знать не положено. Все должно работать с предоставленным API.

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

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

Спасибо вам за ответы, проект горит.

[ataradov]

Я смотрю на этот пример и офигеваю. Пр смыслу sock_bind_state будет снова 1 после приема ответа от прилагаемого питоновского скрипта.

Вот только прем начинается после

printf("socket_cb: sendto success!\r\n");

и у меня они никогда не выполняется, так что в логе только

-- 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, 20:08

[ataradov]

И так, несколько наблюдений:
1. В приложении WINC1500_SIMPLE_UDP_EXAMPLE логика ожидает, что событие SOCKET_MSG_SENDTO произойдет, и в то же время индикация отключается во время открытия сокета:

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 и ничего больше.

Прикрепленные файлы

 WINC1500_SIMPLE_UDP_CLIENT_EXAMPLE1.zip ( 2.19 мегабайт ) Кол-во скачиваний: 14

 

[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. Тоже падает все через несколько минут/секунд работы. Проверить с подключением не могу на нем правда.

[ataradov]

Проблема похоже починена в v18.3.1. Она должна появиться в ASF на следующей неделе. Я спросил, но не думаю, что мне разрешат распространять эту прошивку раньше срока.

---
Отправил PM со ссылкой на прошивку. Проверьте, что она работает с вашими устройствами. Эта прошивка починила Nexus 7 и HTC Desire. Оба не работали с v17.

Сообщение отредактировал ataradov - Jun 3 2015, 22:36

[novartis]

Большое СПАСИБО!
Вечером попробую обновиться.
Сейчас добавил в проект возможность включения точки доступа на winc. В этом режиме зависаний не происходит.
Итого у меня сейчас есть три варианта:
1. winc как АР - зависаний нет (телефон хоть с интернетом, хоть без него)
2. winc коннектится к АР-телефону, на телефоне включен мобильный интернет - зависаний нет
3. winc коннектится к АР-телефону, на телефоне выключен мобильный интернет - происходит зависание

[novartis]

Если долго подождать и много погонять, то падают все три варианта.

Посмотрим, что будет после обновления прошивки.

[ataradov]

Посмотрим, что будет после обновления прошивки.

Я гоняю новую прошивку. Ее сейчас не так легко убить, но все-равно после 20-30 минут непрерывного траффика на максимальной скорости, модуль начинает возвращать -14. Но это уже скорее всего не связано с телефон/ не телефон.

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

[novartis]

Обновился до 18.3.1. Чуток по лучше, но все равно падает.
Самый стабильный режим - когда winc работает как АР, работал полчаса, ниразу дма аддр не было.
А в другом режиме через 5 минут упало.

Надо все таки ждать от разработчиков прошивку, стабильную во всех режимах.

[ataradov]

Надо все таки ждать от разработчиков прошивку, стабильную во всех режимах.

Если просто ждать, то не дождаться ее. Проблема существует (или проявляется) только на точках доступа из телефонов и прочих мобильных устройств. Думаю, что это из-за их скорости.

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

5 минут - это очень быстро. Это с моим приложением так?

[novartis]

Я свой проект тестировал, на плис.
Подключался не только к мобильнику, коннектил Winc к домашнему роутеру, также падает.
Насчет саппорта вы правы, напишу еще в кейс.

[ataradov]

Подключался не только к мобильнику, коннектил Winc к домашнему роутеру, также падает.

Это странно. Какая нагрузка по траффику в этом случае?

Мне кажется, это придется воспроизводить с D21. Если есть реальная проблема с настоящими роутерами, то это значительно хуже и будет проще ускорить починку.

[Расул]

Ребят, у меня вопрос.
Никогда раньше не имел дело с Wi-Fi и хотел спросить, насколько ценник $12,28 ATWINC1500 адекватен за его возможности?
Чем он лучше ESP8266 за $5?
Что лучше подошло бы для серийного изделия, которое просто должно уметь получать погоду по интернету и управляться с мобильного телефона?

[ataradov]

насколько ценник $12,28 ATWINC1500 адекватен за его возможности?

Это очень хорошая цена за модуль в единичных количествах, но учитывайте, что ПО частично сырое и в граничных условиях есть баги, но они фиксятся оперативно.

Чем он лучше ESP8266 за $5?

Наличием сертификаций и соответствием стандартам.

Что лучше подошло бы для серийного изделия, которое просто должно уметь получать погоду по интернету и управляться с мобильного телефона?

Однозначно WINC1500, если не хочется вкладывать еще несколько десятков тысяч долларов в сертификацию или несколько сотен тысяч в штрафы.

Про применимость той сертификации в России нужно смотреть отельно.

[Расул]

Это очень хорошая цена за модуль в единичных количествах, но учитывайте, что ПО частично сырое и в граничных условиях есть баги, но они фиксятся оперативно.

Там стоимость $12 при покупке 500 штук. Это на сайте у них так. На mouser.com цены примерно такие же.
Спасибо огромное за ответ!
Мне случайно достался в руки этот ATWINC1500 и он пришелся кстати) Хочу сделать игрушку и если людям понравится, то может попробую опытную партию изготовить.
Раз уж на то пошло, то хотел еще маленький вопросик задать: у меня есть связка SAMD21 (Cortex-M0+ CPU, 48MHz) и этот Wi-Fi модуль. Справится ли такая связка с такими задачками:
1. работать с RSS
2. принимать почту и парсить принимаемый текст
3. принимать команды от устройств в локальной сети (то есть работать как простенький сервер)?

Сообщение отредактировал Расул - Jun 13 2015, 16:30

[ataradov]

1. работать с RSS
2. принимать почту и парсить принимаемый текст
3. принимать команды от устройств в локальной сети (то есть работать как простенький сервер)?

Зависит от нагрузки, особенно часть про сервер. В принципе я не вижу особых проблем, принимая во внимание, что сервер работает на МК на 48 МГц.

[Расул]

ataradov благодарствую!
Будем работать)

[novartis]

Мне кажется, это придется воспроизводить с D21. Если есть реальная проблема с настоящими роутерами, то это значительно хуже и будет проще ускорить починку.

Давно не писал. После обновления до 18.3 на D21 не удается фатально уронить систему. Работает, не падает. В режиме отправки udp пакетов получил скорость 1.9Мбит/с. Это бесконечный цикл, в котором без пауз засылаются пакеты. Быстрее уже и не сделать.

На моей системе с плис скорость udp доходит до 6Мбит/с. Наверно из-за этого на ней иногда происходит фатальное зависание. Так то работа над проектом закончена.

ataradov благодарствую!

[Inanity]

Здравствуйте.

Тоже использую данный модуль в связке с ПЛИС. Кто какой скорости достигал в режиме TCP?
Мой показатель пока 5.45 МБ/c. (Режим SPI 24мгц.)

Сообщение отредактировал Inanity - Jun 15 2015, 16:55

[novartis]

Здравствуйте.
А расскажите о своей системе, что за плис используете?
Я tcp чуток задействовал, там буквально несколькими запросами обмен происходит, так что скорость там не нужна.
SPI на 25мгц работает.
По скорости у меня сложилось такое представление.
Вот прикрепил картинку.
Загнать в spi данные можно очень быстро, ничего в принципе не мешает, с частотой 25мгц можно гнать. И получим все 25 мбит/с.
Но на каждый мой sento() приходит прерывание, которое нужно обработать. Обработка заключается в считывании, что же за прерывание пришло, обнуление регистра прерывания в winc, вызов коллбеков. Все это - разовые запросы по spi, а вот они очень медленные у меня получились, пока ниос вызовет функцию, пока ей передаст данные, пока дождется, когда аппаратные spi отправит данные в винк и т.д. На это в лучшем случае у меня получилось 180 тактов частоты 100мгц. И таких порций по 180 тактов уйма.
Потом при вызове sendto() драйвер сперва сообщает винку, что он сейчас будет передавать udp данные, формирует заголовок IP, заголовок UDP и т.д.
Это опять небольшими обращениями по spi. И это опять уйма порций по 180 тактов.

У вас скорее всего точно также получается. Сами данные то быстро запихиваются, а вот обработка и подготовка - половина времени.

[Inanity]

А расскажите о своей системе, что за плис используете?

ПЛИС Xilinx Spartan-6. Соответственно microblaze на частоте 96мгц (96/4 = 24 - SPI). Для управления используем исходники атмела (правда, там дикая вложенность в функциях, надо переписывать всё). Первоначально управляли модулем через ядро SPI-AXI, но там CS дергается вручную (записью в регистр), поэтому медленно получалось. Заменили на Quad-SPI-AXI, там CS аппаратный, данные пишутся
в FIFO и отправляются. Отправляем команду, потом 256 байт данных. В таком виде это дало 5.45Мб/с. Пока делаем профайлинг, может можно ещё что-то оптимизировать.

Интересно, какой объём данных модуль может за раз принять? т.е. в после одной команды и в течение опущенного CS?

Сообщение отредактировал Inanity - Jun 16 2015, 12:12

[novartis]

Я сперва использовал альтеровский компонент SPI, но после стал искать на чем скорость падает, обнаружил, что их компонент слишком много не нужных (мне не нужных) операций делает, типа, проверка готовности, сброс регистра ошибок чтения, в который выставляется ошибка, если производилась только запись, и т.п. Написал свой spi компонент, это позволило ускорить работу.

По поводу объема данных, который модуль может принять за раз.
Посмотрит файл nm_bus_wrapper_samd21.c, там есть такой дефайн: #define NM_BUS_MAX_TRX_SZ 2048
Изначально там 256.

Еще посмотрите файл nmbus.c, функцию nm_read_block (в nm_write_block аналогично):

Код

    uint16 u16MaxTrxSz = egstrNmBusCapabilities.u16MaxTrxSz - MAX_TRX_CFG_SZ;
    uint32 off = 0;
    sint8 s8Ret = M2M_SUCCESS;

    for(;;)
    {
        if(u32Sz <= u16MaxTrxSz)
        {
            s8Ret += p_nm_read_block(u32Addr, &puBuf[off], (uint16)u32Sz);
            break;
        }
        else
        {
            s8Ret += p_nm_read_block(u32Addr, &puBuf[off], u16MaxTrxSz);
            if(M2M_SUCCESS != s8Ret) break;
            u32Sz -= u16MaxTrxSz;
            off += u16MaxTrxSz;
            u32Addr += u16MaxTrxSz;
        }
    }

    return s8Ret;

По сути, если вы засылаете (или читаете) блок данных по spi, больше, чем NM_BUS_MAX_TRX_SZ-MAX_TRX_CFG_SZ, то драйвер разбивает их на порции.

Я с этим столкнулся, когда пытался с помощью sendto() в udp засунуть 1400 байт, и подофигел, увидев в wireshark'e вместо одного пакета аж шесть пакетов.

Параметр увеличил до 2048, но по udp максимальный блок засылаю 970 байт, больше - какие то проблемы возникли у драйвера, уже не помню подробности.

[Vasiliy Vershini...]

Не могу загрузить прошивку используя UART. Подключил шнурок непосредственно к модулю, подал питание ChipEnable и сброс.

батник для загрузки, поставляемый производителем вываливает следующее

CODE

Mode UART
Downloading Image...
********************************************
* >Programmer for WINC1500 SPI Flash< *
* Owner: Atmel Corporation *
********************************************
Firmware Path (2B0) C:\REL_ATWINC1500_AT_COMMAND_V0_9_1_20160311\firmware_tools\
firmware\m2m_aio_2b0.bin
Firmware Path (3A0) C:\REL_ATWINC1500_AT_COMMAND_V0_9_1_20160311\firmware_tools\
firmware\m2m_aio_3a0.bin
>>Initialize programmer.
Detecting ports...
(APP)(ERR)[nm_bus_port_detect][577]Failed to find any COM ports
0 of ports found
(ERR)Failed To intilize programmer
Fail
#######################################################################
## ##
## ######## ### #### ## ##
## ## ## ## ## ## ##
## ## ## ## ## ## ##
## ###### ## ## ## ## ##
## ## ######### ## ## ##
## ## ## ## ## ## ##
## ## ## ## #### ######## ##
## ##
#######################################################################

Попытка запустить АТ-прошивку (если она с завода зашита???) тоже не увенчалась успехом. Модуль реагирует на сброс и CE изменяя потребление.

[WLESS.RU]

Не могу загрузить прошивку используя UART. Подключил шнурок непосредственно к модулю, подал питание ChipEnable и сброс.

батник для загрузки, поставляемый производителем вываливает следующее

CODE

Mode UART
Downloading Image...
********************************************
* >Programmer for WINC1500 SPI Flash< *
* Owner: Atmel Corporation *
********************************************
Firmware Path (2B0) C:\REL_ATWINC1500_AT_COMMAND_V0_9_1_20160311\firmware_tools\
firmware\m2m_aio_2b0.bin
Firmware Path (3A0) C:\REL_ATWINC1500_AT_COMMAND_V0_9_1_20160311\firmware_tools\
firmware\m2m_aio_3a0.bin
>>Initialize programmer.
Detecting ports...
(APP)(ERR)[nm_bus_port_detect][577]Failed to find any COM ports
0 of ports found
(ERR)Failed To intilize programmer
Fail
#######################################################################
## ##
## ######## ### #### ## ##
## ## ## ## ## ## ##
## ## ## ## ## ## ##
## ###### ## ## ## ## ##
## ## ######### ## ## ##
## ## ## ## ## ## ##
## ## ## ## #### ######## ##
## ##
#######################################################################

Попытка запустить АТ-прошивку (если она с завода зашита???) тоже не увенчалась успехом. Модуль реагирует на сброс и CE изменяя потребление.

Василий, вроде прошивку через UART производитель и не обещал, или что-то поменялось сейчас?
Насколько помню, процедура была разработана для прошивки через SPI и использования отладочной платы Xplained PRO.
Мы для прошивки модулей делали плату с пружинящими "илогками", подключали к отладке и прошивали.
Если хотите - дадим попользоваться.
---------------------------------------------------------------
Извиняюсь, отстал от жизни)!
Действительно, теперь можно шить и по UART, и это хорошо!
Смущает только предупреждение в http://www.atmel.com/Images/Atmel-XXXXX-AT...icatio_Note.pdf:
Several previous versions of ATWINC1500 AT command firmware(version 0.6.1 ~ 0.7.8) used auto start mode on UART2by programming an eFuse. These versions are incompatible with the current version so an ATWINC1500 module which has been programmed with one of these versions can’t use the current version again...

Ждем комментариев Алекса Тарадова)

Сообщение отредактировал WLESS.RU - Jun 30 2016, 07:53

[alexsy_butyaev]

Парни я только начал работать с WINC1500. Не можете описать всё воркфлоу как правильно проапдейтить фирмваре. где взять бинарные файлы.

[WLESS.RU]

Парни я только начал работать с WINC1500. Не можете описать всё воркфлоу как правильно проапдейтить фирмваре. где взять бинарные файлы.

Поройтесь в проектах Atmel Studio для WINC1500 - там и мануал подробный, и файлы прошивки должны быть.

[Dopler]

Здравствуйте.
Стал счастливым обладателем данного модуля, пытаюсь подключить к STM32 на собственной плате. Framework скачал с сайта атмела отдельно, AVR studio 7.0 установлена, но я ей не пользуюсь (последней студией, которой пользовался была 4.19 и Avr32Studio).
Пример под STM адаптировал, естественно получаю ошибку M2M_ERR_FW_VER_MISMATCH. (драйвер 19 версии, прошивка 17.1).
Сейчас модуль распаян проводками, один раз к компьютеру подключить я могу, но что делать дальше? Как вообще атмел планировал применять эти модули в готовых системах? На AvrFreaksнарод тоже интересуется этим вопросом, но внятного ответа я не увидел.

[Dopler]

Похоже атмел загибается (уже загнулся?). Сайт третий день не работает, никаких файлов скачать нельзя. Мануалы по обновлению прошивки и по запуску примеров не соответствуют действительности (7-й студии). Несколько часов искал, где вообще прошивка лежит. С первого раза ничего не зашилось, не может найти компорт. Судя по всему проблема такая не только у меня, вот товарищ написал развернутый мануал.
http://community.atmel.com/forum/how-firmw...25-xplained-pro

Вообще хоть кому-нибудь удалось апгрейдить прошивку без отладочной платы samd21?

[Dopler]

В итоге смог обновиться через мост USB-UART. Почему-то долго не получалось, так и не понял, что нужно сделать, чтобы работало. Похоже в модуле есть какой-то таймаут, после которого загрузчик перестает ждать прошивки. Если включить USB, потом сразу модуль (нужные сигналы сброса у меня внешний МК формирует), потом сразу утилиту, то все работает.
Самый последний документ по поводу прошивки лежит в папке ASF
xdk-asf-3.33.0\common\components\wifi\winc1500\firmware_update_project\doc