Я плакаль.... Нет, я все понимаю, но тогда уж надо честно уточнять, что и как.

Еще как выбивают. Я уже больше десятка раз ремонтировал частотники с убитыми IGBT-шками. И не помогли ни аппаратные ШИМы (стояли спец. кристаллы (от Мицубиси и др.)), ни наличие защиты от перегрузок и перенапряжений, ни плавный запуск.

Ну а мой личный опыт работы с силовыми ключами озвучен выше....

Еще раз - от аппаратных проблем ничто не спасет. Речь о том, что ПЛИС не создают проблем с некорректной программой, которые сплошь и рядом попадаются на МК, когда программист бьет себя в грудь и клянется, что все написано правильно, а потом объясняет, почему его программа дала реверс без плавного останова. В программе всегда можно залезть непосредственно в порт, или при отладке отключить какие-то алгоритмы (и потом удивляться, почему комплект ключей опять выбит). Аппаратный модуль ШИМ, настроенный конкретно под данные условия, не будет источником аварии сам по себе.

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

Вот и я о том же .

В этом случае обычно помогает многоканальный запоминающий осцилопер. Или, для экономных, "виртуальный осцилопер" .
ЗЫ. Самоуверенность это конечно хорошо, но только до тех пор пока она не начинает мешать...

Ну что еще можно сказать если программист сам себе злобный буратина...

Во, точно! Совсем забыл! Вот как раз watchdog на каждом канале и стоял в одном из ПЛИСовых проектов.


Помогает. Как способ мужественно преодолеть самим же и поставленные трудности. Ну или, в случае МК, когда способа решить проблему кардинально попросту нет.

Да, вот он такой. Расстрелять его? Или выдать железо, которое к его буратинству относится наплевательски?

Странный интерес. Сконструировать 4004 на дискретных транзисторах тоже, конечно, интересно, но это совсем другая задача.



Вы, конечно, извините, но мне почему-то кажется, что Вы не умеете использовать эти самые существующие компиляторы. У меня "почему-то" получается порядка 90-120% по скорости и весьма соизмеримо по объёму (в проектах от ~3кб объёмом). Парочку плохоложащихся на си случаев я знаю, но сильно сомневаюсь, что вы сможете их назвать.


Плата с ФПГА уже есть, программируется 'за пять минут'. А пару десятков АВРок еще надо распаять и зашить каждого отдельно.
микроблейз-си и пикоблейз-ассемблнр тоже есть, пикоблейз вполне аналог для аврок, но быстрее раз в 20.



А сама картинка откуда берется и как поступает в АВРки?
С второй мыслёй полностью согласен, но занафига тогда стадо АВРок распаивать?



пробовал разные варианты. вариант с массивом из 256 масок оказался оптимальным по джиттеру (ровно ноль), но при этом не хватало _аппаратных_ буферов УАРТа при скорости больше чем 19200. На спартане же этой проблемы нет как класса, ибо ШИМы там получаются аппаратными.



Рассмотрим худший случай. На одном порту надо ждать 127 единиц, на втором 128.
Где гарантии что между этими двумя моментами-прерываниями мы успеем принять байт из компорта?



А лимиты в каком виде хранить? массив из 16000 отсчетов в память не влезет.



То есть, на 32 двигателя надо ставить 32 АВРки? спасибо, неинтересно.



После чего надо РУКАМИ посмотреть номер текущего канала, прочитать маски портов, изменить маски портов, вывести байты в порты, рассчитать следующий момент. А вне прерываний надо предрассчитать все эти маски.



Всё прекрасно, пока на одной МЕГе делаем не больше ШИМов, чем иу нее их есть аппаратно. Получаем 32 корпуса на ШИМы, еще корпус-два на АЦПшки, пару мег на цифровой ввод, пару-пятерку мег на управление.. А смысл всего этого при наличии уже купленного спартана? Вы хоть примерно представляете что именно можно эффективно и комфортно сделать на спартане без большого количества тех действий, которые некоторые грубые люди называют 'пикоманством'?

<b>ps: с флеймом "pic VS spartan" я по возможности завязываю. Но по остальным вопросам, касающимся спартана, готов общаться.
1) 16 битных ядер 'под ключ' (то есть, с ассемблером, сями и прочими атрибутами) для спартанов не бывает?
2) Поигрался с пикоблейз. Есть у меня весьма обоснованные подозрения, что мне его хватит, при условии реализации всей переферии внутре спартана, но п1 таки интересен и актуален.
3) Никак не ожидал, что поднимется такой флейм, причем настолько далеко от начального вопроса про 16битные ядра для ПЛИС.
4) вопрос, скорее всего, к Хищнику: а если грубой силой нарастить разрядность пикоблейза до 16бит, по сути добавив одну команду 'загрузить 8бит константу во временный регистр', то это будет совсем порнография, или вполне сносное решение? Расширять шину команд до 18*1.5 или 18*2 бит - это как-то расточительно..
</b>

Видимо, opencores... Xilinx сделал 8 бит (потому что мало места надо и быстрый) и 32 (потому что gcc).

На пикоблейз есть достаточно много reference design-ов, периферия, несложное управление и т.п. 8-разрядность ядра при возможности подключать программируемую периферию на деле не так уж страшна - можно, например, повесить сопроцессор на 16 бит к пикоблейзу, или загружать данные в 16-разрядные регистры частями.

Вполне сносное, у меня есть стековое ядро, которое 16 бит подобным же образом расширяет до 32. Довольно компактный код получается в итоге.

Поможет, но не сильно. Это еще больше в конечном итоге усилит его расхлябанность и надежду на то, что "и так сойдет".
ЗЫ. Воспитывать надо причем фактами (для чего и нужен запоминающий осцилопер - тыкать носом).

Цель проекта - не воспитать отдельно взятого программиста. Есть задачи и поважнее, чем обеспечение корректной работы силовой электроники в каждом отдельно взятом случае и при всех комбинациях состояний МК (включая непрошитое, технологические и отладочные прошивки, а также зависания в других местах, которые негативно сказываются на ШИМе). Да, я могу посидеть с листом бумажки и разрисовать на нем возможные состояния, а также убедиться в их корректности. Но оно мне надо? Мне достаточно дорого мое рабочее время, чтобы заниматься решением рутинных задач "еще и на этом контроллере и еще и в таком режиме". При наличии AVR (или сильной приверженности к ним) - да, это один из обходных путей... еще и обосновать, какой воспитательный эффект он окажет (а пудовая мышка на радиолампах развивает мускулатуру). Но при наличии квалифицированного программиста дать ему вменяемую и надежную периферию - элементарная вежливость (а также признание квалификации и ненавязчивое предложение сконцентрировать усилия на решении более сложных проблем).

Чего "ЖДАТЬ"? Процессор СВОБОДЕН. Два из 3-х прерываний длятся меньше 1мкс каждое. Третье прерывани (раз в 2,5мс) слегка дольше - в зависимости от реализации порядка сотни мкс (1600 команд тебе на решение, а какой-же следующий канал и на сколько включать, хватит ? ). Т.е. свободно более 95% процессорного времени!

Это была шутка? Или Си окончательно отбило способность решать задачи просто?

А теперь попробуй выкинуть из всего перечисленного все лишнее. Результат у тебя должен выполняться менее чем за 100-200 тактов и не выходить за пределы прерывания. Вне прерывания считается только необходимое время для каждого канала. Т.е. те же данные, что и для аппаратных ШИМов.

Ну что можно тут сказать... Разве, что вспомнить что Вы избалованы Си.
Смысл прост - при Ваших подходах Вам и десятка спартанов не хватит...

Я ОЧЕНЬ хорощо представляю что можно засунуть в ПЛИС. ШИМы Вы туда точно засунете, мелкую логику (фарами аппаратно помигать) то-же, и ядро (хотя может в погоне за супер подходящим до этого не дойдет) т.к. оно уже есть готовое, а вот дальше... В общем до обработки изображения дело вряд-ли дойдет...

Перенесено в топик Робот в FPGA
http://fforum.winglion.ru/viewtopic.php?p=11067#11067

Вот это и называется пикоманством. Еще я должен считать, сколько там микросекунд, сколько это команд, и хватит ли мне этих команд.

Ой, а что там дальше? А то я не ОЧЕНЬ хорошо представляю, что можно засунуть в ПЛИС...

микроблейз-си и пикоблейз-ассемблнр тоже есть
Значит робот будет делаться на [микроблейз+ микроблейз-си] и [n штук пикоблейз+пикоблейз-ассемблер] или даже скорее всего без и, так как на ассемблере много писать тоскливо.
- тоды вперед и с песней, а то тут некоторые про оригинальные архитектуры под задачу говорили, хотя сразу было все понятно.

Нет, не ты. Это должен посчитать квалифицированный программист ПЕРЕД тем как браться за написание кода. Тогда и не будет всех тех казусов которые ты описывал выше.
По сути это входит в оценку выбора кристалла. Когда решаешь хватит ли ресурсов 1-5$ AVR-ки или надо брать 12-80$ ПЛИС...