EPM240 кучка енкодеров, кнопок и новичек., подключение енкодеров Опции

[light_junior]

Добрый день всем форумчанам.

Я, будем откровенны, совершенный новичек в ПЛИС, до этого работал только с МК ARM, поэтому прошу небольшой помощи или советов по вопросу:
Нужно с помощью cpld работать с приличным количеством энкодеров, в данный момент 8, после достижения первичной цели будет в районе 30-36, далее информация должна будет передаваться на МК, по SPI-slave интерфейсу
Пока только организовал саму схему работы с одним инкрементальным энкодером, получаю такты енкодера, и направление 0(по часам)/1(против), и задумался как грамотно обрабатывать все в куче. Задача состоит в том, что в SPI данные должны приходить только по требованию (в момент когда только какой либо енкодер активный), и оттуда их потом будет забирать мастер-SPI МК. Вот некоторая дополнительная информация:
- энкодеры являют обычными поворотными, и важно знать не угол вращение, а инкрементальную часть, то есть повернули на 4 такта скажем (суммарных тактов), соответственно должно быть 4 пакета с данными {номер енкодера, дикремент, инкремент}
- энкодеры вращаются независимо, то есть может один/два, могут с одинаковым фронтом (чисто теоретически, но все же).
- помимо енкодеров, есть еще много кнопок, их тоже необходимо опрашивать независимо (матричная схема включения не подходит), то есть информация так же должна уходить в SPI - как разрешать тогда проблему приходжения данных в SPI от двух источников? буфер? FIFO на тригерах?
- желательно что бы все это добро поместилось в EPM240.

Буду благодарен за любую помощь

[light_junior]

Я честно говоря не очень понимаю, какую помощь хочет получить ТС.
Судя по прочитанному, проект несложный, я такие еще на MAX3000 делал .
Но за ТСа его никто здесь не разработает.
Можно отвечать на конкретные вопросы, но их должно быть ограниченное количество, а то пока что глаза разбегаются .
Влезет или не влезет 240 - ну это вообще вопрос 20й. Если не влезет, то впаять в те же ноги микросхему большего размера. Если на это денег нет - ну, думать, как утрамбовать.

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

Если максимальная частота ниже примерно 10000 четвёртых цикла в секунду, то 32 энкодера можно и на микроконтроллере обсчитать с антидребезгом, если выше - можно использовать Lattice MachXO на 1200LE, туда точно всё влезет.

Энкодеры поворотные, по примеру вот таких
Да, Вы правы, можно на МК обрабатывать так и делал ранее, но я хочу вынести всю подключаемую "периферию" на ПЛИС, а МК использовать только как декодер команд. Таким образом поддерживается модульность всего устройства, и обеспечена масштабируемость, для достижения большего количества периферии достаточно будет использовать ПЛИС с большим количеством выводов.
До этого, рассматривал вариант, для кнопок и светодиодов, сдвиговые регистры 74CH, но отказался по причине наращивания корпусов, слишком много выходит, есть правда еще аналоговая часть для МК, но там без мультиплексоров не обойтись.

[iosifk]

Вопрос был по сути один - каким образом достигнуть согласования нескольких источников сигнала, для передачи на один выход, в данном случае последовательный интерфейс SPI, ключевое слово "концепция", "архитектура",

Могу рассказать, как это делается.
По скайпу голосом...

[x736C]

Могу рассказать, как это делается.
По скайпу голосом...

Здравствуйте, Иосиф!
Присутствующим на форуме тоже было бы полезно узнать. Многие ценные советы, попадая в архив форума, позже становятся востребованными, когда люди ищут решение своей аналогичной проблемы.
Призываю Вас не уводить вопрошающих в частное пространство, а поделиться со всеми своим опытом.

[iosifk]

Здравствуйте, Иосиф!
Присутствующим на форуме тоже было бы полезно узнать. Многие ценные советы, попадая в архив форума, позже становятся востребованными, когда люди ищут решение своей аналогичной проблемы.
Призываю Вас не уводить вопрошающих в частное пространство, а поделиться со всеми своим опытом.

Как на это ответить?
Я же не против того, чтобы форум все читали. И я никогда не отказывался от консультаций.
А сейчас самое удивительное. За 7 лет работы в техподдержке я могу дать точную статистику. Более половины тех, кто задает вопрос не могут правильно его сформулировать. И не только потому, что не владеют русским языком, таких тоже много, но в основном потому, что не могут сформулировать основную задачу. Ну это как яхта, когда идет против ветра. Непосредственно против ветра идти невозможно, поэтому яхте приходится идти галсами, т.е. зигзагами и я бы назвал это текущий курс. А то, куда вообще идет яхта - это генеральный курс.
Так вот, возвращаясь к ТС. Все его кнопки и энкодеры - это как раз вопрос о "текущем курсе", потому как на самом деле не важно будут ли это кнопки или что-то другое. "Генеральный курс" - это вопрос о том, как из ПЛИС передать/получить данные в микроконтроллер или в хост.
Недавно для Jenya7 я писал о том, как вообще это делается.
1. Пишем ТЗ и рисуем алгоритм вычислений
2. По алгоритму вычислений считаем требуемую производительность узлов, таких как память, регистры и т.д. Все что можно переводим на уменьшенную разрядность.
3. После этого рисуем блок-схему вычислителя. Ибо одно и тоже можно сделать разными способами и ресурсов потратить по-разному...
4. Вычислитель разбиваем на "кирпичи" и пытаемся их унифицировать при помощи параметров.
5. Определившись с "кирпичем" смотрим, что туда надо впихнуть для удобства отладки в симуляторе и что - в железе. Соответственно получаем параметры для "дебаг-релиз"...

Если есть хост, то в п.3 дополнительно определяем тип обмена "поток" или "кадры". В зависимости от железа в стыке с хостом выбираем тип протокола. В данном случае "железо" - это SPI. Далее у ТС будут "кадры". И вот тут его и надо подвергнуть допросу 3-й степени. Скорее всего SPI в микроконтроллере "короткий" и впихнуть туда кадр с адресной частью будет сложно. Ну и мк стандартный, и скажем передавать например 8 каналов данных одновременно под клок мк. не сможет. хотя это и не факт, т.к. SPI можно сделать программный и данные читать-писать байтами... Но, возмодно выделить несколько линий порта под выбор адреса регистра в ПЛИС. Например 4 линии - выбирают 16 регистров по записи и 16 по чтению... Но можно сделать только 1 линию, и ее использовать для косвенной адресации регистра. Так что варианты есть...
По поводу фильтрации приходящих данных - здесь тоже показания получаются только после интенсивного допроса ...

Вот план парт-хоз актива для промывки мозгов. Кто хочет подробнее - могу рассказать.