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

[light_junior]

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

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

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

[krux]

имхо
не стоит даже и пытаться запихнуть всё это в EPM240

[light_junior]

имхо
не стоит даже и пытаться запихнуть всё это в EPM240

Ну я вот прикинул в квартусе:
8 енкодеров - 48 елементов, SPI по примеру самой Altera (IP Cores) - 70, неужто не хватит 240?

Сообщение отредактировал light_junior - Feb 16 2017, 19:35

[krux]

Ну я вот прикинул в квартусе:
8 енкодеров - 48 елементов, SPI по примеру самой Altera (IP Cores) - 70, неужто не хватит 240?

1. вы должны сформировать структуру регистров SPI, в которых будет хранится содержимое значений энкодеров. Это по объёму больше, чем сами энкодеры. Схема мультиплексирования их в SPI однозначно сожрёт много места в CPLD.
2. вы упомянули про кнопки. здесь штука какая. а сколько одновременно нажатых кнопок вам надо определять? матричный подход подходит для многих структур, пусть не для всех, но это требование на самом деле достаточно важное. здесь нужно определиться. однозначно и до начала исполнения печатных плат под разводку кнопок.
3. максимальная частота выдачи результатов по SPI. будет зависеть от количества регистров в 1) и в 2). устроит ли?

[iosifk]

Ну я вот прикинул в квартусе:
8 енкодеров - 48 елементов, SPI по примеру самой Altera (IP Cores) - 70, неужто не хватит 240?

На самом деле, кроме самих энкодеров наверняка потребуются входные цифровые фильтры, чтобы убрать дребезг на фронтах энкодеров и кнопок. А он обязательно будет...
Для CPLD проект может не лечь, если не хватит интерконнектов. далеко не всегда можно забить CPLD на 99%.. И более того. Будете делать печать и захотите перенести сигнал на другую ногу. А CPLD скажет, что так не влезет... И тоже самое может быть потом, когда захочется добавить хоть один триггерок. А у Вас - экономия в пару долларов приведет к 3-5 тыс долл потерям по деньгам и к паре месяцев по времени..
Не забудьте про внешний генератор тактовых! Его тоже куда попало не подключишь...

[light_junior]

1. вы должны сформировать структуру регистров SPI, в которых будет хранится содержимое значений энкодеров. Это по объёму больше, чем сами энкодеры. Схема мультиплексирования их в SPI однозначно сожрёт много места в CPLD.
2. вы упомянули про кнопки. здесь штука какая. а сколько одновременно нажатых кнопок вам надо определять? матричный подход подходит для многих структур, пусть не для всех, но это требование на самом деле достаточно важное. здесь нужно определиться. однозначно и до начала исполнения печатных плат под разводку кнопок.
3. максимальная частота выдачи результатов по SPI. будет зависеть от количества регистров в 1) и в 2). устроит ли?

Одновременно нажатых кнопок может быть много, они так же независимые...затрудняюсь как то в цифрах ответить. Будет там конечно и массив кнопок, но я пока его не затрагиваю. Мультиплексирование, если я правильно понял Вашу мысль, мне не подходит, так как случай, с одинаковым фронтом на двух энкодерах, у меня приводит к пропуску одного из них. Делал общее ИЛИ на каждый выходной такт енкодера, и потом к шине данных (та которая направление содержит) по общему ИЛИ применял всю шину такта (она как раз совпадала с номером енкодера)

На самом деле, кроме самих энкодеров наверняка потребуются входные цифровые фильтры, чтобы убрать дребезг на фронтах энкодеров и кнопок. А он обязательно будет...
Для CPLD проект может не лечь, если не хватит интерконнектов. далеко не всегда можно забить CPLD на 99%.. И более того. Будете делать печать и захотите перенести сигнал на другую ногу. А CPLD скажет, что так не влезет... И тоже самое может быть потом, когда захочется добавить хоть один триггерок. А у Вас - экономия в пару долларов приведет к 3-5 тыс долл потерям по деньгам и к паре месяцев по времени..
Не забудьте про внешний генератор тактовых! Его тоже куда попало не подключишь...

В плане кристалла, я вот посмотрел на max v, cyclone, в принципе есть такие же по ножках, правда цена уже повыше, 10уе. Потерь не предвидится, так как это пока некоммерческий проект, больше личный.
Насчет дребезга энкодера, не могу ничего сказать, возможно Вы правы, но на МК у меня достаточно просто выходило с ним работать. Для плис - вот:

Код

module quad (clk, A, B, enc_enable, direction);
input clk, A, B;
output enc_enable, direction;
reg [2:0] A_delayed, B_delayed;
always @(posedge clk) A_delayed <= {A_delayed[1:0], A};
always @(posedge clk) B_delayed <= {B_delayed[1:0], B};
wire enc_enable = A_delayed[1] ^ A_delayed[2] ^ B_delayed[1] ^ B_delayed[2];
wire direction = A_delayed[1] ^ B_delayed[2];
endmodule

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

[Koluchiy]

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

Можно отвечать на конкретные вопросы, но их должно быть ограниченное количество, а то пока что глаза разбегаются .

Влезет или не влезет 240 - ну это вообще вопрос 20й. Если не влезет, то впаять в те же ноги микросхему большего размера. Если на это денег нет - ну, думать, как утрамбовать.

[Timmy]

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

Сообщение отредактировал Timmy - Feb 21 2017, 05:37

[light_junior]

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

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

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

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

[Maverick]

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

Пока на ресурсы не обращайте внимания - главное вначале в Modelsim/questasim получить результат симуляции, максимально приближенное к реальным условиям работы. Это делается с помощью тестбенча.

[iosifk]

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

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

[x736C]

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

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

[Maverick]

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

честно говоря я тоже за...
PS хотя бы видео/звуко запись выкладывать на youtube например, а на форуме давать ссылку. Тем более Вы кажется являетесь модератором ветки "Обучающие видео-материалы и обмен опытом", как раз будете наполнять свою ветку

[iosifk]

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

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

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

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

[krux]

по вопросу кнопок.
уточняюще-наводящий вопрос.
собираетесь ли вы делать управление типа "вверх-вниз-вправо-влево" он же "джойстик" он же "крестик" или как там его ещё?
в этом случае, действительно, требование нескольких одновременно нажатых кнопок является объективным. однако. этот "джойстик" можно вынести на отдельную матрицу 2х2 и обрабатывать все его 4 кнопки одновременно.
при этом другая часть клавиатуры (например 4х4 с цифрами и *-#-ввод-отмена, а-ля "PIN-код банкомата") может обрабатываться второй матрицей, допускающей только одно одновременное нажатие.

[light_junior]

Maverick, Так как информация редкая достаточно, то для энкодеров забирать ее по , так сказать "прерыванию" от самой периферии, то есть при обнаружение высокого уровня на любом из блоков энкодеров, из него нужно забрать значение/уровень линии данных. Прошу прощения, если выражаюсь не совсем корректно. О конечном автомате подумывал, но пока не вижу в нем вариантов из за возможных одновременно пришедших сигналов от блоков, если правильно понимаю, все равно придется идти на уступки, делать какую нить минимальную приоритезацию.
iosifk, спасибо за личное приглашение в скайп, но пока откажусь, так как домашний комп пришел в негодность, а с рабочего как то неудобно в рабочее время. Плюс, мне текстовая информация лучше к усвоению, плюс можно перечитать. В плане общественного развития, можно просто организовать конференцию из желающих в определенное время, и ответить на их сокровенные вопросы.
Благодарю за развернутый ответ по стратегии, более подробно постараюсь вникнуть. Насчет интерфейса, SPI, он был выбран так как имеется аппаратный на борту с размером до 16-ти бит, конечно ничего не мешает организовать свой параллельный "ногодрыг", или что то похожее, просто думал уже привязаться к существующему.
Что касается кадров, обдумывал данный вопрос:
есть 8 независимых каналов, в каждом канале: энкодер, кнопка (которая в торце энкодера), кнопка отдельная, 8+1+1 светодиодов (8 энкодера, 1 кнопка энкодера, 1 кнопка отдельная) исходя из этого вырисовывается два типа кадров:
- длинный {адрес канала [2:0], инкремент_энкодера, дикремент_энкодера, светодиоды[2:0], кнопка, светодиод, кнопка_отдельная, светодиод_отдельный}
- короткий {абсолютный адрес [5:0], значение [2:0]}
абсолютный адрес является порядковым номером элемента, со счетом по движению луча ЭЛТ (слева на право, переход на начало новой строки), где столбцы это каналы, строки - типы элементов.
krux,джойстик пока не планируется, все типы элементов-датчиков описать чуть выше в сообщении.
PS. Как я понимаю вставки ника в сообщение на форуме нет?
PSS. Редактирование сообщений дается на некоторое время?

Сообщение отредактировал light_junior - Feb 21 2017, 20:32