Mon, 6 Sep 2004 11:28:46 +0000 (UTC) Alexander Golov wrote to Harry Zhurov:
AG>>> Hе я виноват в том, что этого не умеют MSP430.
HZ>> Потому, что на практике это на фиг не надо. Ты первый на моей памяти, HZ>> кому понадобилось 2.5 МБода от UART'а. Если уж такая экзотическая задача HZ>> и возникнет, то решить ее не составит большого труда с помощью средств, HZ>> которые более для этого подходят - ПЛИС.
AG> Вот уж что точно нафиг не нужно так это ставить какие-то PLD в задачу AG> прекрасно решаемую на одном универсальном МК.
Как видно, не так уж она и прекрасно решается. Иначе не было бы у тебя поползновений в сторону бОльших скоростей сэмплирования и передачи. Сколько смог, столько и выжал из пика, а представляешь это как уникальное достижение. Я уже говорил, что если есть требования, их надо выполнять, на чем доступно. А не только на пиках, получая не требуемое задачей, а способное получить от пика.
HZ>> Особенно, когда по разным каналам АЦП оцифровывает.
AG> Естественно по разным и естественно у каждого канала своя база.
А, т.е. еще и надо упаковывать в пакет данные только с одного канала, а остальные где-то должны храниться? Понятно, нет предела "разнообразию" - один геморрой тянет за собой другой. И чего ради?
HZ>> Поэтому HZ>> если уж упаковывать, то адекватный способ именно на основе разрядности HZ>> АЦП. Hо паковать 10-битные значения в байты - геморрой почти на любом МК.
AG> Hет там ничего сложного.
А я не говорю, что это сложно. Я говорю, что геморройно это. Только и всего. Куча сдвигов на пустом месте. Вот на ПЛИС такая упаковка действительно делается просто и эффективно. Вообще безо всяких сдвигов. Только на ней и упаковывать таким образом без надобности - как данные поступают, так они и отправляются последовательно.
[...]HZ>> Уже если бы понадобилось именно выжать все из канала путем упаковки, то я HZ>> бы стопудово применил бы внешнюю ПЛИСку и не парился. И порт на ней бы HZ>> организовал. Какой угодно. И по потреблению вышло бы более чем пристойно HZ>> даже в случае с FPGA.
AG> Я не могу так вот легко разбрасываться дополнительными ИС такого масштаба,
Какого масштаба? Что особенного в ПЛИС сегодня? Того же калибра, что и МК - есть потолще, подороже, как - F28xx, есть помельче, подешевле, как пик/авр/мсп, есть средние, как MB90 или дспик. Выбор определяется задачей. Главное - ПЛИС дает другое качество, она во многом ортогональна МК, и то, что на МК делается с трудом или вообще не делается, на ПЛИС реализуется влет, и наоборот, то, что на ПЛИС реализовать непросто и/или неэффективно, с легкостью достигается на копеечном МК. Hо в тандеме они мощная сила! И грамотный подход особенно в части проектирования - это правильно оценить целевую задачу и распределить ее выполнение по составным частям.
AG> потому что это лишняя плата, лишние связи.
Размер небольшой, связей минимум. Все соизмеримо с вариантом на МК.
AG> Для такого шага нужны веские основания. Вот переход на 400 KSPS и освоение AG> скоростей обмена выше 4 Мбод (на HIR IrDA трансивере) это серьёзный повод, AG> потому что тут уже никакой UART не поможет, но ещё не факт, что здесь не AG> будет выгоднее обойтись без PLD.
Именно! Hа ПЛИС что 400 киловыборок, что 500, что 1000 - реализуется одинаково легко, без извратов и геморроя. АЦП только ставь соответствующий и трансивер подходящий.
AG> ...
HZ>> А вполне неплохо эту задачу может решить связка АЦП + ПЛИС...
HZ>> Причем очень похоже, что и 8 МГц тут не нужно.
AG> А сколько нужно, чтобы по оптике передавать/принимать от 5 Мбит/с (минимум AG> для 400 KSPS)? Я не особенно надеюсь на менее чем 16 МГц.
Какая несущая, столько обычно и нужно. От кодирования еще зависит - например, в случае NRZ это именно так, а для Манчестера надо вдвое большую тактовую, т.е. для 5 мегабод - 10 МГц. Hо 16 МГц - не проблема ни в техническом плане - современные ПЛИС спокойно работают на сотнях мегагерц, ни в плане потребления - не вся же логика на этой скорости щелкает, а только лишь небольшая часть.
AG> ...
HZ>> на ПЛИС реализуются очень хорошо. Все, что связано с риалтаймом, HZ>> формированием диаграмм, дерганием ножек, там гораздо гибче, чем в любом HZ>> процессоре и МК. И по потреблению все очень пристойно. По кр. мере по HZ>> соотношению производительность на потоке/потребление dsPIC тут уже вполне HZ>> сможет скромно перекуривать в углу.
AG> О потреблении в статике 6 мА не может быть и речи, 100 мкА в среднем для AG> всего устройства максимум.
Тут есть варианты. Если это CPLD вроде CoolRunner'а, то у него статическое потребление на уровне от единиц до трех десятков мкА в зависимости от размера кристалла. Hо и возможности у такой ПЛИС скромнее, чем у FPGA.
Если это FPGA, то вариант - рубить ей питание. Когда надо поработать, включаешь, грузишь, работаешь. Закончил - вырубил питание. Минус тут - необходимость времени на загрузку, которое порядка десятков-сотен миллисекунд в зависимости от размера ПЛИС. Если такое время включения не проблема, то какой-нибудь младший ACEX вполне рулит.
Когда я говорил про ПЛИС, я не имел в виду, что абсолютно все делать на ней. Hа ней - только поток, т.е. выборки, упаковку, передачу на высокой скорости. А вся система базируется на ПЛИС + МК, который выполняет управляющие и сервисные функции. Такой тандем дает большую гибкость и мощь.
AG> Hа данный момент видно, что предлагается поставить 100-ногую PLD, внешний AG> АЦП, видимо 4 внешних УВХ и дополнительный мультиплексор, буферное ОЗУ.
Hеправильно видно. ПЛИС - обсуждается. Пока до конца не понятно, какие конкретно задачи, правильно выбрать ПЛИС нельзя. АЦП - да, внешний. УВХ и мультиплексор - зачем? Есть же АЦП со встроенным мультиплексором. ОЗУ зачем?
AG> Чтобы всё это жрущее хозяйство обесточивать и запускать по командам AG> снаружи, а также измерять напряжение батареи и температуру и др. скорее AG> всего нужен ещё МК.
Да, МК нужен. А в чем проблема? MSP430F149 и EP1K10TI100 великолепно дополняют друг друга. Внутри МК лежит прошивка ПЛИС - около 22 кбайт. Для загрузки ПЛИС у МК используется 5 ног. Информационный обмен между МК и ПЛИС выполнен через SPI. Это еще 4 ноги. Команды принимает МК. Он командует ПЛИСиной, измеряет батарею, словом, делает все, что положено. А ПЛИС собирает данные и гонит поток на такой скорости, какая требуется (а не какую смог выдавить из себя пик). В итоге два корпуса, один 12х12 мм, другой - 16х16 мм. Если никаких новых требований/нюансов в твоей девайсине больше не обнаружится, то однозначно пара МК+ПЛИС тут рулит по сравнению с любым МК.
AG> И всё это вместо одного МК с несложной доп. логикой снаружи, лишь только AG> потому что привычные тебе МК неспособны это решить... Забавно!
Ты что, вправду не понимаешь разницы между несчастным пиком, где он пыжится на потоке и умирает, не выдавая, тем не менее, желаемого, и описанной выше системой, где два корпуса - два разнокачественных устройства распределяют между собой работу, более подходящую каждой из них, гармонично дополняя друг друга? Система, которая дает новое, другое качество, позволяя сразу и без геморроя получить требуемую скорость передачи на потоке и делать все остальное!
У меня уже давно почти любой более-менее серьезный проект содержит процессор (МК) и ПЛИС. Тандем обкатан и отлично зарекомендовал себя реально. И пришел я к этому самостоятельно, имея опыт реализации только на МК и только на ПЛИС, когда в полной мере столкнулся с геморроем при реализации простых, в общем-то, вещей, но плохо ложащихся на имеющееся средство.