rudy_b

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

В стандартных случаях источником запроса на прерывание является периферия, DMA и т.п. Например при приеме байта UART при разрешенном прерывании, таймер, SPI и т.д. Они устанавливают запрос на прерывание, он отрабатывается процессором и запускается соответствующий обработчик прерывания. Для сброса источника прерывания, как правило, нужно считать соответствующий регистр или ручками сбросить бит в периферии. А, затем, снять бит в NVIC процессора. Последнее может делаться автоматически при возврате из прерывания по reti.

Сразу видно, что вы не умеете работать с прерываниями. В начале нужно сбросить не флаг прерывания, а источник запроса, и, только потом, сбрасывать флаг (pending бит)

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

У меня Мегафон. И действия операторов меняются быстро - проблемы 10-летней давности частично поправлены, но, похоже, взамен старых проблем появляются новые. Но, увы, у операторов нет никаких статей, хелпов, errat и т.п. Если бы они эти проблемы хотя бы обозначили - сколько времени было бы сэкономлено.

Ну вот, провел еще один эксперимент - открыл UDP сессию модема на 1 час 56 минут. Закрыл сессию сам по окончании эксперимента. Результат - ни адреса, ни порты за время сессии не изменялись, пакеты (с некоторой точностью - см. далее) ходили туда и обратно. Возможно мне повезло. Но выяснилась одна интересная подробность. В NAT, кроме внешнего адреса и порта есть, похоже, и еще один параметр - что-то типа "Разрешение трансляции внешнего пакета на локальный адрес модема". Этот параметр исходно выключен, но первый пришедший пакет его включает на время 16-20 минут (специально проверил, но грубо), а сам пакет пропадает (не транслируется). Если следующий пакет придет до истечения этого интервала - он пройдет и продлит интервал на это же время (это предположение, специально не проверялось). Если интервал между пакетами превышен, то пришедший пакет включит разрешение, но сам пропадет. Причем при открытии UDP сессии этот параметр отключен - вот почему пропадает первый ответный пакет сервера после открытия сессии. Т.е. для нормальной работы сервер должен посылать два пакета - первый, "просирающий" NAT, который может пропасть, и, только затем, второй с данными. И вот это уже почти точно проделки оператора. Да уж, накрутили ребята...

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

Не хочу спорить с опытным человеком, возможно вы правы. Мой опыт слишком невелик. Поживем - увидим, если поживем.

Именно до дисконнекта. Возможно и существуют какие-то таймауты разрывающие соединение, но их срабатывание автоматически приведет именно к дисконекту соединения. При этом сотрутся параметры NAT. Я, при тестировании, неоднократно висел в UDP довольно долго - несколько десятков минут без передачи пакетов и все работало. И модему нет необходимости долго висеть в UDP - послал запрос, получил ответ, завершил сессию.

В момент подъема GPRS модему присваивается локальный адрес, который сохраняется до отключения GPRS. В момент коннекта (запуска сессии UDP модема), формируются и сохраняются данные NAT, т.е. выделяются внешний адрес и порт и запоминается связь между внешним адресом и портом и локальным адресом и портом. Все пакеты, поступающие на выделенные внешний адрес и порт транслируются на соответствующий локальный адрес и порт. Вот на какой именно локальный порт - не знаю, задание порта UDP не влияет или незаметно. Запомненные параметры NAT должны сохранятся до дисконнекта (завершения сессии UDP модема). Так что у оператора нет проблем на какой локальный адрес отправить пакет, пришедший на конкретный внешний адрес и порт. Эта информация запомнена в NAT и сохраняется вплоть до дисконнекта. Другие данные поступающего пакета ( в частности порт отправителя) в общем случае не должны проверятся. То, что пакеты фильтруются по порту отправителя - это дополнительная фича.

Ух, тяжек путь познания. Запустил Wireshark и посмотрел ответные пакеты от моего UDP сервера и от SocketTest в одной сессии модема. Вы правы, контрольная сумма IP заголовка может быть равна нулю - и так и есть в обоих случаях. Пакеты различаются только в одной детали - порте отправителя. Мой сервер отвечает с того же порта, на который пришел пакет. А вот SocketTest отвечает с другого порта, то ли случайно выбранного, то ли назначенного, но изменить его ручками нельзя. Формально это вполне допустимо, но, похоже, не в этом случае. Получается, что оператор или сам модем блокируют пакеты, если порт отправителя не совпадает с тем портом, который был указан при коннекте. Можно предположить, для чего была сделана такая фильтрация. В старых форумах народ ругался на то, что как только открываешь UDP, на него начинает валиться разный мусор, предложения от операторов и т.п. Эти пакеты попадают в трафик и платит за них пользователь. Возможно оператор добавил такую фильтрацию для блокировки этого. А может это делает сам модем. Так что моя ругань на SocketTest неправильна, точнее не совсем правильна.

