xvr

http://www.allegromicro.com/en/Products/Ca...es/ICs/sink.asp

Хочу добавить свои 5 коп. к всему вышеизложенному: const и enum - типы C++ и они подчиняются правилам видимости (scope), т.е. если у вас есть const ABC на уровне файла, то вам никто не мешает завести int ABC где нибудь в классе, с define такой номер не пройдет. Здесь можно возразить, что нефиг заводить ABC в классе если уже есть ABC на глобальном уровне (и это отчасти правильно), однако не всегда можно вспомнить где и какие глобальные константы были заведены (особенно исли их количество перевалит за пару тысяч, а файлов с их описаниями - за пару сотен), а с другой стороны, если мы поместим константы и класс в разные пространства имен (namespace), то тут все будет идеологически правильно по всем канонам OO, что все равно не избавит нас от большого облома с define'ами. И еще один плюс к enum - их значения вместе с идентификаторами видят debugger'ы, в отличие от define'ов

Мощная площадка приветствуется, а приклеивать м/сх за брюхо абсолютно бесполезно - у обычных SO8 теплоотвод производится через ноги самой м/сх. Кроме того, если м/сх расчитанна на повышенный теплоотвод, то у нее в DataSheet'е обычно пишут сколько она может рассеять при ее монтаже на определенную площадку (обычно 1 кв. дюйм), и иногда пишут через какие именно ноги она будет рассеивать тепло.

Все просто, функции XSpi_* хотят УКАЗАТЕЛЬ на ЭКЗЕМПЛЯР структуры XSpi, если вы создаете только указатель (XSpi* InstancePtr), то функции получают указатель, указывающий неизвестно куда (точнее указывающий на 0 адрес), поэтому вы должны создать ЭКЗЕМПЛЯР структуры (XSpi My_SPI) и передать УКАЗАТЕЛЬ на него в функции работы с SPI. Оператор '&' берет адрес от переменной (того самого ЭКЗЕМПЛЯРА структуры), который как раз и является УКАЗАТЕЛЕМ, с которым хотят работать XSpi_* функции. Что касается совета CodeWarrior1241 использовать меньше глобальных переменных, то тут он прав, а что касается идеи передавать MySpi по ЗНАЧЕНИЮ в функцию InitSPI - то тут он не прав, такая передача во первых сожрет дополнительную память (на копию структуры параметра), а во вторых не позволит работать с ней за пределами InitSPI, так как вся инициализация этой структуры останется в локальной копии - параметре и не попадет в место вызова InitSPI. В данном случае нужно или передавать указатель, объявив экземпляр структуры в месте вызова InitSPI, либо сделать эту переменную локальной в самой функции InitSPI не передавая вообще ничего (но в таком случае ВСЯ работа с MySpi должна содержаться ВНУТРИ InitSPI)

С этого и надо было начинать :) У Вас направильно определен этот самый InstancePtr, надо делать так: XSpi MY_Spi; void InitSPI (void) { XSpi_Initialize(&MY_Spi,XPAR_OPB_SPI_0_DEVICE_ID); XSpi_Start(&MY_Spi); ... }

