tonyk_av

Шедеврально! Я даже в лёгком шоке, ибо не могу сходу ответить на обзывание костылями того, без чего не работает ни одно серьёзное приложение. Что вы увидите, когда запустите вашу программу под Виндой, в которой есть строчка? x /= 0; Не BSoD, а сообщение о недопустимой операции. Не задумывались, откуда оно взялось? Так именно это и делается. Вычислительный алгоритм может быть сложным, да ещё и циклическим, поэтому при одном наборе данных алгоритм может давать нормальное число, а при другом- не число. Посмотрите для начала список исключений, которые могут возбуждать команды FPU. Большинство команд могут возбуждать по несколько исключений в зависимости от значений своих операндов, поэтому общепринятой практикой является отсутствие проверок перед выполнением команд FPU и информирование пользователя в том или ином виде, что при выполнении вычислений произошла ошибка. Вы в своих программах перед каждым сложением или вычитаем проверяете каждый целочисленный операнд да допустимость их значений, гарантирующих, что при сложении/вычитании не произойдёт переполнения? Представляете, во что выливается такая проверка? Ниже пример реализации целочисленного сложения. Код этого функционального блока: FPU при работе на аппаратном уровне вычисляет и результат, и флаги, причём делает это очень быстро. Так нафига мне делать туеву хучу проверок, когда FPU просто дёрнет прерывание в случае недопустимых данных? Зачем _программно_ дублировать _аппаратный_ функционал FPU? Не задумывались? Или все люди имбицилы, которые только и занимаются делением на ноль и извлечением корня из отрицательного числа? Меня окружают люди, которые понимают математику, поэтому их программы в процессе вычислений крайне редко делают ошибки, так зачем тратить кучу времени на проверки, существенно замедляющие работу, когда можно в редких случаях обработать прерывание от FPU при ошибке вычислений и установить флаг недостоверности результата вычислений?

Я впервые столкнулся с вопросом достоверности измерений именно при разработке прибора, измерявшего отклонение сопротивления от номинального значения. Так оказалось гораздо проще проверить флаг ошибки перед индикацией результата, чем городить кучу проверок, что было особенно важно для прибора с батарейным питанием.

Не такая уж и узкая и специфическая. Дело в другом. Если кто-то выполняет вычисления на FPU в задачах управления, то перед выдачей управляющих воздействий он должен проверить достоверность результата хотя бы с точки зрения математики, а то получит NaN и фиганёт его в виде 0xFFFFFFFF на ЦАП.

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

Я про то, что конденсаторы могут быть сделаны прямо на кристалле. При малых токах потребления и высокой частоте коммутации это рабочий вариант. По такой схеме реализован ряд R2R ОУ.

В прерывании- никак. Но в прерывании будет выставлен флаг, сигнализирующий пользователю о том, что в процессе вычислений была ошибка и результат вычислений недостоверен. Готов поспорить, что в МК вы не проверяете статус FPU после вычислений. Наоборот, именно в прерывании я исправлю результат работы операции, вызвавшей сбой и пропущу её, чтобы остальные команды не дёргали прерывание. Ессно. Самое главное, что взведён флаг недостоверности, а там уж пользователь пусть сам решает, что делать.

В общем, как обычно, всё оказалось проще и описано у самой СТМ в PM0214. Там же есть и список исключений, который может возбуждать каждая команда FPU. Странно, что люди выполняют расчёты, но даже не знают, как проверить их достоверность, иначе сразу бы отослали меня к этому РМ.

Что мешает сделать умножители и инверторы напряжения на коммутируемых конденсаторах? MAX233 как пример реализации идеи.

Можно теперь послушать тех, кто изучал математику ЭВМ, численные методы и знает, как обрабатывать ошибки вычислений FPU?

Работаю с STM32F446. Данные идут от человека, поэтому возможные деления на ноль, переполнения и тому подобные неприятности, по которым CPU улетает в Hard fault. Понятно, что попав в обработчик, можно посмотреть флаги FPU, чтобы понять причину попадания и выставить флаги ошибки в пользовательской программе. Вопрос: как правильно восстановить состояние FPU? Как правильно вернуться к выполнению пользовательского кода? Ткните пальцем в пример или где почитать. P. S. Вспомнил, что где-то на форуме Миландра описывалась что-то подобное, поищу. Но, думаю, где-то должны быть описания и примеры обработки.

Изучай, тут всё есть.

Начинаем как GPIO, продолжаем как вход таймера. Зачем ногодрыг? Что мешает использовать SPI DMA?

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

У меня нигде нет не двунаправленных линий ввода-вывода, или ввод, или вывод.

Почему ужас? SPI для всего этого нужен будет один, переплата в виде одного-двух сигналов для защелкивания данных в/из буферные регистры практически мизерна. Уже при 16DI+16DO такое решение выглядит вполне симпатичным, особенно с учётом цены и доступности 165 и 595.

Немного оффтоп, простите. Подобное было на платах контроллеров от Fastwell. Там стояла ПЛИС, в которую программно можно было загрузить прошивки для разных чипов, например, 8255 или 8251. Помню, грузил в такую ПЛИС то ли 2, то ли 3 "чипа" 8255, после чего обращался к ним через IN-OUT. Удобно и очень быстро. Так и просится подобное, но через SPI. Недавно трассировал плату, которая была узкая и длинная. Еле-еле развёл на ней 16DI по этой причине. Будь там чё-нить а-ля MCP23S017 было бы намного проще разводить, хоть 64DI развелось на раз-два. Поэтому поддержу вопрошающего:

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

Я дико извиняюсь за не очень вежливый ответ, но неужели в вашей компании, которая нет людей, способных объяснить их назначение? Так же как и назначение резистора R34 на моей схеме. У меня такое ощущение, что показанную мной картинку из траковской мурзилки ТС видит впервые, иначе сначала разобрался бы с типовой схемой от производителя, прежде чем рисовать свою. Предлагаю в выходные почитать книжки по ссылкам выше, а потом вернуться к обсуждению, ибо P. S. Подтяните свою грамотность в этом вопросе хотя бы для того, чтобы понимать ответы на свои вопросы. Просто мало кому приятно распинаться перед людьми, которые не хотят напрягаться для поиска ответов на свои же вопросы, а хотят тупо получить готовый рецепт.

Странный вопрос. Вы документацию и рекомендации производителей читаете? Исходя из опыта и специфики получаются примерно такие схемы (замечание: на входе не стаб, а TVS):

А что за DC-DC? Подозрительно мало деталей в цепях защиты даже в сравнении с рекомендуемыми производителями схемами. И с DI и DO то же самое.

Было именно предупреждение, а не ошибка, я потому и запомнил, что вот ведь, она, переменная, используется в цикле, а компилятор пишет, что она не используется, причём после цикла присваиваю переменной другое значение для промежуточных вычислений- на тебе. Копипаст сделал и зацепил повторное определение.

Нифига подобного Вот прям сегодня по ошибке написал такое, так g++ ткнул во вторую строку с предупреждением о неиспользуемой переменной. Надо смотреть на версию стандарта, поддерживаемую компилятором и на то, какие предупреждения разрешены или запрещены. Последние версии gcc стали более строже отслеживать подобное, а g++ на подобное всегда ругался, поэтому собирайте ваши программы g++, и будет вам Щастье.

Это про какие стандарты речь идёт? Не надо забывать, что помимо стандартов есть ещё и требования к питанию потребителей, которые необходимо учитывать при выборе схемы обеспечения бесперебойного питания потребителей. Я в самом начале писал, что АВР вредно быстро переключать. Для ответственного оборудования проблема решается просто: между АВР и нагрузкой ставится онлайн ИБП с не большим временем поддержания нагрузки. В этом случае нагрузка даже не заметит переключений. Когда в шкафу электроники на несколько миллионов, добавить ИБП, даже за сотню тысяч, не проблема.

А ФНЧ на входе АЦП по какой частоте рассчитывают? Буржуи называют её частотой Найквиста, которая равна половине частоты дискретизации, то есть применительно к AD7953 это будет 1.024 МГц, и далее по тексту пишут, что DSP у AD7953 выдаёт результаты измерений (не отсчётов!) с частотой 8 кГц. Есть ведь ещё оверсэмплинг, например, в Н7 (про F7 не помню, возможно, тоже есть) он реализован аппаратно, поэтому логично, что частота выборки и частота поступления отсчётов это в общем случае две разные частоты. Делал контроллер, который измерял среднее, СКЗ, минимум, максимум, активную и реактивную мощности и период на STM32F7. Было 12 каналов, по каждому каналу частота выборки была 12 кГц. Вычисления выполнялись каждый период. Использовалась 32 и 64-битная арифметика, загрузка ЦП была около 3-4%, если память не изменяет. P. S. Я просто хочу разобраться в терминологии, потому что, как мне показалось, тут есть разночтения в русскоязычной литературе и буржуйской.

Ну так сами посмотрите на картинку. Чёрным по белому написано, что частота выборки 895 тысяч выборок в секунду. ade7978_7933_7932_7923.pdf