jcxz

....и в начале каждого дня ушлый юзер будет переводить часики на сутки назад. И разорит ТС-а.

А зачем их переводить? Просто хранить счётчик. "Как" - зависит от того - какая энергонезависимая память есть у ТС в приборе. Мы этого не знаем, гадать можно бесконечно. Может у него там дырокол, дырявящий перфокарты? А может терабайтный HDD подключен? Угадаете? Но и то и другое позволяет вести счётчик моточасов.

Тем, что кроме батарейки нужно обеспечить ещё и синхронизацию часов с реальным временем (например SNTP). И предусмотреть действия в случае разрядки/порчи батарейки. И в случае разного рода переводов часов (как на зимнее/летнее время, так и злоумышленные переводы назад). И т.д. Что в сумме намного сложнее учёта моточасов. Хватает для чего? И как вы это посчитали, не зная потребления RTC у ТС-а?

Значит надо посмотреть - какая версия сеггеровских дров стоит дома, и такую же поставить на работе. Потом запустить её JLinkDLLUpdater.exe. Потому что в рабочем другой S/N, ещё не забаненный в новом JlinkARM.dll. А S/N вашего J-Link-а уже забанен. Нет. Перечитайте ещё раз что я писал выше. PS: Если вы ничего не хотите делать для решения проблемы (даже самые простые вещи), то на кой тогда создавали тему с вопросом???

Зачем это окошко здесь? Если это и есть ваша "проблема", то решается она элементарно - заменой JlinkARM.dll на более старый (тот, что у вас стоял раньше). И причина её - в том что поставили более новые дрова Segger-a, а не какая не прошивка. Достаточно поставить те, что стояли раньше (или найти их в папке C:\Program Files (x86)\SEGGER - скорей всего они там у вас и остались). Для этого запустить JLinkDLLUpdater.exe от старых дров и разрешить ему заменить .dll (закрыв предварительно Кейл) Буквально сегодня утром делал такой откат для IAR. Как видно по вашему же скриншоту - вы ничего не шили (так как версия FW - от 2014г), а просто поставили более новый JLink_Windows_Vxxx.exe с новой JlinkARM.dll. В которой забанен S/N вашего J-Link. Этот у вас работает. Ничего покупать не надо. Просто откатите JlinkARM.dll Мой J-Link-Ultra утром выдавал такое же окошко. Сейчас он работает. Ничего не перешивал.

О каком коде речь? Ничего не понятно..... Если речь про пароль, то кто вас заставляет использовать 16-байт? Можно пароль сделать какой угодно длины. А в качестве ключа AES использовать хеш от этого пароля, нужной длины. Так обычно и делают. Только вообще-то TLS (и асимметричное шифрование) - это вообще не про это. Не про длину AES. Если что. Тогда из этого и нужно исходить, придумывая алгоритм учёта времени аренды и генерации кода аренды.

Видимо - мало денех предлагали. Только и всего. PS: Вот вам другой сценарий (очень даже жизненный): Есть некий Производитель девайсов, работающих по ModbusRTU. Предположим это некие счётчики (э/энергии или воды или ещё чего). Допустим есть Заказчик, купивший и установивший на свои объекты кучу этих счётчиков. Счётчики имеют экран, на котором показывают накопленные показания. Но также имеют RS-485 для централизованного запроса данных. Изначально Заказчик (в целях экономии бюджета) решил не делать централизованный съём данных (так как надо прокладывать провода, покупать оборудования для опроса и т.п.). Решил, что ему дешевле нанять бабушек с блокнотиками для периодического обхода. И так работало несколько лет, без нареканий. Но потом обстоятельства меняются - появляются доп.требования по оперативности контроля или просто бабушки начинают бастовать и требовать повышения ЗП. Заказчик вспоминает, что у купленных им счётчиков есть функция опроса через RS-485 по Modbus. И он, Заказчик, даже её оплатил (в расчёте на будущее). Заказчик подсчитывает экономический эффект и решает уволить всех бабушек, а проложить провода и купить оборудования для опроса по ModbusRTU. Далее - находит ваш девайс, который умеет опрашивать по ModbusRTU сторонние девайсы, и заказывает у вас кучу таких девайсов для опроса своих счётчиков. Монтирует на свои объекты. И... вроде можно пить боржоми и курить бамбук. А вам - подсчитывать прибыли. Но вот беда - иногда счётчики по неизвестной причине начинают передавать неверные данные. Очень редко. Непредсказуемо. И без видимых причин. Заказчик вызывает Производителя счётчиков. Делает ему втык. Говорит - "или решай проблему или следующего крупного договоря на N лямов $$$ тебе не видать как своих ушей". Т.е. - мотивирует Производителя материально. А у того эти счётчики уже давно находятся в серийном производстве. И разработчики их уже сокращены или на пенсии. Т.е. - искать проблему в огромной куче быдлокода счётчиков - некому. Да и лень. А договор горит! И Производитель счётчиков *опой чует, что дело в этом самом RS-485 (ведь до этого бабушки несколько лет исправно снимали показания и бед не знали). И возможно он даже знает что проблема в его собственном коде. Только никому не признаётся. И тут этот Производитель счётчиков узнаёт, что Modbus-то ваш - вовсе и не Modbus! Далее он просто пишет простейший код, который кроме нормальных кадров, иногда передаёт и такие разорванные кадры (которые ваш девайс воспринимает как нормальные). Этот тестовый девайс передаёт в нормальных кадрах правильные показания (соответствующие тестовым), а в разорванных - неправильные. Вешает на этот RS-485 сторонний сертифицированный логгер (или даже 2). И показывает этот тестовый стенд Заказчику, убеждая его, что проблема вовсе не в его счётчиках (где она реально и есть), а в ваших девайсах. Ведь сертифицированный логгер видит только кадры с правильными показаниями, а ваш девайс принимает иногда неправильные. Доказывает что ваш девайс видит то, чего нет. Всё - ваш девайс дискредитирован. Договора о поставках с Заказчиком вы лишились. А если бы Modbus у вас был честный, то Производителю счётчиков пришлось бы оторвать пятую точку от стула и найти/исправить баг в своём коде. А не вешать всех собак на вас.

Исходная постановка вопроса неверная. Исходно вы почему-то полагаете, что в среде передачи всё идеально. А там может быть не так. В этой среде передачи (например - RS-485) могут присутствовать устройства, работающие криво. Например - выдающие иногда (очень редко и при определённых условиях) какой-то мусор в канал. Например - обрывки Modbus-кадров. Эти баги разработчики устройств не заметили. Да и фиг с ними. Ведь если в этой среде передачи все приёмники имеют корректные парсеры входящих кадров, то они отбросят такое как мусор. Теперь в этот RS-485 втыкают ваше устройство. И оно начинает иногда глючить. Ведь воспринимает тот мусор как корректные кадры. Дальше начинается разборка - кто виноват? Кому выписывать пи^&*лей? В этот RS-485 втыкают некий сторонний логгер ModbusRTU кадров, пишущий все кадры в течение нескольких суток непрерывно. Логгер - серьёзный, сертифицирован как "ModbusRTU-compliancy". Потом лог просматривают и... не обнаруживают в нём кадров, адресованных вашему устройству. В то время как ваш девайс действовал, как будто видел такие кадры (так как клеил их из какого-то мусора). Делается вывод о несоответствии вашего девайса ModbusRTU. Занавес. А ведь ваши манагеры уже заключили договор на продажу этому заказчику 1 миллиона штук ваших девайсов. Под это дело вы уже закупили вагон комплектации (в кредит). Но договор расторгается. Так как ваши девайсы "не соответствуют спецификации Modbus-RTU". А ваша контора влетает на бабки. Так никто же не против того, чтобы вы реализовали частное решение для данного частного случая, назвав это своим "vendor specific" протоколом. Почему так не сделать??? Но вы же называете его "ModbusRTU", которое им по факту не является. Назовите его своим проприетарным протоколом, в какой-то мере похожем на ModbusRTU. Никто и слова не скажет. Но вы же вместо этого зовёте его ModbusRTU, вводя всех в заблуждение. Намеренно или по глупости.

Этот вам так кажется. Пока не пришёл умный человек, знающий что такое Modbus, и не завалил ваш девайс, посылкой ему корректных Modbus-кадров, которые ваш девайс не в состоянии правильно распознать. Или отправкой мусора, который ваш девайс распознает как корректные кадры. И при желании такой человек всегда найдётся. Всё зависит от суммы гонорара. Скажем придёт ко мне завтра заказчик, принесёт ваш прибор, и скажет: "Вот тебе 10тыс.евро, напиши такой код на любом устройстве, который будет посылать кадры, корректные с точки зрения Modbus-протокола, но которые этот прибор будет неверно распознавать". И я напишу. Зная баги вашей реализации - запросто. И где же ваш девайс "правильно распознаёт кадры", если сами же выше писали, что распознаёт неправильно: Т.е. - по стандарту вы должны отбросить такое как мусор. Вы же воспринимаете это как корректный кадр. Вот сюда тот умный человек и вдарит ваш девайс. Превратив его в тыкву. Со всеми вытекающими. В TCP нет фреймов. Советую почитать учебник "что такое TCP". TCP-это потоковый протокол (поток байт). Если кто-то пишет работы с TCP с опорой на некие "фреймы", то это уже изначально некорретная реализация. И чья-то кривая реализация - это не оправдание другим делать так же.

Интересно - а зачем шили? Для чего?

Что можно обсуждать "созидательно" для сферического коня в вакууме? Вы даже не описали: 1. Примерный функционал прибора? 2. Доступ к какой функции требуется предоставлять с помощью данного сервиса? Ко времени работы прибора? Ко времени работы какого-то режима (мотора) прибора? Или к чему? 3. Как именно прибор осуществляет учёт расхода времени аренды? По часам реального времени? Путём периодического декремента некоего счётчика секунд/минут в памяти? или ...? 4. Если учёт по счётчику, то зачем тогда пишете о некоей дате? Если по часам реального времени - то как именно синхронизируются часы в приборе с реальным временем? Как будет достигаться соответствие времени в приборе со временем, по которому сгенерирована аренда внешним сервисом? И что мешает пользователю не продлять никакую аренду, а просто перевести часы прибора назад? Или что будет, если батарейка на часах прибора сядет, при ещё не истекшем сроке аренды? 5. Имеет ли прибор подключение к интернет? Если имеет (и часы реального времени синхронизируются через этот же канал), то что мешает и продление аренды сделать прям на приборе, без всяких сторонних вебов? PS: И да - прежде чем придумывать свой велосипед с деревянными колёсами, нужно хотя бы изучить имеющиеся (TLS например). И по возможности использовать их.

Лучше не барьеры, а операции обратного чтения после каждой записи в регистры конфигурации таймера. Т.е. - после записи каждого регистра таймера - сделать чтение из него. Впрочем - выше я уже предлагал это, но не знаю - делалось ли это или нет? На XMC4xxx во многих случаях, необходимо такое обратное чтение после записи в какой-либо регистр периферии, если сразу после этого идёт другая запись, в другой регистр, зависящая от эффекта предыдущей записи. Например: запись значения X1 в регистр конфигурации периферии R1, а потом - следующая запись (в регистр R2), включающая эту периферию, режим включения которой зависит от записи X1. Если между записью R1 и R2 не вставить чтение R1, то может работать некорректно. Инструкции барьеров в этом случае не помогают. Только обратное чтение. На STM32F429 тоже сталкивался с таким в какой-то периферии (при работе на макс. частоте). В документации XMC4xxx упоминается необходимость таких обратных чтений между зависимыми записями в регистры конфигурации. В коде операция: LPTIM1->DIER = ... не факт что успевает выполниться до последующего разрешения таймера. Обратное чтение LPTIM1->DIER после записи, до разрешения таймера, должно дать гарантию.

А сами значения в регистрах таймера (после инита) проверили? Сравнили с мануальными? А то кто его знает - не накосячено ли с определениями всех этих множества define-ов, там где вы их взяли?

Можно попробовать: При запрещённых всех прочих источниках прерываний сделать полную очистку всех pending (все ICPRx = ~0) (до инита таймера); потом запустить таймер и посмотреть - может где-то запрос появляется в другом регистре/бите? По идее - PRIMASK не должен никак влиять на появление флагов-запросов в NVIC.

Может зря вы так? Может они хотят: Собрать заинтересованный народ вместе; услышать от них об их "хотелках"; представить свой продукт; рассказать о его преимуществах; провести обучение; после которого - раздарить всем желающим отладочные платы на этом МК (бесплатно), может даже со средствами отладки; провести конкурсы, на которых разыграть дополнительные отладочные платы, наборы компонентов и средства отладки; накормить/напоить всех собравшихся на бесплатном фуршете (может и не одном); дать пообщаться между собой оффлайн собравшимся заинтересованным людям... ? Ну т.е. - действовать цивилизованно, как действовали ранее представители западных производителей МК. Помнится на одном из таких мероприятий, организаторы на фуршете даже выносили нам зажаренного кабанчика на вертеле , которого потом все вместе дегустировали под хорошие напитки. А потом ещё были танцы. С представителями/представительницами организатора мероприятия. Не помню даже уже - какие МК представляли, но само мероприятие отлично помню! PS: А на вашем форуме кабанчика под хорошее винишко в приятной компании не откушаешь. Зато полно всяких не совсем адекватных личностей и школоты...

Элементарно: Девайс ретранслирует траффик некоего канала связи (Modbus). Не разбирая его. В кадрах своего протокола обмена. Делали такие устройства (ретранслирующие прозрачно чужой траффик). Для вас это будет выглядеть как Modbus-кадры в обрамлении некоего "мусора". Или куски таких кадров. Нет, это называется "кривая реализация". Изначально Modbus-RTU - кодонезависимый протокол. Вы же сделали некое поделие, не обладающее кодонезависимостью. Т.е. - что-то сделали, но явно не Modbus-RTU. Ну да. "Работает". До тех пор, пока не найдётся заинтересованного лица, заинтересованного доказать, что ваш девайс не работает (не соответствует спецификации). Далее - эта морда лицо приобретает ваш девайс, и строит элементарный тест. На котором ваш девайс неверно распознаёт кадры. И выкладывает результаты теста в общий доступ. Это обычное дело когда существует конкуренция. Конкуренты так и делают. Если вы не сталкивались с такой практикой, это не значит, что её нет. PS: Есть и другие сценарии, когда с такой костыльной "реализацией" запросто сядете в лужу. Просто подумайте немного... Вам просто повезло наступить мимо граблей. Но завтра может уже не повезти.

Да. Это иногда недостаток наверное. Но также - не встречал в практике прям насущной необходимости в равноприоритетных задачах. Зато очень быстрое и простое управление задачами.

Приоритеты не занятые задачами имеете в виду? Разве имеет большое значение - сколько их? Не знаю как там устроено во FreeRTOS, но у меня, в моей ОС очередь приоритетов = это одно 32-битное значение. С битиками установленными в лог.1 в позициях задач, готовых выполняться. Соответственно - выбор шедулером задачи на выполнение - одна команда CLZ. Скорость выполнения которой всегда одинакова. Конечно - если надо больше задач, то надо будет несколько 32-битных слов. Но рост затрат времени шедулера с ростом числа приоритетов - будет довольно медленный (через каждые 32 приоритета). И я ограничил число задач в своей ОС <= 31 задача(или приоритет) (32-я задача - системная idle-задача). Исходя из моего многолетнего опыта с МК - этого вполне достаточно. Ни разу не встречалось программ, требующих более 31-го приоритета задач.

А если придёт такой кадр, содержимое внутри которого будет похоже на другой Modbus-кадр? Этот вариант называется "кривой костыль". Видимо там поработали такие-же костыле-строители.

Количество реально работающих задач может быть намного меньше максимально разрешённого количества приоритетов задач в OS. И не то (количество реально работающих задач) ни другое (количество приоритетов задач) не имеют никакого отношения к частоте вызова каких-либо задач или сервисов ОС. Пусть будет хоть 200 приоритетов - это не причина срабатывания "раз в 10 минут".

Видимо нужно угадать задание. Как обычно... Попробуйте попытать удачи здесь: https://www.taro.lv/forum/ PS: Странно - может гугл выдаёт наш форум в ответ на запрос: "форум прорицателей и гадалок"? как-то слишком часто люди ошибаются адресом...

Это как решит программист. Флаг работает не сам по себе, а по алгоритму, реализуемому программистом. Сколько задач/читают и пишут в этот флаг и как они это делают - всё в руках погромиста. Стоит сперва включать голову. Чтобы придумать общий алгоритм работы программы. А флажки, задачи, критические секции и т.п. - это компоненты программы. Которыми она может жонглировать как угодно - как решит её создатель. Бездумно всегда включать критическую секцию, не понимая для чего и почему - плохая идея. Это видимо вы читали что-то для 8-битных систем. Для которых операция записи переменных >1 байта - неатомарна. Для ARM например все операции записи 8-, 16-, и 32-битных переменных - как правило атомарны (если не предпринимать спец.действий для их неатомарности). Но зачем вам флажок разрядностью более минимально возможного записываемого элемента в архитектуре? PS: Вот решили вы с друзьями построить дом. Вы пойдёте всей толпой и каждый возьмёт произвольный инструмент (кто - молоток, кто - пилу, кто - дрель) и начнёт сам по себе долбать этими молотками и т.п. не согласуясь с остальными? Или сперва обсудите - кто что будет делать? в каком порядке? какие инструменты использовать и для чего? Вот программа - это оно и есть = порядок действий и какими инструментами их выполнять. А молоток, пила, дрель - это ваши флажки, критические секции, мьютексы, ... с помощью которых вы решаете задачу постройки дома. Можно и нескольким человекам в команде одной дрелью пользоваться. Если согласовать порядок пользования. А можно и все свёрла переломать. Программа начинается не с набивания строк типа char volatile ..., а с придумывания алгоритма работы, реализующего требуемый функционал.

О каких коллизиях речь? Вот одна задача выполняет запись во флажок: flag = 1; другая - чтение флажка: if (flag) .... char volatile flag; Что вас тут смущает? И в чём тут неатомарность?

"как минимум" - не надо. Можно без критических секций обойтись. Критическая секция - это уже тяжёлое решение. При решении практической задачи синхронизации, разумно начинать с простых решений. PS: Хоть бы почитали всю тему что-ль? Чтобы на новый круг не заходить...

И мы уже знаем в какой группе находится наш Modbus-строитель: