syv

Поясню свою мысль. Курсовик - это прежде всего тренировка. Желательно отрепетировать весь путь с нуля. Смотрите. 1. Незнакомый, но простой комплект, следовательно можно освоить архитектуру с нуля и быстро. 2. Для реализации задачи потребуется с десяток микросхем, значит будет освоен САПР со всеми тонкостями. 3. Программка тривиальная, пишется быстро, но требует ознакомления с системой команд. Итак, имеем на руках тренировочный комплект для быстрого овладения навыками эмбеддера. А на работе мне нужен человек, который не боится осваивать что-то новое. Вдруг завтра ARM разорится? :) И еще. Представьте себе, что завтра Вам предложат высокооплачиваемую работу, но с незнакомой Вам платформой. Что делать будете?

Аванс давали?

Поэтому и надо Вас отчислить. Потому как техногенные катастрофы достали уже... Вполне нормальный курсовик. Не напряжный. А старинный комплект по нынешним временам - только в плюс.

Аналогично. +1000. И так все не очень хорошо с профессией в наших странах, а если еще и поощрять бездельников и неучей...

Чего это вдруг Cosmo стало левой конторой? Не нравится - не бери. А если берешь - проверяй. Зато цена - вполне. А хваленый EPCOS с недавних пор полевел. Давеча нарвались на электролиты с офигенным ESR. Хотя маркировка абсолютно та же. Вот она - продажа EPCOS-а японцам из TDK.

То, что Вы описали, и есть режим непрерывного потока трансформатора. Когда речь идет о дросселе, говорят о непрерывном токе. А в обратноходовом трансформаторе можно вести речь о непрерывном магнитном потоке через поперечное сечение сердечника. Ток в первичке всегда будет начинаться с нуля. Затем, в классическом варианте, он будет резко возрастать до величины, обусловленной магнитным потоком, существующим с предыдущего цикла. В Вашем случае в этот момент наблюдается "звон", потому что в отличие от идеала, все контура, куда может протечь ток, определяемый остаточным магнитным потоком, "заткнуты" паразитными фильтрами в виде паразитных емкостей и индуктивностей. Собственно, они и определяют частоту этого "звона". Потом, ток первички (и магнитный поток) будут возрастать со скоростью, определяемой индуктивностью первички и приложенным к ней напряжением. В момент выключения силового транзистора за счет ЭДС самоиндукции откроется диод. И магнитный поток начнет падать за счет протекания тока во вторичке. Скорость спада определится индуктивностью вторички и выходным напряжением. Ток вторички в начале будет пропорционален току первички на момент выключения транзистора через коэффициент трансформации. За время закрытого состояния транзистора ток вторички не успевает упасть до нуля и в сердечнике трансформатора остается некий магнитный поток. В момент открывания транзистора все повторится снова. Вот вкратце описание процессов в режиме непрерывного магнитного потока сердечника. Заметьте, никаких дурацких терминов в виде "наскока одной обмотки на другую". Замечу так же, что режим непрерывного магнитного потока сердечника вполне допустим, но его надо уметь "готовить". Если угодно - совет. Выкиньте свой литцендрат нах. Возьмите Ш-образный сердечник с зазором. Рассчитайте все обмотки таким образом, чтобы каждая из них поместилась в один слой. Первичка самая близкая к керну. Затем вторички, начиная с самой длинной. Затем обмотка обратной связи. Наилучшим вариантом была бы вторичка с отводами, но намотанная в один слой. При намотке надо отступать от краев как минимум 1,5 мм. И не жалеть изоляции из пленки ПЭТ-Э между слоями. Это позволит Вам снизить межобмоточные емкости.

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

Это связано с плохой работой выходного диода при переходе из режима прерывистых токов к режиму с непрерывным током. А это, в свою очередь, может зависеть от кучи факторов. 1. Неверно подобранные или отсутствующие диодные снабберы. 2. Очень большие значения паразитных параметров трансформатора (при условии, что со снабберами все ОК). 3. Плохая топология печатной платы. 4. Некорректно выбранный тип выходного диода. 5. Сочетание нескольких факторов. И вообще. Я бы не рекомендовал Вам использовать эту МС в режиме непрерывных токов. Рекомендую ознакомиться с документацией на ИС Viper от ST. Там все изложено достаточно популярно. Можно воспользоваться этими рекомендациями применительно к Вашей ИС.

Лучше по форме тока сквозь первичную обмотку.

А что? I2C индикаторы запрещены к применению? Или отменили MK с аппаратным параллельным портом?

А зачем? Если такая потребность возникает, то что-то не так с Вашей схемотехникой.

И тратит при этом процессорное время на пресловутые nop-ы.

