observable

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

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

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

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

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