[andreichk 0]

Привет Народ!

Получил сегодня задание сделать клавиатуру на 16 кнопок на ПЛИСине от XILINX.

На входе должно быть 16 кнопок, на выходах, которых два ,должно быть-

на одном- меандр, на втором два байта от 1 до 16 в зависимости от нажатой кнопки в течении активной части меандра.

На рисунке для ясности приведён пример , когда одновременно нажаты клавишы: 2,5,12,16.

Оба выхода должны будут опрашиваться ПИК процессором, в котором они описаны следующим образом

 

коды кнопок

#define Key1    0b0000000000000001//0x0001//1
#define Key2    0b0000000000000010//0x0002//2
#define Key3    0b0000000000000100//0x0004//4
#define Key4    0b0000000000001000//0x0008//8
#define Key5    0b0000000000010000//0x0010//16
#define Key6    0b0000000000100000//0x0020//32
#define Key7    0b0000000001000000//0x0040//64
#define Key8    0b0000000010000000//0x0080//128
#define Key9    0b0000000100000000//0x0100//256
#define Key10   0b0000001000000000//0x0200//512
#define Key11   0b0000010000000000//0x0400//1024
#define Key12   0b0000100000000000//0x0800//2048
#define Key13   0b0001000000000000//0x1000//4096
#define Key14   0b0010000000000000//0x2000//8192
#define Key15   0b0100000000000000//0x4000//16384
#define Key16   0b1000000000000000//0x8000//32768

 

и

 

#ifndef TASTE_EN

#define TASTE_EN PIN_A5//Признак опроса кнопок

#endif

ПЛИСку умею програмировать пока только в графическом режиме.Подскажите,плиз, с какого боку подходить к решению данной задачи.Заранее спасибо :beer:

[chds 0]

Могу предложить решение на VHDL

Ну для начала нужно определиться с частотой опроса клавиатуры. Сформировать такой сигнал можно на обычном делителе зависит от внутренней частоты в ПЛИС:

signal cnt : std_logic_vector(20 downto 0);
signal scan_keyboard : std_logic;
cnt : process (clk)
begin
   if (clk=1 and clk'event) then
       cnt <= cnt+1;
   end if;
end process;

scan_keyboard <= cnt(20);

 

тут входной clk поделили на 2^20

 

а потом запускаться от сигнала scan_keyboard и считывать состояние со входных пинов к которым подключены кнопки:

если в entity объявлен сигнал типа:

 key : in std_logic_vector(16 downto 1);

то выполняем что то типа:

scan : process (scan_keyboard)
begin
   if (scan_keyboard=1 and scan_keyboard'event) then
       send_scaned_key <= key;
   end if;
end process;

Дальше останется только выдать параллельный код send_scaned_key последовательно, можно так же самостоятельно написать на VHDL процесс, а можно запортмапить сдвиговый регистр, в библиотеке у Xilinx их предостаточно.

Ну конечно возможны модификации, типа: слать когда нажимают кнопки, но это потребует незначительной модификации кода.

 

 

 

 

Настрочил, а потом прочитал:

ПЛИСку умею програмировать пока только в графическом режиме.Подскажите,плиз, с какого боку подходить к решению данной задачи.Заранее спасибо

 

Ну тут еще проще, читай мануал.

[rezident 0]

Двух сигналов для синхронного интерфейса маловато. Нужно еще фреймовую синхронизацию ввести. Т.е. сигнал, который будет определять начало слова состояния. Если кнопки у вас не объединены в матрицу, то ничего сложного в схеме нет. Организуйте интерфейс синхронного последовательного канала на 16-и разрядном сдвиговом регистре. А схему устранения дребезга на двух 16-и разрядных параллельных регистрах и логике типа XORа, которые тактируются низкочастотным сигналом с периодом порядка 10мс...100мс. В одном регистре хранится предыдущее состояние в другом состояние, отфильтрованное от дребезга. Если текущее состояние кнопок отличается от предыдущего, то значит идет дребезг контакта и логика не должна "пропускать" сигнал во второй регистр "устойчивого состояния", а запись происходит только в первый регистр. В противном случае текущее состояние записывается в оба регистра.

Ну и по сигналу фреймовой синхронизации информация из регистра "устойчивого состояния" копируется в сдвиговый регистр и выдается наружу синхронно с тактовыми сигналами.

Хотя нафига вам такой геморрой при наличии в системе МК, я не понимаю? :laughing:

[chds 0]

Двух сигналов для синхронного интерфейса маловато

Тут можно поспорить. Link порты у всех DSP могут работать в таком режиме. Передний фронт запрос записи, задний запись и сигнал подтверждения не нужен. Ну и I2C/SPI тоже такие не требовательные.

[andreichk 0]

Скажите, а можно ли каким-то образом обьеденить уже нарисованный кусок программы с тем, что вы предлагаете на VHDL ?

Спрашиваю потому, что в ПЛИСке уже имеется код сделанный в графике, но к нему нужно ещё вот это прилепить(кажется два раза одно и тоже написал)

Ну или как можно этот код в графику перерисовать?

[chds 0]

Ну с начала нужно поведать где и чем вы творите.

Если в ISE с полной лицензией, то объединять VHDL и Schematic никаких проблем нет. Либо в VHDL блок Схематика вставляете через port map или в схематик вставляется блок VHDL и дальше работается как с графическим элементом.

[andreichk 0]

Хотя нафига вам такой геморрой при наличии в системе МК, я не понимаю? :laughing:

дело в том, что этот самый геморрой уже распаян на двухсторонней плате и от него никуда не денешься. да и порты в ПИКе уже все растасканы по заданиям и для клавы осталось только два.

И ещё сенсей мне прерывание под это дело написал и сказал, что сделает мне харакири, если я его не использую.

 

Ну с начала нужно поведать где и чем вы творите.

Если в ISE с полной лицензией, то объединять VHDL и Schematic никаких проблем нет. Либо в VHDL блок Схематика вставляете через port map или в схематик вставляется блок VHDL и дальше работается как с графическим элементом.

точно в нём, только насчёт лицензии не уверен.Качал его с ихнего сайта где-то 1.7Га

[chds 0]

Ну это станет понятно в процессе.

Я так понимаю, если новичок, то проще всего объединять в схематике.

Для этого создаем новый проект, делаем верхним уровнем схематик. Дальше, что можем рисуем, что не можем делаем визардом (Tools->Symbol Wizard) нужный нам символ и заполняем его кодом.

[andreichk 0]

а мне вот такой вариант предложили

[rezident 0]

Тут можно поспорить. Link порты у всех DSP могут работать в таком режиме. Передний фронт запрос записи, задний запись и сигнал подтверждения не нужен. Ну и I2C/SPI тоже такие не требовательные.

Что-то вы меня не поняли. Я про фреймовую синхронизацию, а вы о чем? Возьмите у SPI только два сигнала: SCLK и MOSI. А теперь скажите где у битовой последовательности начало и где конец? ;) I2C это другая песня. Её пока исполнять не будем. :)

а мне вот такой вариант предложили

И как он по-вашему должен работать? Ну считает счетчик, ну имеется сигнал окончания счета, а дальше что? Откуда и как приемник узнает какой именно вход подключен к выходу мультиплексора в данный конкретный момент времени? Для этого приемник должен сам генерить тактовые импульсы для счетчика или синхронизироваться этим же сигналом. Т.е. все равно к трем сигналам приходим:

- тактовые импульсы,

- последовательные синхронные данные,

- сигнал фреймовой синхронизации, который указывает на начало и/или конец фрейма (кадра передачи).

[andreichk 0]

а мне вот подсказывают, что , так как и ПИК и ПЛИС кормятся от одного кварцгенератора, то и никакая синхронизация не нужна

[rezident 0]

а мне вот подсказывают, что , так как и ПИК и ПЛИС кормятся от одного кварцгенератора, то и никакая синхронизация не нужна

Ну не нужна так не нужна. Чего же эти "подсказчики" до кучи вам не нарисуют рабочую схему и не объяснят как же она работает7 ;)

[TomaT 0]

а мне вот подсказывают, что , так как и ПИК и ПЛИС кормятся от одного кварцгенератора, то и никакая синхронизация не нужна

 

Теоретически! Возожно, но про прерывания на момент обмена, можно забыть... В ПИКах я не спец.

Вообще, то говоря, можно и одной ногой обойтись... :) Но, как я понимаю не на данном этапе...

 

З.Ы. Если есть только две свободные ноги, то тут, проще всего, (если в одну сторону передача) реализовать синхронный последовальный интерфейс, хотя если все этодело от одного каварца кормиться, то в одну сторону одного провода хватит, UART...

 

З.Ы.Ы. Вернее, ето будет "Synchronus Transmitter" :), но копать все равно в сторону USART!

[rimpocha 0]

А дребезг контактов вы подавляете как?

[chds 0]

Что-то вы меня не поняли. Я про фреймовую синхронизацию, а вы о чем?

Я имел в виду вот такой способ передачи: