Вообще, у ШИМ линейность хорошая. Другое дело, невозможно получить точно ноль и точно напряжение питания из-за сопротивления ключей. Такая же картина и для обычного ЦАП, его выходной буфер, если даже он rail-to-rail, не может обеспечить полный размах. В этом БП полный диапазон выходного напряжения перекрывается при изменении выходного напряжения ЦАП примерно от 100 мВ до 3.1 В (точные значения находятся при калибровке), т.е. начало и конец шкалы ЦАП не используются.

Плавная подстройка как производится?

тупо +/-1 к ШИМу пока не достигнет нужного уровня. Можно ПИД добавить, но пока хватило и этого.
+-2мВ в диапазоне 3В - 0.1% - в принципе неплохо, проверял по образцовому мультиметру и элементу Э303.

Скольки разрядный АЦП используется при этом? В U8002A нечто похожее применяется, так как при включении выхода напряжение быстро устанавливается меньше заданного на 10-20 мВ, затем через 1-2 секунды доходит до номинала.

встроенный 12-разрядный. Сначала хотел применить внешние MCP3551 и 16-битный ЦАП, но пока хватает встроенного и ШИМа.
буфер на AD8552, опорник ADR421.

Я видел такое, кажется, и в одном из вариантов самодельного эталона с GPS-опорником (программное переключение смежных кодов PWM). А можно и иначе, если есть еще один "лишний" DAC или PWM, смешать на резисторах, даже не особо заботясь о сопряжении (вопрос лишь в калибровке). "Грубо" и "точно", соотношение по вкусу.

Вот тут и кроется проблема - если не заботиться о сопряжении, не будет монотонности. А для программного увеличения эквивалентной разрядности монотонность гарантирована.

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

Если бы у автора это была одна из первых работ, то да, это довольно смело... А в данном случае у ЛИ это уже да-а-алеко не первая разработка, опыт, знаете ли, большое дело

К чему это сообщение? Лишь бы что-то написать?

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

Несомненно. Для управления VXCO это было несущественно, для управления блоком питания - в полный рост. Но я имел в виду, что сопряжение выполнять как-то на этапе начальной калибровки, определяя соответствие масштабов. Иначе да, тут и однопроцентные резисторы не особо помогут... Зато и достоинство есть - фильтровать проще и устанавливается быстрее.

Когда бы был приличный САПР, то я бы первый клеймил за осциллограф. Пока же, беспаечная макетка и пара прототипов наш преступный удел.

Очень категорично. Но ведь виртуальные макеты сами по себе нужны только для чисто науки. А потом - паяльник необходим. Да и осциллограф часто не помешает.

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



Что несколько категорично - согласен. Но вектор задан правильно. Паяльник из разработки нужно изживать. У меня было достаточно случаев, когда аналоговая схема после моделирования вела себя на практике точно так же и не требовала никаких доработок.

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

Однако отмечу, что нас снова пытаются увести в сторону от темы те же самые люди.

Вопрос только в том, насколько можно доверять полученным результатам. На едаборде (edaboard.com) встречал мнение одного довольно авторитетного тамошнего обитателя, который говорил, что за много лет видел такие ошибки PSpice, что нарочно не придумаешь: на схеме из пассивных компонентов сигнал на выходе появлялся раньше, чем на входе, а простенький усилитель на полевых транзисторах показывал неплохие результаты на частотах рентгеновского диапазона. Подобные случаи, в силу их курьезности, безусловно не представляют никаких сложностей для разработчика, но после таких ляпов становится очевидным, что прямая "выгрузка" результатов моделирования в продакшн невозможна. Никто не поручится, что софт в определенной ситуации не станет врать весьма правдоподобно. Вот и выходит, что инструмент этот хороший и полезный, но нуждается в обязательной проверке полученных результатов экспериментальным путем. Иначе, риск сэкономить себе в убыток неприлично велик.


Да кто бы спорил. В автомобильной промышленности САПРы применялись чуть не со времен появления первых компьютеров, однако на "беспаяльниковую" разработку производители вышли лишь совсем недавно (могу немного спутать, но где-то год 2004-2005). До этого каждая новая модель автомобиля обязательно проходила этап предварительной сборки и выявления расхождений компьютерной модели и реального изделия. Это в автомобильной отрасли, где вложения таковы, что экономить им не переэкономить и автоматизация дает весьма внушительный эффект, т. ч. CAD-ы там прокачивались десятилетиями и многомиллионными бюджетами.

В разработке электроники затраты существенно ниже (легко сравнить по стоимости сборки прототипа автомобиля и прототипа электронного устройства), что предполагает существенно меньший экономический эффект, что, в свою очередь, предопределяет возможные затраты на разработку средств автоматизированного проектирования. Раз денег меньше, то и прогресс медленнее. Чего говорить про всякую электроннопроизводящую мелочь, если даже Интел сначала выпускает инженерные семплы, потом семплы для разработчиков, а только потом запускает продакшн. Причем и это не всегда окончательная версия изделия, т.к. часто потом выпускается еще куча степпингов, которые могут отличаться друг от друга весьма ощутимо.

Раз уж Интел (самый крупный производитель электроники в мире) не может избавиться от "паяльника" в разработке, то есть ли смысл говорить об этом нам здесь и сейчас?

Моделировал в Pspice не один десяток схем, поэтому довольно хорошо представляю границы применимости результатов. Да, некоторые фокусы бывают, типа киловольтового выходного напряжения ОУ, но они легко отсеиваются. Проблемы получения правдоподобных, но неправильных результатов ни разу не встречал.

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

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



Измерил тепловое сопротивление радиатора после покраски. Получилось 1.1°C/Вт (до покраски было 1.3°C/Вт). Получается, можно сочетать красивый внешний вид и эффективность.