Easyelectronics.ru

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

Выводить собираюсь в ЛСД

Важно.

хорошо. я пошел методом деревенским. просто поставил на каждую ногу пика по кнопке с внутренней подтяжкой к плюсу. вот так вот. у меня у пика много свободных ног и задача это позволяет.

У матричной клавиатуры 4+3 выводов. Что вы там подтягиваете?

В большинстве 16 Пиков есть прерывание по изменению состояния 4 старших разрядов порта В. Оно просто создано для матричной клавиатуры (позволяет избавится от циклического опроса выводов по таймеру и экономит кучу процессорного времени). Конкретно в Вашем пике я такого прерывания не увидел, но есть IOCIE: Interrupt-on-Change Enable bit
1 = Enables the interrupt-on-change
0 = Disables the interrupt-on-change
Посмотрите, может на базе этого прерывания получится сделать что-то подобное.

Прерывания по изменению состояния пинов созданы не для клавиатуры, а для ВЫХОДА ИЗ СЛИПА по подобным событиям. Что касается экономии времени по сравнению с опросом, то сие глупость невероятная. Ибо опрос клавиатуры должен выполняться с периодом не менее, чем время дребезга клавиатуры, то есть примерно раз в 20...30 мс. Обработчик опроса занимает не более пары...тройки десятков машинных циклов, что дает при машинном цикле в 1 мкс (как пример при осцилляторе ПИКа 4 МГц) скважность процесса обработки примерно 1000. То есть он занимает 0,1% машинного времени.
Применение внешних прерываний для обработки кнопок приводит к громоздкому и запутанному алгоритму защиты от дребезга и никакой экономии не дает вообще. Если говорить о теории данного процесса, то кнопки не относятся к периферийному оборудованию реального времени, что делает использование прерываний бессмысленным.

В компилляторах mikroelektronika есть библиотека для работы с клавиатурой, на сайте и в описании выложены примеры, но вот реализована-ли привязка нескольких символов к одной кнопке или нет, не знаю.

Доброго времени суток.

Зачем так КАТЕГОРИЧНО.
Думаю, что прерывание на RB4-RB7 у пиков нужно для отслеживания изменения состояния на этих входах. А то для чего разработчик задействует их - дело личное. Один применяет для матричной клавиатуры 4х4, другой для выхода из слипа, а третий например для опроса квадратурного энкодера (если INT0 и INT1 заняты). Ну и так далее.

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

Что бы подобные вам думать начали.
Сие прерывание не предназначено для обработки дребезга...

Глупости всегда очень личное дело.
И каждый волен их совершать.
Поэтому можно кнопки обрабатывать, даже анализируя датчик температуры на кристалле, а сам корпус МК сделать кнопкой. Но такое решение, несмотря на его реализуемость, чрезвычайно неудобно.
А есть совершенно логичное и стройное решение, когда сам опрос автоматически убирает дребезг, а при необходимости экономить питание, все используемые для опроса входы вызывают таки прерывания по изменению состояния, но с ЕДИНСТВЕННОЙ ЦЕЛЬЮ - выйти из слипа и продолжить ОПРОС.
Квадратурный энкодер у какого нибудь двигателя - это устройство реального времени и опросом его делать некуртуазно - порой вообще требуется аппаратное решение (есть МК со специальным модулем). А вот механический энкодер совершенно отлично обрабатывается как кнопки, но у него дребезг поменьше, однако при медленном вращении пропусков не будет совсем даже при опросе в 20 мс, а при быстром пропуски совершенно незаметны, поскольку человек, вращая энкодер, ориентируется не на угол его поворота, а на показания изменяемой величины.

Не скажите. А если энкодер используется именно для измерения угла поворота а не для, например, регулировки громкости? А мы не замечаем пропуски... )))
Как раз подобный проект предстоит реализовывать в ближайшее время, выписал энкодеры, жду.

Парни, то как Вы высказываете сугубо свое мнение, выглядит не очень красиво. И не делает Вам чести.
Судя по Вашим словам, можно сделать вывод, что в компании Microchip работают одни глупцы с отключенными мозгами.
Почитайте вот эти документы, если конечно знание английского позволяет:

Author: Mark Palmer
Microchip Technology Inc.
AN566.pdf
http://ww1.microchip.com/downloads/en/A ... 00566b.pdf

Author: Stan D’Souza
Microchip Technology Inc
AN552.pdf
http://ww1.microchip.com/downloads/cn/A ... 00552e.pdf

После прочтения рекомендую Вам написать те же высказывания по поводу использования прерываний на RB4-RB7 в службу техподдержки Microchip. Может откроются глаза у буржуйских инженеров.

Можно и из буханки троллейбус сделать, но ведь речь не о том. Вам же говорят: проще без прерываний, с прерываниями алгоритм сложней и кучу глобальных флагов придется ставить.
А вообще, у некоторых МК есть аппаратный интерфейс для таких штук. С настраиваемыми таймаутами.

Так я и не спорю с данным утверждением. Просто прерывание по изменению удобно использовать и для матричной клавиатуры. Заснул, проснулся по прерыванию, задержка в 16мс для борьбы с дребезгом, обработка нажатой кнопки и опять спать.
Да и на счет енкодера, встречал схему с оптическим енкодером в качестве счетчика витков и отслеживанием направления вращения, подключенных к RB4-RB5 (канал А-В). Частота следования импульсов до 10кГц. Все прекрасно работало, никаких сбоев и пропусков импульсов. Контроллер PIC16f873, т.е. явно использовалось данное прерывание, т.к. аппаратной обработки енкодера у него нет. Кто-то скажет глупость ,абсурд и не рационально, а я говорю, что надо уважать чужое мнение и решения, тем более если они абсолютно рабочие.

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

Так это и есть ОПРОС, милчеловек...
Прерывания не определяют кнопку. Прерывания лишь БУДЯТ контроллер. И все. А если учесть, что реальные задачи требуют не только детектирования нажатий, но и более сложные комбинации с удержанием, двойным нажатием и пр., то универсальный подход с опросом и формированием флагов и машины состояний клавиатуры будет гораздо выгодней для любого проекта.

Вы читаете выборочно или как?
Я же написал, что все зависит от задачи. И энкодер, который дребезжит дольше, чем длительность импульсов на его выходах, для выбранного применения НЕ ПРИГОДЕН. В принципе. А если применять прерывания, то может так статься, что ничем другим МК уже заниматься не будет. Ибо дребезг сожрет все время на бесконечные входы в обработчик...