![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
Ruslan1
Свой-
Постов
3 015 -
Зарегистрирован
-
Посещение
-
Победитель дней
3
Весь контент 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 миллисекунд, и это не мешает его езернетам и вайфаям- все делается через прерывания.
-
Интерфейсы для обновлений
Ruslan1 ответил unix тема в В помощь начинающему
Конфликт понятий. Если ситуация "критическая"- то об "удобстве" уже не думают. Тут больше маркетинг и планирование. Нужно считать что дешевле (я подразумеваю не только стоимость деталей, но и репутационные риски и поддержку): 1) вкладывать в каждое устройство френндли-интерфейс для перепрограммирования 2) иметь специальную процедуру и спецоборудование, специально поддерживать именно нуждающегося пользователя в случае ахтунга. Например, присылать ему в аренду оборудование или инструктировать где что купить. Для бытовухи/ширпотреба- однозначно (1). Для индастриала(технически подкованного заказчика)- смесь (1) и (2), зависит от ситуации и исполнения девайса. У меня был проект, когда шли по (2), но довели до (1) : В перечень поставляемого оборудования сразу входил программатор, ну и в юзер гайде на устройство было расписано что и как делать. То есть в результате, для пользователя все сводилось к USB плюс специальный софт на компьютере 🙂 -
FreeRTOS и другие, имеет ли смысл использовать?
Ruslan1 ответил unix тема в ARM, 32bit
Кстати да, это сложный переход. Я тоже через это прошел, когда после турбо-си и суперлупов начал писать в С++Билдере. Это был шок: вообще никакого "суперлупа", у каждого окошка/кнопочки/компонента свои события и функции их обработки. Очень тяжело было, первые пару дней, но зато потом как понял! 🙂 Но это вечная тема, что-то мы принимаем, а что-то нет или с большим скрипом. Вот мне, например, не дается идеология C++ с объектами/классами. А кто-то проникся и вовсю пользует. "Сотня задач" подразумевает какую-то очень непростую обработку каких-то данных. А эти данные где-то тоже хранить нужно. При таком сложном алгоритме и устройстве, никогда не поверю, что 60 килобайт на служебные нужды будет серьезным вкладом в общее необходимое количество RAM. И если Вы возъметесь организовывать свои сервисы, на это тоже уйдет память, природу не обмануть. Сейчас внутреннюю память микроконтроллеров сотнями килобайт считают, и, как правило, можно еще внешнее что-то подключить. -
FreeRTOS и другие, имеет ли смысл использовать?
Ruslan1 ответил unix тема в ARM, 32bit
Какой цикл? при чем здесь цикл? Задача говорит системе: "я буду спать до того как произойдет такое-то событие". Шедулер усыпляет задачу и передает ей снова управление только тогда, когда указанное событие произойдет. Если в этот момент выполняется задача с большим приоритетом- то шедулер подождет, пока это высокоприоритетная задача отдаст управление шедулеру, и наконец-то запустит эту задачу. Никаких циклов и поедания ресурсов в этой ожидающей задаче нет. А если Вам нужно просто задержку организовать- так это опять же через 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 байт), но тут можно и оптимизировать. -
FreeRTOS и другие, имеет ли смысл использовать?
Ruslan1 ответил unix тема в ARM, 32bit
Если задача "тупо ожидает в цикле" - то это уже непрофильное применение RTOS. Что-то нужно менять в делении на задачи, например разделить задачу на две. Задача не должна просто ждать, не отдавая управление. Для длинных пауз есть системный сервис (в тиках RTOS), для малых величин- таймер с прерыванием и ожидание семафора от этого таймера в задаче. А если флаги выставлены в порядке "1)включить, 2)выключить", а просканированы в порядке "1)выключить 2)включить", то в результате оно останется включенным? Если сигнал аварии и сигнал включения несинхронны, то запросто такое возможно. И нужно какие-то предыстории и постистории контролировать, хотя бы чтоб не включить там, где должно быть выключено. -
FreeRTOS и другие, имеет ли смысл использовать?
Ruslan1 ответил unix тема в ARM, 32bit
Задача№1: принимает решение о включении (на основе данных) и выдает этот сигнал в очередь для задачи №4 Задача№2 (или прерывание): принимает решение о выключении (на основе данных) и выдает этот сигнал в две очереди: для задачи №3 и для №4. Задача№3: ждет (очередь с сигналами от №2) и выключает. больше ничего не делает. Задача№4: ждет (очередь с сигналами от 1 и 2), и принимает решение по заранее обработанному алгоритму. Например, включает если пришел сигнал от №1(включить) и не пришел сигнал от №2(выключить) в течении предыдущих 2 ms и в течении следующих 10 ms. Но вариантов много. Идея в том, чтобы разделить сложное действие на небольшие простые модули(задачи), с входом и выходом, которые просто спят пока нет новой входной информации. -
FreeRTOS и другие, имеет ли смысл использовать?
Ruslan1 ответил unix тема в ARM, 32bit
Если оно "ждет", то спит и вообще не занимает ресурс, проснется по событию RTOS (очередь или семафор). Само собой, нужно понимать что от чего зависит и как. Да, я помню, еще в описании uC/OS-II было описание как докатиться до взаимной блокировки, задач, конечно же такое возможно и в FreeRTOS. А что не так? у меня сейчас есть проект такой на ESP32. Общение между задачами происходит через стандартные сервисы FreeRTOS: задача, запущенная на одном ядре, выдает данные в очередь, а задача, запущенная на другом ядре, эту очередь ждет. Работает, проверял логическим анализатором- очень все предсказуемо (задержки и время обработки). Я Espressif фреймворк использую. Там есть в документации кратко, как "ванильный FreeRTOS" у них рапараллелен на два ядра: ESP-IDF FreeRTOS SMP Changes. Вот этого не пробовал. Знаю, что можно RTOS только на одном ядре запустить, а другое врукопашную использовать (то есть без сервисов и шедулера), но я так глубоко не копал. -
FreeRTOS и другие, имеет ли смысл использовать?
Ruslan1 ответил unix тема в ARM, 32bit
Да пожалуйста: Задача1: раз в какое-то время запускать опрос датчика Задача2: просыпается по прерыванию, которое посылает сюда сообщение из датчика (принятое, например, по ПДП или побайтово). Обработка и отсылка сообщения в задачу, собирающую данные со всех датчиков для формирования из них нужного пакета (например, передача 20 показаний датчика за раз, или десяти опрошенных датчиков). задача3: работа с внешним интерфейсом (запросы-ответы от линии связи, передача всех запрошенных данных) задача4: работа с внешним интерфейсом (периодические отсылки, например измеренные данные) задача5: локальный интерфейс (лампочки-кнопочки-дисплейчики) задача6: локальный отладочный терминал (обычно UART с системой команд и/или отладочным логом) задача7: опрос набортных сенсоров (ну например напряжение питания и состояние батареи). задача6: вотчдог, контролирующий все задачи: принимает сообщения от всех задач и ребутит систему или отдельные задачи если ему чего-то не нравится. А еще очень помогают приоритеты, чего суперлупом не сделать. Например, когда длинные вычисления делаются в задаче с малым приоритетом в фоне, а подача в нее новых данных (буферизация) идет средствами RTOS (очередь сообщений). Понятно, что природу не обмануть и суммарное время нужно считать (чтобы все вычисления успевались до переполнения очереди), но для особо настырных есть многоядерные камни (начиная с народного ЕСП32)- и задачи запросто могут быть разделены между ядрами. У меня есть проект, где одно ядро ЕСП32 только DSP вычислениями загружено по такой схеме. И что значит "расчехлять"? оно такое страшное? Первый раз, конечно, нужно документацию прочитать, чтобы сконфигурировать ну и вообще понять что это и как. Но даже тут сэкономить можно: просто найти на используемый камень пример в Интернете с морганием светодиодом, и использовать как опору. И читать документацию, смотря на этот пример. Не, так глубоко я не заплывал. К сожалению. Или к счастью, это сейчас спорный вопрос. 🙂 -
FreeRTOS и другие, имеет ли смысл использовать?
Ruslan1 ответил unix тема в ARM, 32bit
я тут в 2006 зарегился, как раз когда первую свою борду на ARM разрабатывал (AT91RM9200), тогда параллельно как раз и uC/OS-II изучал для него же (был честно купленный микриум под исследовательский грант в НИИ). И то и другое успешно заработало, а я зауважал системы реального времени. -
FreeRTOS и другие, имеет ли смысл использовать?
Ruslan1 ответил unix тема в ARM, 32bit
Я тоже из этих. Базы данных с индексированием и поиском на ассемблере на PIC18 писал (с внешней RAM с батарейкой). И перешел на Си наверное лет на 5 позже чем это было уже возможно. То же самое и с RTOS, но тут меня подтолкнули (проект на юкосе подсунули). И обратно на ассемблер и суперлуп не перейду. Это как пересел в машине на атомат после ручки- я ее поюзал лет 20 и в любой момент могу снова потому что умею, но! только в случае сильной нужды и точно не по собственному желанию 🙂 -
FreeRTOS и другие, имеет ли смысл использовать?
Ruslan1 ответил unix тема в ARM, 32bit
RTOS имеет смысл использовать. Всегда. RTOS позволяет делать систему гибкой и расширяемой. А это экономит главный и невосполнимый ресурс- наше время и наши нервы, и сейчас (во время реализации кода) и в будущем (поддержка и развитие уже имеющегося продукта). Только не нужно рассказывать про ресурсожручесть. Я впервые RTOS на PIC16 с 370 байт RAM пробовал, и уже там это имело смысл. FreeRTOS- замечательный образчик RTOS. И сам на нем уже много лет сижу, и всем советую именно его как базу для нового софта. Бесплатен, популярен, исходники доступны. -
Так а нужно-то сколько? просто больше или просто меньше- это не на инженерном языке. Если больше чего то не годится? если меньше чего то подходит? Ну и проверять доли микросекунд пином- так себе тест. Нужно или такты в симуляторе/эмуляторе считать, или таймер аппаратный под эту проверку использовать.
-
Расскажите про EtherCAT
Ruslan1 ответил jagdhund тема в Интерфейсы
А как без этой программы ESI файлы и hex(bin)-файлы EEPROM к своим устройствам создавать? Можно, конечно, и врукопашную, в текстовом редакторе, но смысла нет никакого. Эта SSC интересная софтинка (еще и си-исходники может), но я ее только для ESI файлов и прошивки EEPROM использую. Области EEPROM и адреса полностью прописаны в документации ECAT. Например, ethercat_esc_datasheet_sec1_technology_2i3.pdf, раздел "11 SII EEPROM" -
Однозначно Git. Много лет пользую и пока не разочаровался. Если у конторы есть нужда (абсолютная приватность) и возможности(сервер и администратор) - то на своем сервере Если с этим тяжко- то облачный сервис. Мне исторически гитлаб нравится больше, чем гитхаб.
-
Расскажите про EtherCAT
Ruslan1 ответил jagdhund тема в Интерфейсы
(У меня не et1100, но думаю это не имеет значения.) Вероятно, не шьет служебную область, которая влияет на общение по ECAT (Vendor ID и прочее, что влияет на выбор ESI файла) ? Попробуйте через EtherCAT Slave Stack Code (SSC), тоже от beckhoff . Там есть EEPROM Programmer внутри. Только через него мне удавалось прошить устройства с еще чистым EEPROM. Соединение должно быть точка-точка, то есть на линии ECAT должно быть только одно еще не сконфигурированное устройство. -
Выбор способа написать программу.
Ruslan1 ответил xinortcele тема в В помощь начинающему
Я тут жаловался летом на тормоза с прерываниями в ESP32 и что мне пришлось программный огород городить и делать поллинг коротного сигнала DRDY на отдельном ядре. Оказалось, что даже на отдельном ядре, даже с vTaskSuspendAll() в этой единственной задаче, процессор умудряется периодически отвлекаться/зависать на 5-6 микросекунд (на 240 MHz) и не поллить то, что мне нужно. Уж не знаю, что там он делает- просто все-таки шедулер или функция библиотеки ESP-IDF запущенные на другом ядре, тормозят оба ядра, то ли доступ к какой-то памяти блокирует работу другого ядра, вариантов много. Но факт налицо- я не могу гарантировать непрерывное выполнение единственной задачи на выделенном ядре. Может без RTOS можно, но мне не подходит. Бяка неприятная, и если не знать что искать- то можно долго разбираться. Так что пришлось все-таки городить из короткого DRDY нормальный CS длительностью немного больше времени передачи нужного количества байт, и далее стандартным драйвером SPI Slave обрабатывать принятое. Обошелся формирователем из таймера 555 плюс два транзистора для инверсии входа и выхода как мне нужно. Так как у меня есть запас по времянке (длительность передачи нужных байт примерно 30% от периода транзакций) , то считать клоки для точного формирования CS не нужно, стабильности таймера на RC достаточно. В-общем, вот такой интересный факт при задействовании второго ядра ESP32 и FreeRTOS.