jcxz

Конечно, лучше такой и использовать. Я там указал.

Видимо у автора совета какая-то личная симпатия к осциллографам Напряжение конечно же лучше измерять вольтметром. Делать это нужно на шунте, включённом последовательно с источником 3V (и не важно в минусовом или плюсовом проводе - ток в последовательной цепи везде одинаков). При измерении питать лучше как тут уже советовали - от стабилизированного источника, напряжение которого такое, что после вычета падения на шунте на нагрузке будет 3V. Хотя можно и не заморачиваться с этим если шунт достаточно низкоомный. Но как тут советовали брать шунт 5 Ом я бы не стал - при токе 90мкА падение будет <0.5мВ - имхо показания будут сильно зависеть от наведённых шумов. Лучше взять хотя бы несколько сотен Ом, а лучше - несколько кОм (SMD резистором). Имхо. Т.е. - собрали цепь: регулируемый источник напряжения источник (3...5V) - шунт - нагрузка. Параллельно нагрузке - вольтметр, параллельно шунту - второй вольтметр. Сначала по первому вольтметру выставляете напряжение на нагрузке == 3V (регулируя источник). Потом измеряете ток по второму вольтметру. Второй вольтметр - точный, первый - любой.

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

Для автора ADUCM361 за <1500р - "дорого". А Вы про внешние АЦП....

Я так понял - Вы хотите какой-то девайс сделать для себя и чисто на отладке. Тогда какая разница сколько стоит сам МК и сколько стоит IAR? А если для конторы, и для дальнейшего серийного производства, то какая разница сколько стоит отладка и сколько стоит J-Link? Если для конторы 108 евро являются проблемой, то и разрабатывать для такой конторы не стоит: https://ru.farnell.com/analog-devices/eval-aducm360qspz/aducm360qspz-evaluation-module/dp/2378630?st=ADUCM361 В комплекте с отладкой (моей по-крайней мере как на ссылке выше) шёл и эмулятор. А если не хочется им, то можно J-Link использовать.

Отладки часто можно получить на халяву.

ADuCM360 - тоже простой, с простой периферией. И АЦП куда более "high-precision": 24 бита. Да к тому же их там два независимых, аппаратных. Только отладку с ним не отдам - сам всё подумываю какой-нить "аналоговый регистратор" на ней замутить.

Имхо танцевать нужно не от формы хранения, а от функционального назначения. Не регистры и их поля редактировать, а функции устройства, разбитые на группы по функциональным блокам устройства. Тогда это будет конфигурирование ориентированное на пользователя устройства, а не на разработчика протокола обмена с этой ИМС.

А что там такого уникального в этих МК с точки зрения АЦП? Вроде как всё заурядно, MSP430FR2355: One 12-Channel 12-Bit Analog-to-Digital Converter (ADC) – Internal Shared Reference (1.5, 2.0, or 2.5 V) – Sample-and-Hold 200 ksps Такое есть почти в каждом современном МК. И даже лучше.

Вы мои посты вообще читаете? Тогда если ПО одно, то на него можно потратить N*Y ч/часов и получить более надёжное ПО. Просто распилив например на более мелкие части. Меняется и очень сильно. Потому что когда ПО одно общее, хоть и делается по частям, командой, любому члену этой команды, проще разобраться в чужой части (а это делать придётся в таких ситуациях), чем ковыряться в другом ПО, другой архитектуре, да ещё и другом инструментарии разработки/отладки. Когда такое случится и к вам придёт начальник и скажет "Давай-ка садись, разберись как у твоих соседей построен проект и найди у них баг". Вот тогда и станет вашей. Ну или ваша телега, запряжённая раком, лебедем и щукой, никуда не уедет. PS: "Это уже точно не моя забота." - да уж, странная у вас там обстановка. Если разработчиков не волнует будет ли работать устройство или нет..... PPS: И ещё один весёлый пункт в таком Змее Горыныче: Когда (вдруг) уволится разработчик ПО для одной из его голов, то оставшемуся бедолаге представится весёлая возможность изучать и разгребать оставленное ушедшим коллегой "наследство", вникая во все тонкости архитектуры и инструментария. И уволится он в самый такой неудобный момент, когда известно что где-то есть плавающий баг, но неизвестно где

Я же указал основание. Посмотрите мои два пункта из сообщения выше. Про бюджет времени == N ч/часов. Если на одно ПО потрачено N ч/часов, а на другое N/3 ч/часов (при том что сложность ПО примерно одинакова; хотя это неверно - во втором случае ПО будет много сложнее и соответственно ситуация будет ещё хуже), то какое ПО будет надёжнее? Или Вы не согласны с этим? Но автор данного треда ведь Вы? Вот когда начнёте делать, тогда и поймёте. Про одно из "плохого" я уже сказал многократно: на это ваше каждое ПО бюджет времени на отладку/разработку будет меньше. Про второе Вы сами только что сказали, только почему-то сами и не поняли: раз каждое ПО ещё и как-то "следит" за другим - это дополнительный функционал, и приличный по размеру. А чем ПО сложнее, тем вероятность багов в нём больше. Или Вы и с этим не согласны? А самое веселье начнётся когда начнёте отлаживать этого многоголового Змея Горыныча. И когда ваш девайс будет периодически изредка глючить на объекте по непонятным причинам, а оба "независимых" разработчика станут дружно показывать пальцем друг на дружку "У меня всё работает, это в его части сбои". И так будет со 100%-ной вероятностью. Даже когда ПО одно единое, но делается командой, то и в этом случае возникают такие ситуации (не раз сам с таким сталкивался), когда каждый говорит что "у меня всё работает". Так что вам к двум "независимым" разработчикам придётся нанимать ещё и "независимого" третейского судью для разруливания таких ситуаций. Вот тогда и вспомните "что плохого"..... PS: Главная мысля, которую я хотел донести: Надёжность ПО (и устройства) зависит прямопропорционально от количества времени потраченного на него, и обратнопропорционально - от размера и сложности ПО. Вы же хотите уменьшить это время, усложнить ПО и при этом почему-то получить бОльшую надёжность. Вот это и странно...

Затем, что такой макрос может быть использован несколько раз в одной и той же области видимости.

Мне текст не нужен. Я по выражению всё вижу. Главное чтоб компиляция не выполнялась при ложном условии. А если нужен текст его можно в комментарии написать.

То и дают - проверку условий на этапе build-time. И я не использую никакие C99 и иже с ними. И вообще - те мои макросы Вы выдрали из сообщения предназначенного для приведённого мной примера кода конфигурирования MPU. Вот и попробуйте этот пример скомпилить без них.

Во-во! А ещё ТС не понимает, что бюджет времени на разработку - он всегда ограничен. И если скажем на работу выделено N программисто-часов можно: Или потратить все N на разработку одного ПО. Получив надёжность этого ПО прямо пропорциональную потраченному времени, скажем: k*N. Или потратить 0.33*N времени на разработку одного ПО + 0.33*N времени на разработку второго ПО + 0.33*N на согласование действий двух (групп?) программистов. Получив результирующую надёжность всей системы ПО: MIN(k1*0.33*N, MIN(k2*0.33*N, k3*0.33*N)). Где коэффициенты k1/k2/k3 будут зависеть от профессионализма разных разработчиков. Но общую надёжность системы в любом случае определит самая ненадёжная её часть. Вы почему-то решили что баги в двух разных ПО будут объединяться по принципу ЛОГИЧЕСКОГО И. С чего бы это? Я вот считаю что они будут объединяться по принципу ЛОГИЧЕСКОГО ИЛИ.

Если вам они не нужны, зачем тогда используете? Кто-то стоит над вами с палкой и заставляет? "Мыши кололись, плакали, но продолжали жрать кактус". Или в чём вопрос? я не понимаю....

Где-то валялись 2шт. MSP-EXP430FR5739. Одна даже не юзанная. А вы где сами находитесь?

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

Дублирование, когда имеются в виду два идентичных аппаратных блока с одинаковым ПО, конечно же даст увеличение надёжности. За счёт выявления аппаратных сбоев. О программных багах тут речи нет. Кроме рекомендованных вам выше МК, можете посмотреть также на TriCore: https://www.infineon.com/cms/en/product/microcontroller/32-bit-tricore-microcontroller/ Сам не использовал, но насколько понял из мануала, они имеют два аппаратных ядра, выполняющих параллельно один и тот же код, и сравнивающих результаты работы друг с другом. Почти то что Вы хотели, но на одной архитектуре, с одним кодом. Не знаю что и как там ставят (я не являюсь специалистом в этой области, а мнению безграмотных писак из СМИ и прочих "диванных спецов" - не доверяю), но вроде как в самолёте все окончательные решения принимает пилот. В том числе и какую систему отключить, а какой и далее доверять (если там возникли какие-то конфликты) - тоже решает пилот. А Вы собрались такое решение возложить на некую дешёвую 8-битную систему. В этом случае у вас просто надёжность работы будет определяться как раз её надёжностью. Ну или минимальной из надёжностей обеих систем. И Боинг, на который Вы ссылаетесь, имеет всё-таки я думаю несколько иной бюджет на свои разработки. А значит - может вести такие работы на соответствующем уровне. Пытаться впихнуть такое в обычный инвертор для э/двигателя - это значит вместо решения насущных задач, тратить время на какую-то ерунду. И в результате получить заведомо худший результат по сравнению с тем, чтобы всё это время с пользой потратить на основное ПО, его более глубокую отладку. Если у вас есть лишний программист и вам его нечем занять, то лучше посадите его за ревью кода основного программиста. Для такой системы это (имхо) даст лучший результат. PS: Или Вы свой самолёт разрабатываете?

Зависит от алгоритма. Если условные переходы в пределах кеша (те условные, направление выполнения которых зависит от измеряемых данных; т.е. например переходы циклов - не в счёт), то они будут без кеш-промахов. Условные переходы, зависимые от данных да ещё дальние - не в каждом алгоритме обработки данных такие встретишь, тем более ТС вроде говорит о сигнальной обработке.

Вангую: через некоторое время Вы создадите тему "порекомендуйте МК, который будет контролировать второй МК, который контролирует третий МК".

Вот именно. И увеличение числа архитектур в проекте просто сделает её вероятность равной: (1-.01/2) = 0.995 = 99.5% Конечно хорошо: чем больше багов отловлено, тем больше премий себе любимому можно обосновать перед начальством. PS: А если серьёзно, то и количество требуемой работы удваивается. Получается что даже если предположить что результирующая вероятность бага стала такой же как в случае с одним МК, то может лучше эту вторую дополнительную половину работы потратить на лучшую проработку основного ПО и получить меньшую вероятность бага? Тратить время полезно на работу извилин (например: ревью кода сторонним программистом если не доверяете основному), а не на работу пальцев (как можно больше набыдлокодить, авось что-нить и заработает).

Это как взял в правую руку ложку, чтоб супа поесть, но не доверяешь ей (руке). И правда - вдруг она мимо рта да в чужой рот суп пронесёт??? Тогда мы будем её левой рукой контролировать, придерживать, чтоб правая не своевольничала. Странная картина вырисовывается, не правда ли?... Чем больше у вас всякого разнообразия в коде, тем больше вероятность ошибок в нём. Так что ваша система будет ещё менее надёжной чем на одном МК.

Если по выражению не понимаете, то попробуйте подставить вместо x выражение результат которого != 0 и скомпилить, а потом выражение результат которого == 0 и опять скомпилить. Увидите разницу. строка кода - это значит используется так: ... ASSERT_STATIC(..., 0); ... в отличие от выражения (как assert_static()).

Зачем это делать??? Открываем даташит на TM4C129DNCPDT, читаем: "The interleaved memory prefetchs 256 bits at a time. The prefetch buffers allow the maximum performance of a 120 MHz CPU speed to be maintained with linear code or loops that fit within the prefetch buffer." И правда, если посчитать: На чтение одной строки кеша (256 бит) на 120МГц тактовой CPU нужно 6 тактов. Итого: 256/8бит/4байта=8команд, т.е. даже если весь ваш код будет исключительно из 4-байтовых 1-тактовых команд, то одна строка кеша это будет 8 команд. Т.е. - как минимум за 2 команды до конца текущей строки предвыборки будет считана уже следующая строка. И задержки не будет вообще. Конечно если происходит кеш-промах (переход за пределы кеша), то необходимо 6 тактов на загрузку строки кеша. Но это детерминированное время. Загрузка идёт по отдельной шине (ICode bus) и никак не зависит от доступов к другим регионам памяти.