А Вы в курсе, что по очень правдоподобной легенде, нынешние популярные вычислители AVR и ARM созданы именно студентами. Тогда я бы пошел еще дальше. Надо разбираться в теории того, что ты делаешь. Даже здесь в качестве примера приводилась задержка в виде цикла замкнутого на себя. Но это же недопустимо по-любому. Я даже на РС так не делаю. А уж на МК...

В мемориз, однозначно! Все правильно. Каждой задаче - своя методология ее решения. Нет применению ООП без нужды! :)

Вы знаете, где это можно сделать безболезненно. Я готов доказать Вам на реальных фактах, что Вы не совсем правы. Дык, на С и С++ пишут тоже все подряд. И схемы разрабатывают. И Саяно-Шушенскую ГЭС эксплуатируют. Давеча вон Фобос-Грунт... Что же касается кода, о котором я говорил, приходите - покажу. Писали немцы - уважаемые и опытные люди. Если сможете сделать лучше, даже денег дадут. Только одно НО. На верхнем уровне порядка 60 тыс тэгов. Число датчиков, как дискретных, так и аналоговых - порядка 100 тысяч. Плюс к этому, Ваше оборудование должно быть сертифицировано во всех инстанциях по всем необходимым критериям безопасности и качества. В том числе и Вы, как программист. Я ПЛК не разрабатываю. Я их эксплуатирую. Поэтому, Вам виднее... И вообще, здесь речь не о ПЛК...

Когда сильно припекает - можно и на АСМ-е. :) Но это бывает крайне редко. Практически никогда. А мне приходилось в юности и на PDP-11 в кодах... Но я никогда не провел бы прямой аналогии: код->Асм->С->С++. Пмсм, это выглядит вот так: код | Асм->С | С++. У меня нет автомобиля. Управлять я им не умею. Но аналогия понятна. И отражает она лишь исключительно Ваш жизненный и профессиональный опыт. Хоть мне и трудно - продолжу про автомобиль. Автоматическая коробка передач. По Вашей методологии на всех автомобилях должна быть только такая. Но это далеко не так. Даже на пафосных дорогих автомобилях есть оба варианта. Почему? Для начала - вовсе не критикую. Подход как подход. Годится для большого количества программистов В определенных ситуациях незаменим. Сам пользуюсь на верхнем уровне при изготовлении HMI. Но у него есть свои недостатки. И не везде он годится. Возвращаясь к Вашему примеру про ПЛК. Все, что Вы описали - естественный процесс. А то, что Вы делаете руками - искусство. И повторить реальность - не выйдет. Соглашусь - инструментами надо владеть. Но и плодить лишние псевдосущности в виде не всегда нужных классов тоже не имеет смысла. Беда в том, что я плотно знаком со всеми подходами. Техническая сложность программирования ПЛК несоизмеримо Выше, чем МК. Особенно, когда код состоит из сотен тысяч строк на один ПЛК. А таких ПЛК в системе далеко не один. И все это связано сетью. Плюс к этому - верхний уровень и HMI глобального и локального уровня. Ну Вы же далеко не сноб. Зачем же принижать квалификацию профессионалов в той области, с которой Вы сталкиваетесь крайне редко? То, что Вы изложили - дилетантизм, простите за резкость. Я не буду ничего объяснять в этой ветке, поскольку она не о ПЛК. Если кому интересно - могу изложить отдельно. Это отдельная тема. Только скажу одно - спроектировать ПЛК может любой выпускник ВУЗ-а. Для этого ничего не надо, кроме небольшого набора знаний, которые у него есть. А вот сделать проект средней по сложности линии - вряд ли. И это не голословное утверждение. Это многократно проверено на практике.

