Ruslan1

Ну, я по рекомендациям производителя рисовал. Про Reset: это вообще все не монтируется, данный пин отсутствует ("NC") в SIM7080. Upd: Да, 100 nF это мое изобретение, Симком такое не рисовал. Мой косяк.

Блин! Спасибо!! Завтра с утра уберу. P.S: Ну это же не я, оно само подается... :)

RESET вообще не используется, потому что в SIM7080 его нет. Смотрел логическим анализатором: я действительно ничего не подаю на PWRKEY. Про имена пинов CTS и RTS на схеме: в новых документах Симком их переименовал, но направления оставил. Так что тут все норм, работает.

Мне нужно чтобы модем после подачи питания не включался (мешает измерениям). Я его хочу включить позже. То есть мне нужно: 1. подал питание VBAT. Модем не включается и ничего не делает. 2. включаю модем подачей пульса на PWRKEY. Дальше нормальная процедура инициализации и т.д. Сейчас вижу, что после подачи питания модем автоматически включается. Приходится дожидаться конца инициализации (а это до 20 секунд) и потом через команду AT его выключать. Может быть можно как-то проинструктировать модем, чтобы не производить ненужное мне после подачи питания автоподключение к сети??? Отдельного сигнала RESET у SIM7080 нет, так что просто удержать в сбросе даже теоретически не могу (могу только сбросить через длинный сигнал на PWRKEY, но не удержать в ресете). Пока что вижу, что никак не сделать то что я хочу, только VBAT не подавать.

Подсмотрел, как сделано в устройстве c похожим функционалом: там модем подписывается, и тут же ему приходит еще не доставленное сообщение от брокера, он отписывается. Причем соединение было восстановлено с флагом ""clransession=true". QoS=1. Странно, я думал это не так работает. Что брокер не доставит этому clientID ничего за то время, когда клиент явно не подписан на топик. Но если QoS=1 так работает, как я вижу на реальном устройстве, то замечательно. Тогда у меня нет проблемы. Подписываюсь-проверяю-отписываюсь, и ничего не получаю пока опять не подпишусь. И ничего не теряю из топика потому что подключаюсь с тем же clientID. Именно то что мне нужно, но неожиданно. Почитаю еще описание mqtt. Upd: Вот как написано, и это соответствует моим представлениям о подписках (гуглоперевод текста отсюда ) Upd2: вроде понял. Есть флаг "сохраненное сообщение" (retained = true). Именно мой случай, мне всегда нужно получать именно только последнее (самое актуальное) имеющееся в топике сообщение. Да. Накрутили в этом mqtt. Уважаю.

Спасибо, про CMUX я и забыл. Проверил- есть. Значит, если вдруг будут проблемы, знаю куда идти.

Проверил на реальном модеме, вроде получается. Вижу, что это URC сообщение всегда имеет \r\n в начале и \r\n в конце. Уже хорошо. К сожалению, у меня в прошивке (1951B12SIM7080) нет поддержки опции (AT+SMCONF="MESSAGELEN", 1) чтоб выводить и длину сообщения, ну да ладно.

Использую SIM7080. Нужно принимать сообщения от брокера. Что делать- ясно. Подписываюсь на топик и ловлю от модема сообщения, начинающиеся с "+SMSUB:". Но это сообщение полностью асинхронно, и запросто может прийти во время моего общения с модемом с помощью других AT команд. Возникли вопросы: 1) целостность сообщения гарантируется?. То есть не будет ли оно порезано пополам ответом модема на другую команду ("OK", например)? 2) может ли это сообщение влезть между отправкой команды модему и появлением ответа на эту команду? Например, запрос времени с ntp сервера или любое другое действие, требующее от модема внешнего общения, может занять сколько-то секунд. То есть команда-пауза-ответ_модема. В эту паузу может влезть "+SMSUB"?. Или, например, я посылаю свое сообщение, а в это время приходит URC 3) как определять конец сообщения? Насколько я понял, после сообщения "+SMSUB:" модем даже \r\n не вставит? или вставит? В ответе [+SMSUB: <topic>,<message>] эти topic и message всегда в кавычках приходят? А может быть как-то можно по запросу эти сообщения от брокера принимать? Типа дал модему команду, и только после нее он эти сообщения в порт передает, по очереди, или по одному на такой запрос?

