Pull to refresh
0
0

Embedded system engineer

Send message

Где-то встречал описание попытки разобраться — в общем проблема в отсутствие POSIX сигналов в Win, типа ctrl-c, но это не точно

Не надо весь инет перерывать, есть вполне авторитетные источники:
Нейман Л. Р., Демирчян К. С. Теоретические основы электротехники. Т. 1.-М. – 1966.
С первых страниц вводится понятие электромагнитного поля как некоей математической абстракции, вполне соответствующей наблюдаемым явлениям

Было дело, но вот к этому патенту я не имею никакого отношения. Немного забавно, особенно когда вспоминаешь сколько мучений доставляет написание формулы изобретения

вы не можете любить кого-то прямо сейчас, а завтра разлюбить. Или верить во что-то сейчас, а через час перестать верить

Ну почему именно такое объяснение?

Киберспорт забыли. Развивает реакцию, выносливость и прокачивает мышцы пальцев.

Спасибо за оперативные пояснения. Вопрос в продолжение дискуссии. Верно ли утверждение, что при условии принятых допущений (в силу указанных элементов схемы замещения) максимальное значение передаваемой мощности через трансформатор не превышает 2,5%? Я вроде бы смотрю, но в схеме замещения нигде не вижу оговорок про магнитные свойства среды, в которой осуществляется передача энергии и естественно прихожу к выводу, что полученное выражение распространяется на все возможные варианты, в том числе и на обычный трансформатор с магнитным сердечником. Уточните пожалуйста конечный результат, при каких условиях он получен

Ваша конечная формула для мощности на приемнике в пределе при выполнении советов 1 и 3 дает обратную зависимость от взаимоиндуктивности в квадрате (если произведение активных сопротивлений r1 и r2 будет гораздо меньше индуктивного сопротивления х3), т.е. выводы противоречат полученному выражению максимума мощности. И с каждым последующим увеличением частоты или количества витков, что в обоих случаях приводит к увеличению индуктивного сопротивления еще больше будет приводить к противоречию.

Недавно наткнулся на ништякового тараканчика UCD3138. Все то, что нужно для ИИП.

Если на эту картинку смотреть как на стереоскопическую, то начинают проявляться процессы, схожие с моментом Большого взрыва

напряжение меняется с -220 вольт до +220 вольт 50 раз в секунду

<занудство> 220 — это вообще-то в идеальном случае средне-квадратичное, т.е. интегральный показатель, а не мгновенное значение. За период сети напряжение 2 раза принимает значение 220 В и 2 раза -220 В. Если уж хотели проучить, так бы написали, что напряжение имеет периодическую форму, в лучшем случае синусоидальную с амплитудой 220*1,4142 и частотой 2*π*50.</занудство>


PS Извините за нудятину

Спасибо за ссылку. То, что параметры SiC и GaN на порядок лучше IGBT, сомнений не вызывает. Сомнения были только по низкой цене. Два года назад вот такая штука приобреталась за 300 €. С учетом прыжка рубля, психологический барьер держался до сих пор.

появились дешевые SiC ключи

пруф, пожалуйста. И на GaN, если тоже есть сведения о дешевых

Конструктивно электродвигатели делятся на два типа: инраннеры и аутраннеры.

Синхронные машины бывают с индуктором на роторе, статоре или комбинированного типа. По сути тоже, только без сраннеров

Ваш живой пример прекрасно работает при указанном workaround #3, т.е. через настройку программных приоритетов. Если я правильно понял, контекст задачи заключается как раз в том, что сначала нужно выполнить очень приоритетные инструкции в прерывании, а потом идет череда второстепенных. Вот эти второстепенные, но все в том же прерывании, могут быть "отложены" на время работы с оборудованием. При этом программный приоритет прерывания настроен на самый высший уровень. Верно?


Где в reference есть прямой запрет на изменение I1/I0 внутри ISR? Может быть мне еще запретят завершать ISR любым другим способом, кроме как по команде IRET?

Не надо ерепениться. Речь не о запрете, а об отсутствии документированного поведения на все возможные действия. Ожидали одно, а получилось другое и виноват производитель. После первой убитой недели можно было бы и в службу поддержки обратиться.


Тем не менее, спасибо Вам за занимательные грабли. Будем иметь в виду. Могу по случаю проверить на STM8S003 или STM8L052C6, тем более что намечается разработка с пониженным энергопотреблением. До осциллографа надо только донести

По первому отписался ниже.
По второму, стандартно, т.е. "условно стандартно", перешли по вектору прерывания, обработали, вышли из прерывания соответствующей инструкцией. Если нужно раскидать обработку прерываний от разных источников, то выставляем соответствующие программные приоритеты. И совсем другая ситуация "условно не стандартно" когда понижают приоритет в самом прерывании. С какой целью, словить другое прерывание и обмануть логику микроконтроллера? Во всяком случае, без понимания контекста задачи трудно понять зачем такие выкрутасы. Если нужно выполнить еще какие-то операции, например инициировать запись следующего байта/слова и при этом дать возможность другим прерываниям на приоритетную обработку, то тут, как мне кажется, проще в самом прерывании окончания записи байта разрешить более приоритетные прерывания путем воздействия на механизмы запрета самих же прерываний, но никак не на статусные биты контроллера. Опять же, такой вариант исходит из того, что у Вас изначально приоритет EEPROM IRQ был самым высоким по каким-то причинам.


По третьему. Вы можете однозначно сказать, когда происходит переход по вектору вложенного прерывания, до или после "ручного" изменения битов приоритета CC? Это событие нужно отследить при разных программных приоритетах EEPROM IRQ.


Мне кажется, я начал улавливать причину такого поведения. Пока Вы разруливаете приоритет прерываний программным способом, а восстановлением состояния CC занимается IRET, то все происходит как положено. Но как только начинается несанкционированное изменение статусных битов, выполнение инструкции IRET приводит к неоднозначному поведению.

Аналогичная ситуация происходит и в случае понижения приоритета кода в ISR EEPROM до любого другого значения, отличного от I1 == I0 == 1.

Ну вот теперь уже понятнее. То есть при выходе из вложенного прерывания в состояние с любым меньшим приоритетом происходит возврат в сон. Такое поведение выглядит действительно, мягко говоря, "странноватым" и как минимум должно быть обоснованным в документации. Поймите правильно, мне здесь не нравится только оговорка про "любое меньшее". Но мне вполне логичным кажется такое поведение при возврате в состояние с наименьшим приоритетом.


А по поводу PC, что Вас смущает? В спячку контроллер возвращается после выполнения RETI (при установленном AL), а значит PC должен выгрузиться из стека до остановки тактирования. При возобновлении тактирования содержимое PC вполне определенное, и именно то, которое было до входа в последнее прерывание.

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity