andrewlekar

Сделал приём Ethernet фреймов через прерывание и начались проблемы - приложение (на lwip + ucos) работает минут 5, после чего начинает задерживаться при пингах, сбрасывать соединение TCP, возникают сообщения о расходе памяти lwip. Если сделать поллингом и проверкой указателя буфера DMA, то всё работает на ура. В чём может быть причина? Похоже на неправильную обработку прерывания. Однако системный таймер обрабатывается точно так же и не сбоит.

Проблема как выяснилось описана в Errata.

Наблюдаю странную вещь в работе Ethernet DMA. При отправке данных первый пакет шлётся, но индекс DMA TX Consume не изменяется. Аналогично и со вторым пакетом. Начиная с третьего пакета всё начинает работать как следует: Produce и Consume индексы меняются друг за другом. Можно было бы оставить как есть, но мне достаточно двух буферов TX, а в результате бага используются четыре буфера. Кто-нибудь встречал такую проблему?

Да, RomBOOT инициализирует последовательный порт и USB, посколько он именно через них заливает код в процессор. Однако гарантировать, что эти порты будут инициализированы при запуске уже зашитого софта я бы не рискнул. По поводу того, какой из загрузчиков что инициализирует, ссылку уже давали выше. Кроме того, можно просто посмотреть исходники - там всё ясно и наглядно. В любом случае их придётся пересобирать под себя.

Нигде не могу найти информацию, можно ли использовать VEXT вместо STATUS. То есть, можно ли считать, что у SIM900 VEXT всегда появляется не раньше, чем STATUS?

Точнее из этой ROM грузится только RomBOOT, о чём и написано в терминале. Bootstrap вместе с U-Boot и линуксом был благополучно стёр со флэшки.

Советую попробовать другие версии самбы. У меня заработала только 2.6.

В примере ещё выставляется размер адреса и ещё желательно выставлять размер опкода и размер данных. Кроме того, в I2Caccess не был размещен адрес, то есть там нули. В примере туда засунут адрес со сдвигом. Возможно в этом затык. В любом случае, даже если ваш I2C заработает, толку будет мало. В OpenAT до сих пор нет стабильного I2C. В лучшем случае будут перезагрузки и сбои. В худшем - мёртвое зависание.

Это разного уровня бутлоадеры. Суть в том, что флэш и озу на армах часто ставят внешние и их надо запускать, а загружать прошивку хочется с разных устройств и даже из сети. Поэтому есть загрузчик самого нижнего уровня под названием Boot Rom. Этот загрузчик позволяет загружать программы размером не более встроенной озу, поэтому им загружают Bootstrap. Bootstrap инициализирует внешнюю память и грузит U-Boot. U-Boot это уже полноразмерный загрузчик, позволяющий загружать что угодно откуда угодно. Как правило U-Boot используется для всяких линуксов. Если линуксов не планируется, то можно остановится на Bootstrap. Да, Bootstrap и U-Boot требуют перекомпиляции под свою периферию.

Через машину состояний как-то сильно круто. Для работы с модемом не актуально, потому что в один момент времени может быть только одно обращение к модему и можно тупо оформить цикл ожидания до прихода ответа. Внутри цикла поллинг других вещей типа индикации если нет оси. Если есть многозадачная ось, то вообще ничего дополнительно не требуется. Если всё-таки есть желание писать программу на конечных автоматах, то рекомендую погуглить QPC. Очень нехилый (и вроде бы живой) фреймворк. Имеет даже допиленный lwIP.

Да и 3 секунды для такой картинки это много. У меня оцифровка, ресайз и сжатие занимала без кэширования порядка секунды. С кэшированием насколько я помню около 0,3 секунды. Ну и простор для оптимизации ещё очень большой. Процессор AT91SAM9260.

При таких условиях можно всё же поставить вейвком, но ОпенАТ категорически не рекомендую. 3 года автономной работы он не выдюжит. Не в плане энергопотребления, а в плане надёжности. ОпенАТ как автономная платформа не очень хорош - случаются произвольные перезапуски, произвольная остановка приложения, зависание вплоть до аппаратного сброса. Так что маложрущий проц и вейвком дадут нужный результат.

Если из-за других задач возникают пропуски, значит неправильно выставлены приоритеты. Если приоритеты выставлены правильно, а пропуски всё равно возникают, значит не хватает вычислительной мощности и надо обновлять железо или править алгоритмы (можно проверить, отключив все задачи кроме обработки АЦП). ucos View это программка для оперативного наблюдения за состоянием оси. Работает просто - собирается вместе с рабочей программой и шлёт данные через ком-порт на ответную часть на компьютере.

Да. Но модем можно поискать с правильным спящим режимом, чтобы питание не дёргать.

На вейвкомах пониженное потребление сделать нереально.

А я бы предложил, чтобы вместо непонятного симкомовского сервера был тупо FTP. И формат служебной смски чтобы открыли (кстати, какая защита от смски с поддельного сервера?)

Странная зверюга. Она только ось умеет обновлять?

Попробуйте AT+CNMI=2,2,0,1,0 и ещё AT+CNMI=2,2,0,0,0.

В чём проблема портирования либ? Не использовать одну либу из разных задач и всё будет ок.

На своём модеме выполните команду ATI3 и напишите, что отвечает. Прошивать, скорее всего, нужно что-то из разряда fsu или fsup - что именно, лучше всего спросить в Компэле. Буквы h и g - это модификации модулей. У q2686/2687 версия с буквой G имеет в два раза больше памяти. Для q2406b самая последняя прошивка должна быть 6.57h. Однако перешивать крайне не советую - с тех пор как поставлялись q2406b многое поменялось и есть шансы получить проблем, особенно с TCP стеком. Да, и ещё, если ваш Fastrack довольно старый, то там скорее всего прошивка версии 6.xx, которая несовместима с той, которую вы скачали. И обновить её можно будет только через DwlWin (и входа BOOT). Если вы будете обновляться через DwlWin, то насколько я помню, он сам спросит, какой тип модема у вас используется и зальёт то что надо.

Наблюдается то же самое: не регистрируется ни одна симка, кроме МТС. Кто-нибудь победил?

Да, будем прикручивать SSL, скорее всего. Качественное шифрование - это требование вообще, я тут ничего не имел в виду. Реализация на наше усмотрение. Фрагментирование нужно в виде собирания пакетов, если те вдруг порежутся сетевым оборудованием. Фрагментирование на передачу скорее всего не понадобится, так как одна посылка будет не более 100 байт. Полная поддержка броадкаст пакетов вообще-то не требуется (только ARP чтоб ходило) - нужно только чтобы стек не падал при большом потоке таких пакетов.

Вроде как PolarSSL достаточно реально прикрутить. Исходники не сильно страшные и требования к памяти приемлемые. Задача - бессбойная, беспроблемная работа в сетях местного провайдера. Посему нужны DHCPc, DNSc, поддержка мультикаст, броадкаст, кое-каких ICMP, обработка фрагментированных пакетов, качественное шифрование. Ещё dynDNS желательно, но с ним я ещё не разбирался и это не так актуально. Я для того тему и поднял, чтобы не составлять собственное мнение по каждому из представленных продуктов, а с наибольшей вероятностью сразу выбрать лучшее решение.

Слышал мнение что этот стек довольно жирный. Мне хватит в LPC1768 места для стека, SSL и ещё хотя бы 4K ОЗУ свободных? Посмотрел TNKernel. Насколько это полноценный стек? Можно ли его сразу использовать в проекте?

Посоветуйте наиболее полный и наименее сырой TCP стек из бесплатных (или платных, но доступных для скачивания) для RTOS. Пока что наиболее подходящим вариантом представляется lwIP. Стек от микриума менее подходит из-за отсутствия в свободном доступе модулей DNS, DHCP, SSL для него и из-за отсутствия поддержки фрагментации, ограничений по ICMP. Говорят, что неплох NicheLite, но это урезанная версия NicheStack, а урезанность это не очень приятно. В частности нет поддержки multicast пакетов. Это не страшно, если стек из-за них не будет валиться. С другой стороны, легче будет запихать в не очень большую память процессора. Посоветуйте, что выбрать при таком раскладе.