Лично для меня самое важное, что есть в Кубе- это его помощь при распределении функций по пинам( Pinout & Configuration). Так как все функции привязаны к конкретным ногам и могут быть перенаправлены на другие только иногда- то такой онлайновый планировщик очень помогает, особенно с учетом жесткой завязки этих интерфейсов и таймеров на определенные каналы DMA под эту функциональность. И при рисовании платы помогает проверить, а возможно ли такие-то функции поменять/перекинуть на другие пины для простоты разводки- дело пары секунд в Кубе. И опция установки частот тактирования (Clock Configuration) - тут все очень внятно, и нарисованно именно под используемый чип, очень удобно. Только за эти функции уже благодарен разработчикам Куба. Много нервов и времени экономит. Кодогенератор Куба: Естественно, пользуюсь (дополнительно к CMSIS) предлагаемыми либами (LL, HAL), но это все просто скопировано в мой проект. Иногда подсматриваю решения в наиболее запущенных случаях: создаю в Кубе проект для работы с непонятной для меня функциональностью, и использую результаты на уровне копирования решений и методов. Но никогда не использовал сгенерированный им код как проект.

Кстати, про системный тик: Практически все пользователи (и я тоже) оставляют этот параметр по умолчанию. Но мало кому дествительно нужно каждую миллисекунду запускать планировщик, это чисто психологический параметр (О! одна миллисекунда! круто!). В реальности эту величину можно и поменять, например увеличить, чтобы меньше ресурсов жралось на пустое переключение задач. Например, в очень шустром ESP32 (тактовая 240 МГц) по умолчанию тик выбран 10 миллисекунд, и это не мешает его езернетам и вайфаям- все делается через прерывания.

Конфликт понятий. Если ситуация "критическая"- то об "удобстве" уже не думают. Тут больше маркетинг и планирование. Нужно считать что дешевле (я подразумеваю не только стоимость деталей, но и репутационные риски и поддержку): 1) вкладывать в каждое устройство френндли-интерфейс для перепрограммирования 2) иметь специальную процедуру и спецоборудование, специально поддерживать именно нуждающегося пользователя в случае ахтунга. Например, присылать ему в аренду оборудование или инструктировать где что купить. Для бытовухи/ширпотреба- однозначно (1). Для индастриала(технически подкованного заказчика)- смесь (1) и (2), зависит от ситуации и исполнения девайса. У меня был проект, когда шли по (2), но довели до (1) : В перечень поставляемого оборудования сразу входил программатор, ну и в юзер гайде на устройство было расписано что и как делать. То есть в результате, для пользователя все сводилось к USB плюс специальный софт на компьютере 🙂

Кстати да, это сложный переход. Я тоже через это прошел, когда после турбо-си и суперлупов начал писать в С++Билдере. Это был шок: вообще никакого "суперлупа", у каждого окошка/кнопочки/компонента свои события и функции их обработки. Очень тяжело было, первые пару дней, но зато потом как понял! 🙂 Но это вечная тема, что-то мы принимаем, а что-то нет или с большим скрипом. Вот мне, например, не дается идеология C++ с объектами/классами. А кто-то проникся и вовсю пользует. "Сотня задач" подразумевает какую-то очень непростую обработку каких-то данных. А эти данные где-то тоже хранить нужно. При таком сложном алгоритме и устройстве, никогда не поверю, что 60 килобайт на служебные нужды будет серьезным вкладом в общее необходимое количество RAM. И если Вы возъметесь организовывать свои сервисы, на это тоже уйдет память, природу не обмануть. Сейчас внутреннюю память микроконтроллеров сотнями килобайт считают, и, как правило, можно еще внешнее что-то подключить.

Какой цикл? при чем здесь цикл? Задача говорит системе: "я буду спать до того как произойдет такое-то событие". Шедулер усыпляет задачу и передает ей снова управление только тогда, когда указанное событие произойдет. Если в этот момент выполняется задача с большим приоритетом- то шедулер подождет, пока это высокоприоритетная задача отдаст управление шедулеру, и наконец-то запустит эту задачу. Никаких циклов и поедания ресурсов в этой ожидающей задаче нет. А если Вам нужно просто задержку организовать- так это опять же через RTOS: задача говорит системе "разбуди меня через столько-то системных тиков", и все. Если ожидание меньше системного тика- то задача взводит аппаратный таймер и из прерывания этого таймера посылается сигнал. А задача говорит системе "разбуди меня, когда пришел сигнал от таймера". И Вы как-то зациклились на расходе ОЗУ. Вам действительно настолько критичны те 64 байта на задачу плюс стек, и разово 236 байт на шедулер, которые нужны, например, freeRTOS? Scheduler Itself: 236 bytes (can easily be reduced by using smaller data types). For each queue you create, add: 76 bytes + queue storage area For each task you create, add: 64 bytes (includes 4 characters for the task name) + the task stack size. Про стек на задачу: это зависит. У меня, например, 128 элементов (128*4 байт), но тут можно и оптимизировать.

