Rash

Я ж думаю одесситы в следующей версии добавили возможность перезагрузки в этом случае и больше не будут вешать модули с искрящими элементами. Всё да не возможно, но то что в голову пришло и то, что ранее опытом получено, думаю необходимо предусматривать. Я уже проходил непредусмотренное программное состояние для приёмопередатчика (не GSM), когда можно сказать прожил месяц в шахте и каждый день наматывал по несколько километров там. Но там свои проблемы с питанием из-за искробезопасности и помех хватает. После общения с производителем, я сделал управление приёмопередатчиком не по даташиту, и проблема решилась. Заодно добавил таймауты на кучу состояний при работе с ним, т.к. ещё раз попадать так желания не было. Поэтому для меня время выполнения секунды, это вечность, На отладку уходит много времени. Стараюсь все всегда сделать с минимальным временем исполнения, все интерфейсы через DMA, отдельными библиотеками отвязанными от приложения, даже если задача этого не требует, что бы быстрее отладить возможные состояния, даже те которые не предусматриваются.

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

Ув. CADiLO, скажите, что из приведенных Вами цитат документации я не выполнил? Я жду 2 секунды на несчастную команду AT В случает ответа, следующую команду я посылаю не раньше чем через 50 мсек. Допустим ответа нет никакого, как мне узнать об этом? если: В самой посылке всё в норме. Посылка не меняется от времени. Могу снять ещё раз логическим анализатором Saleae и показать, если проведений выше информации недостаточно. Могу даже плату прислать, что б убедиться в этом.

Модуль на AT команду отвечает. И отвечает 2 раза. В Логе я прокомментировал строчки. *Первый раз послал AT * Жду ответ, если в течении 2-х секунд * Ответа нет, посылаю команду AT ещё раз * Приходит ответ OK, практически сразу (как я понимаю на первую команду AT) * Потом ещё через время, приходит ещё раз ответ OK (как я понимаю на вторую команду AT) Команда AT показана для примера, такое может произойти с любой командой, если модуль не отправил ответ в отведенный мной таймаут. Возникает такое не всегда. От наличия Сим карты не зависит, от включённого BT модуля тоже, питание стабильно 4.1В. Время контролировалось логическим анализатором.

Скорость фиксированная 9600 кбит/сек (было и 115200 разницы не заметил). AT посылая для проверки, что модуль живой. Вместо AT может быть любая другая команда. Это пример. Вопрос в другом, как корректно обработать таймауты если вдруг ответ не получен (не важно по какой причине) или получен сбойный пакет?

Добрый день. Есть несколько вопросов относительно правильной последовательности при общении AT командами с SIM800R? 1. В SIM800R была передана AT команда, но на неё нет ответа или пришел ошибочный (битый) ответ. Что делать по истечению определённого таймаута? Какое это должно быть время (хотя бы для команд независимых от сети)? Предполагаю, что если нет ответа, то необходимо послать эту команду ещё раз, например через 1..5 секунд. Но этот метод не эффективный, т.к. на самом деле модуль задумывается (это уже выяснили почему) и даёт ответ потом на две команды подряд. Например: AT // Проверка связи и ждём 2 секунды ответа AT // ответа нет, истёк таймаут, посылаю ещё раз OK // ответа на 1-ую команду AT AT+CBC // Запрос напряжения АКБ, т.к. я получил OK на предыдущую команду OK // ответа на 2-ую команду AT [b]!!! Тут происходит коллизия[/b] +CBC: 0,92,4136 // Ответ напряжения АКБ OK // Ответ OK для запроса напряжения АКБ В данном примере коллизию можно обойти т.к. я жду конкретный ответ для обработки +CBC Но вот вариант с вклиниванием передачи данных, например по BT, смещает мой обработчик. Можно дописать ещё различных условий, но не считай, что так работать правильно. AT // Проверка связи и ждём 2 секунды ответа AT // ответа нет, истёк таймаут, посылаю ещё раз OK // ответа на 1-ую команду AT +BTSPPDATA: 1,16,SIMCOMSPPFORAPP // Пришли данные по BT AT+CBC // Запрос напряжения АКБ, т.к. я получил OK на предыдущую команду OK // ответа на 2-ую команду AT [b]!!! Тут происходит коллизия[/b] AT+BTSPPSEND=1,11 // Запрос на передачу по BT, т.к. я получил OK на предыдущую команду +CBC: 0,92,4136 // Ответ напряжения АКБ OK // Ответ OK для запроса напряжения АКБ > SPP APP OK // Передаю по BT, т.к. я получил OK на предыдущую команду SEND OK // Подтверждение передачи 2. Другой вариант - установить таймаут ожидания где-то 60 секунд, на любую команду (независимую от оператора) и если нет ответа, перегружать модуль. Подскажите, кто как делал и какие есть рекомендации от производителя?

Написано, ёмкость возле разъёма Сим карты, а ранее вы написали, что между ножками 18 и 19 (я так понял) удобно ставить ёмкость. Где правда? А то у меня ближе к разъёму одна ёмкость 0.1 мкФ.

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

Я думал 19 и 21 ноги для земли антенны BT модуля. Спасибо. Они у меня в отдельный полигон выведены и BT модуль используется. Буду исправлять. Лучевой разводкой для микросхем и кварцев, практически всегда платы делаю. Не думал, что это Сим карты и модуля касается. Для модуля же есть своя плата и в ней в моём понимании должны быть учтены требования запитки и стока токов. А ещё подвохи описать возможно?

А как его подключать? интересно фото правильных и не правильных включений. Тоже попадал на перезагрузки при использовании МТС карт и исходящем звонке. Баланс карты был низким (какой не помню). Питание смотрел, просадок не было. Логический анализатор показывал диаграмму перезагрузки модуля как в даташите (ножка STATUS опускалась в 0). Модуль SIM800C32. Прошивки B04 и B06 вели себя одинаково. Это было при первых включениях и адаптации кода с SIM9000R на SIM8000С. Потом чудесным образом прошло и пока не повторялось. Уже подумал, может модуль научился. Изменения в коде в основном коснулись только включения/выключения модуля и изменения таймаутов (в несколько раз) ожидания ответа на AT команду. На SIM9000R такой перезагрузки не было.

Да так работает, спасибо. Только теперь переменная определённая с атрибутом адреса исчезла из map файла. И проверить её адрес модно только в отладке.

Так работает в IAR, но не в GCC

Доброе время суток. По воле судьбы приходится сделать проект в AtmelStudio (6 или 7ая версия) (GCC). Кто подскажет, как разместить переменные по фиксированным адресам в ОЗУ? Как сделать регион памяти нашёл, как разместить по фиксированным адресам не нашёл. До этого всё писал в IAR, там это сделать просто.

К таким выводам пришлось прийти самому, потом они подтвердились в процессе переписки с представителем. Потоки данных это хорошо, но их можно предавать и час, и два, и сутки. От этого они не перестанут быть потоками данных. Интересна скорость с которой у Вас работали устройства в сети. Не думаю, что больше 2-5кбит/сек в общей сети.

В исходниках есть стек LwMesh, это легковесная версия построения Mesh сети. ZigBee стек тот, что соответствует спецификации ZigBee, называется BitCloud, никогда в исходниках не был. Да и вряд ли будет. ZigBee подойдёт там где нужно раз в несколько секунд, передать пакетик данных, иначе эта сеть загнётся или будут потери пакетов. Минус ZigBee, что нужен ещё обязательно координатор. LwMesh гораздо лучше в этом плане плане, да и можно подкорректировать при необходимости. Эволюция собственных девайсов была BitCloud -> LwMesh -> Свой стек и драйвер приёмопередатчика.

Есть ещё ZigBee от Atmel. Стек закрыт. Но вроде как работал, т.к. запускал его наверное ещё лет 6 назад. Сеть подымалась, данные передавались. Но на нужную мне задачу скорости не хватало, т.к. есть существенные затраты на поддержку сети и таймауты для передачи данных. Есть у них мене тяжеловесный стек LwMesh. Тоже запускал и тоже работает, но тоже не подошло в чистом виде для задачи. После этого, на базе изученного, был написан свой радиостек (к этому рано или поздно придёте) с поддержкой ретрансляции. Доступ к регистрам приёмопередатчика и их описание, можно взять из разных rf стеков Atmel, кроме ZigBee. Платы все свои. Но можно купить и готовые модули. Поддержка есть русскоязычная и очень быстро отвечает.

Контроль можно и программно сделать. А задержки, это я уже молчу, всех устраивает, все этому явлению могут найти адекватное объяснение (на дворе 2017 год, а тут задержки в секунды, в следующем году, с новой операционкой, до минут дойдут) :smile3046:

Думаю устроит и CMUX, просто поинтересовался, раз тема такая возникла. Вначале ещё в планах к PPP добраться нужно. Ножки проблема, если устройство малогабаритное, но и то есть корпуса QFN, а в основном 2 лишних дорожки не проблема. Нашёл минимум одно ограничение, BT модуль не поддерживает CMUX, для этого случая 2 UART будут предпочтительнее.

Значит для модулей SIM800С использовать 2-ой UART для PPP не получится на текущих версиях ПО.

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

Судя по доке SIM800 Series_Serial Port_Application Note_V1.01 UART1 не полный, а UART2. Для модуля SIM800C наоборот. Значит ли это что в таблице UART1 и UART2 для SIM800C нужно поменять местами?

А как в случае PPP обрабатывать входящие/исходящие звонки и смс?

такие разъёмы есть у Murata - MM8430-2610RA1 ответка Murata дорогая, можно попробовать у китайцев купить (вроде должно подойти) https://ru.aliexpress.com/item/New-SMA-Male...2311.0.0.14tVW9

x893, Стёб то тут причём?

Коллеги, Ваши объяснения хороши, но я не новичок в электронике и программировании. И если честно, то объяснения про многозадачность ОС, её приоритеты, сто тысяч пятьсот модулей для покупки, воспринимаю, как оправдания за кривой драйвер UART или кривой диспетчер задач в ОС, или железо не подходящее по производительности. Т.к. модуль себя ведёт одинаково, что с СИМ картой, что без. А соответственно, если нет сим карты, то какие особые задачи он обслуживает? Другой вариант - это возможно, что общение с UART специально сделали таким, чтобы пользователь не нагружал или перегружал модуль большим количеством команд, а изначально ориентировался и привыкал к такой медленной работе.