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

Я запускаю стандартный пример от атмела UDP_CLIENT_EXAMPLE для winc. SPI работает, chip id считывается, версия прошивки считывается. В самом примере проходят функции m2m_wifi_init, m2m_wifi_connect. Никаких ошибок не появляется. Но в результате к роутеру модуль не подцепляется, на самом роутере он не появляется.

То-есть функция переданная через pfAppWifiCb вызывается с event==M2M_WIFI_RESP_CON_STATE_CHANGED и M2M_WIFI_CONNECTED == pstrWifiState->u8CurrState ?

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

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

А на счет того, что функция m2m_wifi_connect ничего не делает, я бы поспорил. Эта функция передает в вифи модуль параметры для коннекта (ssid,pwd). Я предполагаю, что она также дает команду модулю законектиться к данной вифи сети. Также я предполал, что после вызова этой функции и после того как модуль законнектится к вифи, модуль должен выставить прерывание и вызваться callback - wifi_cb. Может я и ошибаюсь насчет прерывания.

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно подробнее, что именно и как "поднимается"?

Версия firmware - 18.0.3
Min driver ver 18.0.0
Curr driver ver 18.0.0
Вчера проверял в атмел студио, последние версии стоят.

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

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

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

Вывел на печать dma_addr.
Получил такие цифры:
...
...
...
897860
910222
972144
972144
972144
972144
933022
910200
894442
0
0
0
0
0
...
То есть, сначала было много места, потом, бац, и нет места. Что-то ломается.

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

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

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


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

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

Я поговорю с разработчиками и узнаю как они планируют такие вещи отлаживать.