Опять же. Вы пытаетесь спрятать проблемы, абстрагироваться от них. Извините за сравнение, как пресловутый страус. На самом деле, весь этот сонм переменных и функций никуда физически не исчезает. Он прячется по разным, порой труднодоступным закоулкам, которые программист предусмотрел для них. Инкапсуляция называется. Ведь рано или поздно Вам, таки, придется излагать математическую модель для каждой из электрических машин в отдельности. Т. е. реально вы будете иметь ряд виртуальных функций для управления по моменту и по скорости. Но Вам один фиг придется написать весь комплект математических моделей для каждой из машин в классах потомках. Приношу свои извинения за то, что заставил Вас написать столь длинный пример. Поверьте, я не со зла. Я только хотел сказать, что под общепринятым понятием может скрываться хренова туча разнородных объектов. Добавлю только, что трансформатор - тоже электрическая машина. А внешних свойств с остальными вращающимися машинами у него практически нет. Хотя его тоже можно включить и выключить. :) И плавно переходим к кактусам. Сравниваем мой и Ваш. Я бы сделал в базовом классе вращающихся машин в первую очередь виртуальные функции, позволяющие осуществить управление по моменту и по скорости. Если бы у нас дополнительно стояла задача серво управления, то еще добавил бы виртуальных функций для точного перемещения. Что касается "стоячих" электрических машин трансформаторов и асинхронников с заторможенным фазным ротором, то здесь вообще для меня не ясно, что делать. Поскольку назначение этих девайсов совершенно иное, чем у вращающихся машин. И в результате наши классы получились бы полностью разными. Потому как построены на разных подходах при достаточно общей постановке задачи. А других постановок задач в нашем беспокойном и яростном мире ожидать не приходится. А вот здесь Вы неправы. Помимо мира "чистых" программистов существует такой же огромный мир программистов промавтоматики. А там код весь код именно такой - неструктурированный, где все связи между объектами изначально были только в головах механика и технолога, которые рисовали циклограммы технологического процесса. Потом к этому делу приложились программисты, которые и понятия не имеют о реальных механизмах машины и процессах, происходящих в ней. И ничего, тысячи людей зарабатывают тем, что сопровождают такие проекты. И даже модифицируют их, когда этого требует производство. Быстро и качественно. Иначе лишат сладкого. Там тоже есть свои кактусы. И свои методы. И специально обученные люди. И чтобы было понятно - поясню. Речь идет о нескольких миллионах строк кода. А с каких это пор модель перестала быть самостоятельным объектом? На самом деле у Вас есть два объекта - сам реальный объект и его виртуальная модель. И хорошо, если Вы не ошиблись, когда только начинали проектировать базовый класс. Или вдруг не поменялись свойства нижнего объекта таким образом, что Вам придется перелопачивать практически все. Иначе наварите таких макарон, что спагетти покажутся царским лакомством....

Ну я, конечно, не большой поклонник С++, но не настолько. И вообще, есть целый класс задач и условий труда программиста, когда без ООП - никуда. Мы это уже обсуждали, и тогда Вы меня убедили. Это понятно. И при правильной эксплуатации вполне логично. Имеет и еще какое. Но об этом ниже. Вот здесь мы и расходимся. У меня в этом мире нет ни одного объекта, совпадающего с другим, кроме искусственных, созданных программно. А это всего лишь часть задач, предлагаемых к решению. И здесь, ПМСМ, кроется некое противоречие. Любители ООП ломают задачу под себя. При этом они абстрагируются от архитектуры вычислителя и от от реального объекта, упрощая его своей моделью в виде класса. При этом создается некая искусственная среда, зачастую включающая в себя ОС там, где это не является необходимостью. А вот на этой благодатной почве и расцветают все кактусы. Поскольку Ваша искусственная среда естественным образом не совпадает с моей. И я, желая использовать Ваш код, вынужден разбираться в Вашем восприятии реальных объектов. А это для меня практически не осуществимо. Есть иная концепция. Когда программист приспосабливает вычислитель к реальным объектам без искусственной среды. При этом считается, что каждый объект уникален. Встречный вопрос. Сколько потребуется Ваших вопросов, чтобы Вы смогли приступить к созданию класса? Лично я считаю, что для управления реальными объектом, искусственный промежуточный программный объект не нужен. Иначе это дело разрастется в систему классов, подобную той, что нужна для GUI.

ПМСМ, разногласия С-филов и С++-филов не отражают ничего, кроме разницы в характерах самих оппонентов. Дело в том, что кому-то достаточно сложно далеко абстрагироваться от первоначальных объектов, а кому-то нет. С++ характерен тем, что гораздо более полно отражает кактусы, пустившие корни в голове программиста. И если кто-то классифицирует (в смысле С++) объект так-то и так-то, то другой может и не разобрать то, что наворотил первый. Поскольку имеет свои представления об этом же объекте. В корне отличающиеся от представлений первого. Чтобы не быть голословным, попрошу уважаемое сообщество создать класс "машины электрические". А там посмотрим - у кого что выйдет...

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

Спорить не буду, но почему-то все поголовно стараются уйти от фазового управления. Т. е. преобразователей ведомых сетью. Видимо, не каждая сеть может выдержать издевательства в виде подобных устройств. Интересно, с чем связана такая нелюбовь к столь "незаменимым" девайсам? А альтернатива есть. За рубежом только ею и пользуются...

Мне приходилось наблюдать подобные девайсы в работе. Греется, воняет, а желаемую выходную характеристику не обеспечивает. При этом к железу транса прилипает все близлежащее, сделанное из стали. Единственное место, где вся эта беда работает более-менее сносно - это электровоз. Что касается коммутационных помех, то именно они послужили причиной отбраковки импульсных источников автором темы. Помехи от инверторного источника питания дуговой печи создавал лично в графитовом тигле. Близлежащие приемник, телефон, Wi-Fi работали вполне сносно.

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

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

А какой в нем смысл? Чтобы больше денех потратить что-ли?