tonyk_av

Я старую версию удалял. А сейчас обновляться перестал.

Может, проще перейти на С++ и не утруждать руки и мозг нажиманием кнопок там, где это же самое может хорошо сделать компилятор? class ADC_device { public: ADC_device( void ); virtual ~ADC_device( void ); virtual uint8 txByte( uint8 a_byte ); virtual bool rxByte( uint8* a_byte ); };

Кстати, Куб после очередного обновления стал ворчать, что не может обновиться, чё-там у меня то ли без подписи, то ли без серта. Так и стоит вот такая версия-сборка:

И да, и нет. Пробовал ставить тёмные темы от Эклипса. После последних обновлений Куба эти темы стали стабильно слетать, поэтому приходится терпеть тёмную тему Куба.

Интересно, насколько сильно замедляется переключение контекста в ОС и вход-выход в прерывание при включенном сохранении контекста FPU? Есть у кого-нибудь цифры для сравнения? Просто обратил внимание на фразы в форумах про FreeRTOS, что сохранение контекста FPU ощутимо замедляет работу ОС и нагружает память.

О как. Возьму на заметку, буду обращать внимание на дизассемблер. По-моему, такие фишки должны управляться опциями компилятора, разве нет?

Согласен. Я посмотрел пару использованных библиотек, но там плавающей точки нет.

В этом нет необходимости. Задача ПЛК исполняет байт-код, дескриптор задачи ОС известен, номер шага программы ПЛК, вызвавшего сбой, тоже известен, так что ошибка определяется с точностью до команды ПЛК, что, собственно, и требуется. Код ошибки запоминается в поле задачи. Пока нет. Я понимаю о чём речь. Приоритет прерывания от VFP выше, чем у планировщика FreeRTOS, поэтому пока не отработает прерывание VFP, задачи не переключатся. В других прерываниях VFP не используется, но если потребуется, то нужно будет сохранять его контекст при входе в обработчик, но пока при входе в другие обработчики я не делаю даже ленивого сохранения.

Искать не нужно, адрес в стэке. Ошибка FPU сбрасывается всегда. Для пользователя выставляется флаг ошибки, с которым он волен делать что хочет. Ессно! В используемой модели данных ПЛК уже есть флаги ошибок вычисления. Мне просто нужно их устанавливать. Читаем PM0214. И какая ошибка, и где она возникло- всё известно при входе в обработчик. У каждой задачи свой набор исключений, так что это не проблема. Ну так сделайте приоритет прерывания FPU выше, чем у прерываний, использующих FPU. В чём проблема? Какими переключателями? Нет там никаких переключателей флажков, в этом-то и смысл использования прерывания FPU. Это же ПЛК, там нет кучи флагов, а есть условное исполнение: загрузил инверсию флага ошибки в LRO и всё. В зависимости от этого флага все команды, зависящие от него или будут, или не будут исполнятся. Используется FreeRTOS, для которой написана обёртка на С++. При создании задачи ОС в параметрах задачи сохраняется указатель на экземпляра класса задачи, в котором будет флаг ошибки FPU. Думаю, в FreeRTOS API найдётся функция извлечения дескриптора выполняемой задачи.

Пример в PM0214. Плюс установить для пользователя флаг ошибки вычислений NaN только пример. У FPU есть ещё исключения. Ещё раз: смысл обработки исключений FPU в том, чтобы не тратить время на проверки перед выполнением операций, дублируя функционал FPU, а реагировать на ошибки, выявляемые FPU в процессе его работы. Ведь ошибки должны возникать редко, так какой смысл тратить на проверки значений операндов команд времени больше, чем выполняется сама команда?

А зачем определять где? Как оказалось, достаточно знать, что при вычислениях была ошибка. Выполнение основного потока команд продолжается, пусть и с прерыванием на установку флага ошибки. Так что кода там мизер. Пример в PM0214. Здесь STM32, поэтому я просто использую доступный на STM32 функционал. Никого же не смущает, что код работы с UART на STM32 не работает под Виндой. То есть тупо дублируете функционал FPU. Зачем? Не доверяете FPU? Ведь проще выполнить операцию и посмотреть флаги результата её выполнения, чем городить кучу кода для проверок или вычисление флагов. Пример выше, в функции ADD, где значения флагов B, C, и Z определяются _до_ выполнения операции сложения, хотя если уйти от кросплатформенности, то можно просто копировать в маркеры значения флагов процессора после выполнения сложения, что будет значительно быстрей и потребует значительно меньше кода. Ещё раз: это нормальный способ. На разных платформах разные механизмы обработки.

Шедеврально! Я даже в лёгком шоке, ибо не могу сходу ответить на обзывание костылями того, без чего не работает ни одно серьёзное приложение. Что вы увидите, когда запустите вашу программу под Виндой, в которой есть строчка? 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 много было схем с МК или ПЛИС, в которых приходилось на ходу переключать направление передачи с входа на выход? Кстати, а ТСу требуется менять направление передачи?

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