amaora

В основном силовом сервоприводе есть оценка или измерение момента (или силы) нагрузки. Эта оценка передаётся на сервопривод ручки управления. В ручке обычный сервопривод, но работающий по сигналу заданного момента (или силы) а не по положению. При необходимости можно в сервоприводе ручки ограничивать/ослаблять момент, скорость, имитировать вязкость или что угодно. Сигнал с положения ручки идёт на заданное положение силового сервопривода.

Обычно, на хорошем моторе, чтобы пустить такой же ток но в обратную сторону нужно лишь немного уменьшить подаваемое напряжение, а не подключать его другой стороной. На активном сопротивлении обмоток действительно выделиться столько же тепла при том же токе. А по питанию, в цепи постоянного тока, ток сменит знак и будет накачивать ёмкости если лишнюю энергию никуда не отводить. Резистор при этом подключается к цепи постоянного тока, а не напрямую к мотору.

В SO(3) такое невозможно, определите порядок поворотов и найдёте углы. Если только приращения маленькие, то можно приближённо взять мнимые компоненты кватерниона умноженные на 2.

У меня аналогичная одноранговая CAN сеть, и так же проблема с раздачей коротких адресов. Сейчас все держится на том, что ответы узлов с длинным первичным уникальным ID посылаются с недетерминированной задержкой, и перепосылаются в случае неудачи. Но я пока делал тесты только на игрушечной сети из трех устройств.

Оставьте в цикле только работу с fatfs, остальное перенесите в обработчики прерываний (сами решайте каких, хотя бы и по таймеру). Это самый простой способ.

А я смотрю со стороны того, что имеем сейчас step-down сделанный на LM46001 по схеме из ДШ (500 кГц, 22 мкГ), который делает 5в из диапазона 5-50в, то есть коэффициент 10:1. Он нормально работает и от 5в и от 55в, и это бывает полезно в некоторых применениях. Не понимаю, какие преимущества даёт несколько вариантов исполнения на разные входные напряжения? Почему версия рассчитанная на максимальное входное не может работать от нижнего предела с заполнением близким к 100%? Да, сильно прижиматься к 12в не нужно, бортсеть не предполагается. Допускаю возможность ограничиться диапазоном 48-200в для случая flyback или других топологий с трансформатором, но по ним я ещё не понял ничего.

Нет, не кабель, это источник питания для контроллера BLDC, первичный источник - аккумулятор (наиболее вероятные варианты от 48в до 120в).

Сейчас использую LM46001 для того чтобы сделать 5в ~1А из 5-50в. Можно найти несколько вариантов замены на 100в входного (LM5116, MP9486, ...), но оказывается нужно до 200в. Ввязываться в разработку источника желания нет, хочется взять готовое и надёжное. С изолированными топологиями не работал, не знаю особенностей. 1) Вход: 12-200в (нижнюю границу можно подвигать, чтобы не усложнять преобразователь, изоляция не требуется); 2) Выход: 12в +/- 0.5в ~1А; 3) Обойтись без выводных и высоких компонентов, трансформатор плохо вписывается; 4) Проще лучше, не хотелось бы выдумывать схему из низковольтного step-down контроллера + стартового линейного регулятора + драйвера + транзисторов. Что можно сделать? Или лучше смотреть flyback?

По моим наблюдениям, чаще всего на высоких dv/dt по ёмкостной связи проходят эти импульсы в сигнальные цепи, нарисуйте паразитные конденсаторы на схеме. По измерениям использую "пружинку" заземления на щупе и отдельное (изолированное) питание осциллографа либо исследуемого устройства.

Отдельный пул свободный блоков под каждый размер. Можно заранее их аллоцировать через malloc (когда блоки мелкие и важна локальность), а можно по мере работы пополнять пул, вместо того чтобы делать free. Когда надо alloc, то соответственно смотрим в пуле, если там пусто то уже делаем malloc.

Не знаю есть ли подобное в GCC, если бы это позволило бы навязать ramfunc атрибут (сделать копию) всем используемым в функции символам, возможно было бы удобно. Но в любом случае компилятор не сможет гарантировать отсутсвие обращений к flash.

Оба куска склеиваются вместе в один образ и объявляются константы содержащие размеры и адреса, чтобы можно было этот образ разделить и загрузить куда надо. Смотрите как работает загрузка .data секции (в самом обычном скрипте для запуска из flash), что передаётся в стартовый код. Можно и отдельно два бинарника собрать, если встроенный механизм загрузки не нужен и кто-то загрузить их оба.

Репозиторий 1 под схемы-платы-чертежы, репозиторий 2 для кода. В первом проставлются теги (метки ревизий) соответствующие версиям ушедшим в производство, так чтобы всегда можно было найти схему-плату-чертеж для конкретного изделия. Во втором ведётся обычная разработка софта, привязки к железу на уровне контроля версий нет, вместо этого внутри самого софта есть варианты конфигураций, сборка под разные ревизии платы. Так лучше, проще собирать свежие версии софта под старые ревизии железа. Документация живёт вместе с софтом но пока у меня все плохо с ней.

ready_flag это на одном уровне кода (про который говорим), а работа с регистрами на другом (там volatile почти всегда к месту), не надо все в одно мешать. Сделаете тогда может быть все объявления типов с volatile? С флажком самый простой пример, чтобы показать что без и volatile можно сделать то же самое, причём часто все fence() уже есть в коде. Множественные ненужные чтения получаются когда volatile прилепляют ко всему, по методике "если доступ из разных потоков то надо volatile". Вот это я и считаю неверным, а не само использование volatile.

Так они там и есть, это же работа с регистрами IO чтобы включить событие. А даже если нет, то ещё один fence() так же можно поставить (если им и без того не является сам req_new_event), чтобы запись 0 не перенеслась. Это слово не вполне выражает то, что хотят им сказать в задачах синхронизации. В некоторых случаях порождает лишний код множественной записи-чтения там где этого не нужно.