Мне удалось объяснить Specter'е что я хотел изменив строку (rule (tjunction on)) на (rule (tjunction off)(junction_type supply_only)) Результат поразительный - когда Spectr'а трассировала эти цепи как сигнальные было лучше :( Видимо все таки придется разводить их вручную :(

Если верить хелпу по командам do файла, то assign_supply описывает ИСТОЧНИК питания, т.е. пин, к оторому надо подсоединить все остальные (насколько я понял) Очень не хочется - там стоит 208ми ногий PQFP c весьма мелким шагом (0.6), и если ему подвести вручную все питающие пины, то у Spectr'ы будут проблемы с разводкой всех остальных пинов :(

Конкретно с CAM350 не работал, так что процесс расписать не могу :( Кстати сам Gerber весьма близок к G-code (G-code - RS274D, Gerber - RS247X), так что подойдет и что нибудь попроще CAM350

Пока руками один раз. Текст выглядел приблизительно так: (net +12V_ISO (pins X4-8 X12-13 D3-7 D3-5 D3-3 D3-1 X2-14 X2-13 X11-2 D14-3 D14-1 X3-14 X22-2 X25-2 D4-7 D4-5 D4-3 D4-1 D5-7 D5-5 D5-3 D5-1 X5-8 X18-2 X15-2 X21-2 X20-2 X23-2 X24-2 C73-1 X19-2 X14-2 X17-2 X16-2) (rule (tjunction on)) (supply power) ) (Добавленное мной выделенно) В do файле прописано assign_supply +12V_ISO (pin X2-14) Для остальных цепей аналогично (для земляных вместо supply power было написано supply ground)

Станки обычно работают с G-code (оно же RS274D), точнее с ним работают программы, которые управляют этими станками. Программ этих довольно много (Mach3, emc2 и куча других - искать по ключевому слову CNC), управляют они обычно шаговыми двигателями (интерфейс step/dir) или серво приводами. Что касается PCAD'а, то из него надо получать gerber формат, который потом надо пропустить через какой нибудь CAM (типа CAM350), на выходе будет тот самый G-code

Кнопок и батареек там нет, а есть там кучка разных питаний (+15,+3.3,-3.3) с общей землей (GND) и еще 2 гальванически развязанных питания, каждое с собственной землей. И я пытаюсь объяснить Spectr'е, что весь этот зоопарк надо трассировать в режиме power trank, не получается :( Соотвествующий атрибут на цепи я руками прописал в dsn файл, и оно вроде даже поняло, но результат как то не очень изменился :(

И GND там тоже есть (и другие есть) Не нашел я там такого атрибута :(

Я бы не обращал, но он их ТАК разводит, что просто караул :( Именно, причем и команд, что бы их вставить в do файл я тоже не нашел :( Нашел только соотвествующее описание в dsn файле, но править каждый раз его ручками очень не охота :( (Я пробовал, но что-то не срослось, надо разбираться)

Слоев всего 2, так что с плэйн-слоями не судьба :( assign_supply стоит - не помогает :(

Господа, как объяснить PCAD'у (что бы он потом объяснил Spectre) что некоторые цепи являются цепями питания (и земли)? А то Spectra сначала выдает предупреждение, что у сигнальной цепи GND слишком много pin'ов и что это наверное не сигнальная цепь (в чем она совершенно права), а потом пытается ее развести (как сигнальную) - результат мне будет снится по ночам в кошмарах :( Соотвествующей ручки у PCAD'а не нашел :( (Наверно плохо искал)

Посмотрите в сторону MAX6816, MAX6817, MAX6818 (подавители дребезга кнопок на 1/2/8 каналов) (Цена правда может не понравится :) ) Но, как тут уже правильно заметили, при наличии в схеме Alter'ы можно обойтись и ей одной.

Лучше конечно совсем без входного мостика (как Вы и предлагали), в таком случае в потери будут на 2х ключах (1 ключ PWM и 2й ключ вместо входного диода, так как просто запереть PWM ключ на время 'неправильной' полуволны входного напряжения не получится из за встроенного диода) А с мостиком потери будут на 3х ключах. С другой стороны проблем управления таким монстром будет на порядок больше из за массы ключей без общего провода управления, причем половина из них должны будут управлятся низкочастотными сигналами (100Hz), так что трансформаторы в затворы не пройдут :( Угу $5 (смотрел на сайте TI), а здесь все $10 (смотрел на einfo) Но всеравно это меньше чем контролер PFC (с ZVT) и PWM (ZVT/Phase shifted control) Мне видится что управление лучше сделать на драйверах полумоста (типа IRS2184), это сильно сократит число необходимых изолированных напряжений и позволит избавится от оптопар. Вот только для 50Hz управления ему понадобятся нехилые конденсаторы в bootstrap :( Слишком много :( Совершенно точно все не влезут. Кроме того, действительно хотелось бы сделать все остальные каналы на TOPе, тогда основной канал можно будет заглушить при отсуствии нагрузки на нем (остальные при этом должны работать)

У AD есть целый выводок м/сх специально для этих целей, см Power Supply Sequencers или Power Supply Sequencing Bulletin

Про тепловые трубки я как бы в курсе, есть только одна проблема - достать цистерну трансформаторного масла будет гораздо проще, чем тепловые трубки в мелкооптовом количестве :( PS. Покупать Thermaltake'овские радиаторы и пускать их на трубки не предлагать :) На TMS320 тоже может, мне уже предлагали :) Еще можно Pentium Dual Core поставить - по одному Core на PFC и выходной PWM :)

Материал собственно корпуса может быть любым - например пластмасса или алюминий (первый вариант предпочтительней, т.к. дешевле, но возможен и второй вариант - если это поможет решить проблему охлаждения) Внутренний объем около 3л (или более). Пока у меня есть только макет собственно прибора (его объем раза в 4 больше, я надеюсь, что окончательный вариант можно будет сделать покомпактнее) Это мысль! Только есть одно 'но' - там довольно много разъемов :( Придется их как то герметизировать.

Если под 'другими программами' понимаются программы под Windows, то они это делают через соотвествующий системный драйвер. Этот драйвер, прежде чем лезть в регистры порта, должен открыть системный драйвер соотвествующего LPT порта (куда он собирается лезть) и запросить у него экслюзивный доступ к порту. При этом Windows блокирует доступ к порту со стороны всех остальных программ (включая ее саму) Пример куска драйвера в присоедененном файле

Ага, теперь понял. Я смотрел на изолированные понижающие PFC, но то, что я видел было сделано на базе flyback преобразователя, а он на 500W не потянет. А на forward converter скорее всего не найдется готовых м/сх управления Можно сделать SEPIC или Cuk конвертор Посмотрел на TMS - по моему это черезчур для данного проекта, я все таки хочу нестандартный БП на максимально стандартных микросхемах. БП с применением DSP - это уже на класс выше, чем надо :( Для начала хочется определиться с требуемым КПД, никто случайно не знает кокого либо пакета для термального моделирования?

Не понял, с мостиком все понятно, а куда денутся потери от PFC?

Это собственно первый вопрос - я не очень представляю сколько тепла можно рассеять из закрытого ящика через радиатор без принудительного охлаждения. Желательно, что бы при этом внутренности ящика не сварились :) На PFC будет весьма порядочно :( Для этого надо взять ключи получше (с меньшим Rds и Qg), а для этого надо выбрать топологию, которая позволит взять Vds поменьше, например phase shifted мост (IMHO у форварда с active clump Vds будет в 2 раза больше) Я думал уже в этом направлении, даже нашел топологию PFC без моста на входе, но у него потери в ключе оказались больше, чем в исходном мосте :( Я хотел их использовать в основном для снижения динамических потерь в ключах, почему то мне кажется, что они будут ощутимые (надо посчитать) Это да, что есть то есть. Надо посчитать и сравнить потери в альтернативных топологиях, осталось только определиться со списком этих самых альтернативных топологий :) И очень 'неплохая' избыточность по стоимости :( Можно рассмотреть как крайний вариант :)

По 100В каналу требования не критичны, вполне устроят 5% стабильности (по всем напрявлениям), и пульсации до 1V p-p. (Эти требования можно еще ослабить, но тогда придется пересмотреть остальную часть схемы) Что касается остальных каналов, то там вообще что получится :) Допустимо до 10% и более стабильности, пульсации правда желательно иметь поменьше, по крайней мере до 0.1V p-p по 15В каналу, остальные как получится.