Если задача "тупо ожидает в цикле" - то это уже непрофильное применение RTOS. Что-то нужно менять в делении на задачи, например разделить задачу на две. Задача не должна просто ждать, не отдавая управление. Для длинных пауз есть системный сервис (в тиках RTOS), для малых величин- таймер с прерыванием и ожидание семафора от этого таймера в задаче. А если флаги выставлены в порядке "1)включить, 2)выключить", а просканированы в порядке "1)выключить 2)включить", то в результате оно останется включенным? Если сигнал аварии и сигнал включения несинхронны, то запросто такое возможно. И нужно какие-то предыстории и постистории контролировать, хотя бы чтоб не включить там, где должно быть выключено.

Задача№1: принимает решение о включении (на основе данных) и выдает этот сигнал в очередь для задачи №4 Задача№2 (или прерывание): принимает решение о выключении (на основе данных) и выдает этот сигнал в две очереди: для задачи №3 и для №4. Задача№3: ждет (очередь с сигналами от №2) и выключает. больше ничего не делает. Задача№4: ждет (очередь с сигналами от 1 и 2), и принимает решение по заранее обработанному алгоритму. Например, включает если пришел сигнал от №1(включить) и не пришел сигнал от №2(выключить) в течении предыдущих 2 ms и в течении следующих 10 ms. Но вариантов много. Идея в том, чтобы разделить сложное действие на небольшие простые модули(задачи), с входом и выходом, которые просто спят пока нет новой входной информации.

Если оно "ждет", то спит и вообще не занимает ресурс, проснется по событию RTOS (очередь или семафор). Само собой, нужно понимать что от чего зависит и как. Да, я помню, еще в описании uC/OS-II было описание как докатиться до взаимной блокировки, задач, конечно же такое возможно и в FreeRTOS. А что не так? у меня сейчас есть проект такой на ESP32. Общение между задачами происходит через стандартные сервисы FreeRTOS: задача, запущенная на одном ядре, выдает данные в очередь, а задача, запущенная на другом ядре, эту очередь ждет. Работает, проверял логическим анализатором- очень все предсказуемо (задержки и время обработки). Я Espressif фреймворк использую. Там есть в документации кратко, как "ванильный FreeRTOS" у них рапараллелен на два ядра: ESP-IDF FreeRTOS SMP Changes. Вот этого не пробовал. Знаю, что можно RTOS только на одном ядре запустить, а другое врукопашную использовать (то есть без сервисов и шедулера), но я так глубоко не копал.

Да пожалуйста: Задача1: раз в какое-то время запускать опрос датчика Задача2: просыпается по прерыванию, которое посылает сюда сообщение из датчика (принятое, например, по ПДП или побайтово). Обработка и отсылка сообщения в задачу, собирающую данные со всех датчиков для формирования из них нужного пакета (например, передача 20 показаний датчика за раз, или десяти опрошенных датчиков). задача3: работа с внешним интерфейсом (запросы-ответы от линии связи, передача всех запрошенных данных) задача4: работа с внешним интерфейсом (периодические отсылки, например измеренные данные) задача5: локальный интерфейс (лампочки-кнопочки-дисплейчики) задача6: локальный отладочный терминал (обычно UART с системой команд и/или отладочным логом) задача7: опрос набортных сенсоров (ну например напряжение питания и состояние батареи). задача6: вотчдог, контролирующий все задачи: принимает сообщения от всех задач и ребутит систему или отдельные задачи если ему чего-то не нравится. А еще очень помогают приоритеты, чего суперлупом не сделать. Например, когда длинные вычисления делаются в задаче с малым приоритетом в фоне, а подача в нее новых данных (буферизация) идет средствами RTOS (очередь сообщений). Понятно, что природу не обмануть и суммарное время нужно считать (чтобы все вычисления успевались до переполнения очереди), но для особо настырных есть многоядерные камни (начиная с народного ЕСП32)- и задачи запросто могут быть разделены между ядрами. У меня есть проект, где одно ядро ЕСП32 только DSP вычислениями загружено по такой схеме. И что значит "расчехлять"? оно такое страшное? Первый раз, конечно, нужно документацию прочитать, чтобы сконфигурировать ну и вообще понять что это и как. Но даже тут сэкономить можно: просто найти на используемый камень пример в Интернете с морганием светодиодом, и использовать как опору. И читать документацию, смотря на этот пример. Не, так глубоко я не заплывал. К сожалению. Или к счастью, это сейчас спорный вопрос. 🙂

я тут в 2006 зарегился, как раз когда первую свою борду на ARM разрабатывал (AT91RM9200), тогда параллельно как раз и uC/OS-II изучал для него же (был честно купленный микриум под исследовательский грант в НИИ). И то и другое успешно заработало, а я зауважал системы реального времени.

Я тоже из этих. Базы данных с индексированием и поиском на ассемблере на PIC18 писал (с внешней RAM с батарейкой). И перешел на Си наверное лет на 5 позже чем это было уже возможно. То же самое и с RTOS, но тут меня подтолкнули (проект на юкосе подсунули). И обратно на ассемблер и суперлуп не перейду. Это как пересел в машине на атомат после ручки- я ее поюзал лет 20 и в любой момент могу снова потому что умею, но! только в случае сильной нужды и точно не по собственному желанию 🙂

RTOS имеет смысл использовать. Всегда. RTOS позволяет делать систему гибкой и расширяемой. А это экономит главный и невосполнимый ресурс- наше время и наши нервы, и сейчас (во время реализации кода) и в будущем (поддержка и развитие уже имеющегося продукта). Только не нужно рассказывать про ресурсожручесть. Я впервые RTOS на PIC16 с 370 байт RAM пробовал, и уже там это имело смысл. FreeRTOS- замечательный образчик RTOS. И сам на нем уже много лет сижу, и всем советую именно его как базу для нового софта. Бесплатен, популярен, исходники доступны.

Так а нужно-то сколько? просто больше или просто меньше- это не на инженерном языке. Если больше чего то не годится? если меньше чего то подходит? Ну и проверять доли микросекунд пином- так себе тест. Нужно или такты в симуляторе/эмуляторе считать, или таймер аппаратный под эту проверку использовать.

А как без этой программы ESI файлы и hex(bin)-файлы EEPROM к своим устройствам создавать? Можно, конечно, и врукопашную, в текстовом редакторе, но смысла нет никакого. Эта SSC интересная софтинка (еще и си-исходники может), но я ее только для ESI файлов и прошивки EEPROM использую. Области EEPROM и адреса полностью прописаны в документации ECAT. Например, ethercat_esc_datasheet_sec1_technology_2i3.pdf, раздел "11 SII EEPROM"

Однозначно Git. Много лет пользую и пока не разочаровался. Если у конторы есть нужда (абсолютная приватность) и возможности(сервер и администратор) - то на своем сервере Если с этим тяжко- то облачный сервис. Мне исторически гитлаб нравится больше, чем гитхаб.

(У меня не et1100, но думаю это не имеет значения.) Вероятно, не шьет служебную область, которая влияет на общение по ECAT (Vendor ID и прочее, что влияет на выбор ESI файла) ? Попробуйте через EtherCAT Slave Stack Code (SSC), тоже от beckhoff . Там есть EEPROM Programmer внутри. Только через него мне удавалось прошить устройства с еще чистым EEPROM. Соединение должно быть точка-точка, то есть на линии ECAT должно быть только одно еще не сконфигурированное устройство.

Я тут жаловался летом на тормоза с прерываниями в ESP32 и что мне пришлось программный огород городить и делать поллинг коротного сигнала DRDY на отдельном ядре. Оказалось, что даже на отдельном ядре, даже с vTaskSuspendAll() в этой единственной задаче, процессор умудряется периодически отвлекаться/зависать на 5-6 микросекунд (на 240 MHz) и не поллить то, что мне нужно. Уж не знаю, что там он делает- просто все-таки шедулер или функция библиотеки ESP-IDF запущенные на другом ядре, тормозят оба ядра, то ли доступ к какой-то памяти блокирует работу другого ядра, вариантов много. Но факт налицо- я не могу гарантировать непрерывное выполнение единственной задачи на выделенном ядре. Может без RTOS можно, но мне не подходит. Бяка неприятная, и если не знать что искать- то можно долго разбираться. Так что пришлось все-таки городить из короткого DRDY нормальный CS длительностью немного больше времени передачи нужного количества байт, и далее стандартным драйвером SPI Slave обрабатывать принятое. Обошелся формирователем из таймера 555 плюс два транзистора для инверсии входа и выхода как мне нужно. Так как у меня есть запас по времянке (длительность передачи нужных байт примерно 30% от периода транзакций) , то считать клоки для точного формирования CS не нужно, стабильности таймера на RC достаточно. В-общем, вот такой интересный факт при задействовании второго ядра ESP32 и FreeRTOS.