Что-то не похоже. Почему тогда мой UDP сервер, запущенный в тех же условиях вместо SocketTest не делает этой ошибки? И ответные пакеты от него (исключая первый) всегда доходят? А пакеты SocketTest не доходят никогда? Причем и адрес и порт те же. Т.е. совершенно очевидна ошибка именно в пакете.

Разобрался с SocketTest 3.0.0. Внимательно посмотрел ответные пакеты Wireshark. Раньше смотрел только адреса и порты, а сейчас влез в заголовок ответного пакета. В нем обнаружилось несовпадение контрольной суммы заголовка: Header checksum: 0x0000 [incorrect, should be 0x3589 (maybe caused by "IP checksum offload"?)] Вероятно поэтому ответные пакеты и не доходят до модема. Не пользуйтесь этой программой. Заодно еще раз внимательно посмотрел пинг средствами модема. Картина та же - первый запрос - всегда таймаут, три последующих проходят нормально. Ну, вроде теперь все понятно, кроме того кто виноват -модем или оператор. Спасибо всем ответившим. Когда доберусь до SIM800C отпишусь, правда это будет не скоро.

А потому, что я делал только одну попытку связи с сервером NTP в одной UDP сессии. Ессно ответного пакета я не получал. А потом я перезагружал UDP сессию и делал следующую попытку. С тем же результатом. Вместо того, чтобы сделать несколько попыток в одной сессии. А при использовании NTP команд модема, я (фиг знает почему) делал несколько попыток в одной сессии - и все работало со второй попытки. А догадаться, что только первый ответный пакет пропадает - мозгов не хватило. И еще - в режимах чистого UDP я использовал чужой сервер SocketTest 3.0.0. Причем проверил его в режиме TCP - отлично работает в обе стороны. А вот в режиме UDP - оказалось глючит. Сервер слушал заданный порт, входящие пакеты получал и показывал адрес и порт отправителя - все честно. Отправка ответных пакетов делалась ручками (задание адреса и порта из входного пакета). Но вот модем этих ответных пакетов не получал и сейчас не получает, ни первого, ни следующих. Что-то в этом сервере не то, но продукт чужой, фиг его знает в чем дело. А когда написал свой UDP сервер - сразу начал получать ответные пакеты кроме первого и стало все понятно. Другого модема сейчас нет. Но скоро буду делать нормальный модем на SIM800C, вот тогда и посмотрю что там будет. Пока точно неизвестно кто глючит - модем или оператор.

Проверил. В одной UDP сессии и первый и все последующие пакеты приходят на сервер с одного и того же адреса и порта. Заодно проверил NTP через UDP. В одной UDP сессии делаю 4 запроса. Первый - не выполняется, на остальные три ответ нормальный. Т.е. пропадание первого ответа в UDP сессии подтверждается и тут. P.S. Заодно проверил и NTP через соответствующую функцию модема - та же история, первый запрос пропадает следующий проходит нормально. Вот такие пироги...

Возможно. Но, он иногда перебрасывает меня на другой "фиг его знает что" и при этом модем дает отдельное сообщение. Здесь его нет. Кроме того, после получения локального IP при подъеме GPRS он не имеет права это делать. Я смотрел - локальный адрес и порт модема я специально не выставляю, они равны нулю. Кстати надо бы попробовать снова задать UDP порт и посмотреть что будет. Я раньше его задавал, но, потом, в экспериментах, перестал. И после коннекта все пакеты к серверу идут с одного и того же адреса и порта (и первый и остальные), т.е. адрес и порт стабильны. Но это навскидку, специально не отслеживал, проверю. В этот момент, точнее при коннекте, должны задаваться и запоминаться параметры прокси (NAT). И они должны быть строго постоянны до дисконнекта. Нет, у меня нет другой симки для модема. Можно попробовать симку из телефона, но как-то не хочется, да и оператор тот же. У меня SIM800L. Да и работает все исправно с точностью до первого ответа.

Не поленился и нарисовал свой сервер UDP. И вот что получилось. Запускаю UDP на модеме, connect ->connect ok Send ... ->send ok. Мой сервер получает пакет, отвечает на него, но модем ответа не получает. На все последующие send - модем нормально получает все ответы, вплоть до завершения сессии (disconnect, shut). Т.е. пропадает только первый ответный пакет сервера после connect. Пробовал поставить задержку ответа сервера на 10 сек - ровно то же самое. При повторном запуске UDP - то же самое. Чудеса... Зато стало понятно почему у меня NTP через UDP не работал, я не делал повторных попыток получить время, точнее делал, но каждый раз перезапускал сессию UDP. А надо было сделать несколько попыток в одной сессии.

Это все равно UDP, просто в пакете ICMP строго определена структура данных.

Да, без проблем. Но вот что меня смущает и заставляет думать, что я что-то не то делаю. Ведь запросы ping и NTP проходят нормально через соответствующие функции модема. А если посылаю их через UDP - не проходят (по крайней мере NTP). А ведь это тоже пакеты UDP. Что-то тут не то, еще поиграюсь.

Я правильно понял, вы намекаете на то, что в моих проблемах с UDP виноват оператор? А можно поподробнее, если несложно? Решение через MQTT вероятно возможно, но как-то не очень хочется надеяться на чужого дядю, сегодня он есть, а завтра его нет. Это меня тоже беспокоит и, думаю, универсального решения нет. GSM и сама по себе небольшой подарок, надежность ниже плинтуса.

Согласен, можно использовать TCP а не UDP для решения задач. Но мне сейчас важно выяснить что, собственно, умеет делать подобный модем (SIM800L), раньше с GSM не работал. Саму разработку буду делать, вероятно, на SIM800C. Сама задача дурацкая, ТЗ практически нет, что понадобится завтра неизвестно (но совершенно точно понадобится - аппетиты растут по мере еды), поэтому приходится делать с запасом и хорошо понимать, что можно делать и чего это будет стоить. Звонки, SMS, email, NTP, TCP проверил, FTP пока не нужно, но думаю, оно заработает. А вот с UDP неожиданно напоролся и хочу понять в чем дело и кто виноват. Оператора сменить конечно можно, но надеюсь понять, он ли виноват, или я где-то что-то не то делаю. Может найдутся люди работающие с UDP без белого адреса и через Мегафон и подскажут.

А вот у меня работает только в одну сторону. И непонятно в чем дело, работа по по UDP и TCP практически одинакова, но по TCP пакеты ходят в обе стороны, а по UDP - только от модема к серверу. Может что-то еще нужно сделать? Не поделитесь вашим кодом?

Именно это и требуется. И мне неважно через какой адрес и порт транслируются пакеты. Важно что ответные UDP пакеты на этот адрес и порт исчезают. Да, это проверено.

У нас несогласованность в терминах. Под proxy я подразумеваю то же самое, что и вы под NAT, т.е. подмену адреса и порта при прямой и обратной трансляции пакетов. И все, что выговорите совершенно справедливо. И, ессно, обмен идет только через прокси (NAT). При запуске GPRS я получаю локальный адрес 10.237.141.82. На сервер TCP/UDP приходит пакет с адреса 188.170.81.135, порт 61469. В UDP, даже если сервер не запущен, при CIPSTART я все равно получаю connect. Т.е. при UDP connect используется только для прокси (NAT), что естественно, наличие сервера на реальном адресе UDP даже не проверяется в отличие от TCP. Но зачем блокировать ответные пакеты UDP?

Похоже это проделки оператора. Понятия connect нет в UDP. Оно вводится специально для прокси сервера, чтобы он запоминал параметры переадресации на время существования коннекта, а потом забывал. Специально проверил - если отправляю несколько пакетов UDP после коннекта - они приходят на сервер с одного адреса и порта. После disconnect-connect они приходят уже с другого адреса и порта. Похоже, что Мегафон специально заблокировал ответные пакеты UDP, чтобы пользователь заплатил за использование фиксированного адреса. Это, в какой-то мере разумно, можно будет сразу посылать пакеты на модуль. Но могли бы и не блокировать, насколько я смотрел разные обсуждения - раньше это работало.