Вид для печати
Не могу восстановить клаву своего второго Поиска. Пробовал контактол эластичный - со временем отваливается. Проблема еще в том, что на шлейфе идущем к разъему дороги закрыты пленкой и приходится рисовать новые дороги просто сверху.
Поэтому подумываю как бы подключить обычную клаву. Наверное придется модифицировать BIOS, или грузить драйвер/резидент после старта DOS. Ни у кого идей нет, как бы попроще реализовать? На чем вообще USB клавы делают для новоделов всяких? Что за контроллер?
Про usb не слышал. У Поиска ведь обычная механическая клавиатура как у Спектрума... Для Спектрумов есть контроллеры, позволяющие подключить IBM клавиатуру вместо механической.
Вот например: http://zx-pk.ru/showthread.php?t=17270
Скажу идею - кидайте тапками :)
У Поиска есть разъём магнитофона, в котором найдутся 3 свободных вывода + есть земля.
У Поиска есть свободные линии портов КР580ИК55.
Добавить на макетке транзистор, для линии данных, защиту от статики на обе линии и
можно сделать PS/2 мышь или клавиатуру.
Я прав, или что-то помешает так сделать?
Как минимум, нужно ведь совместимость с клавой IBM PC обеспечить. Т.е. оно должно в порт 60h писать, в BDA где-то символы храниться должны. Ну и существующий механизм опроса клавы вырубить надо :) Т.е. сделать можно, и может быть даже нужно, но геморройно
Я уже прикинул. Не получается с аппаратной точки зрения.
Если бы частоту обмена только процессор генерил, тогда возможно,
а так, когда клавиатура выдавать стробы будет - не успеет.
А программно, так у нас много чего эмулируется и клавиатура тоже.
Не, ну в принципе, тут имхо два пути:
1) Дополнительный контроллер на шине. Можно на чем угодно, хоть на PIC, хоть на ARM, хоть на 8042 (если разобраться, как оно работает). Она общается с клавой - как только символ поступил - генерируется IRQ, которое обрабатывает резидент или дополнительный BIOS-rom. По IRQ символ забирается из из контроллера.
Минусы - чтение напрямую из портов ввода-вывода (60h чтоле) по прежнему остается в системной плате, проги которые работают напрямую с портами - в пролете. Если сделать дешифрацию портов на контролере, то будет конфликт с системной платой. Плюс в биосе по прежнему сидит подпрограмма сканирования родной клавиатуры, жрущая процессорное время.
Плюсы - не нужно лезть в нутрь Поиска - вставил контроллер и пошел.
2) Подключить клаву к штатному разъему Поиска на материнке. Для этого собрать маленький переходник на микроконтроллере (PIC/Arm).
Плюсы - все проги работают как и раньше, все так же софтово идет опрос клавы. Программная составляющая не меняется.
Минусы - отключается штатная клавиатура. Подпаиваются провода на материнскую плату, дополнительно устанавливается небольшой переходник куда-то в корпус. Так же в корпусе вырезается дырка под провод или под PS/2 разъем (в случае если контроллер держит USB-host, под USB-разъем).
Все-таки думаю, что можно отдельный контроллер клавы сделать, вставляемый в слот расширения. Поиск постоянно (приблиз 18.2 раза в секунду) производит опрос родной матричной клавиатуры. Схематически делается это с помощью программного интервального таймера 8253 (ви53), канал 1 которого формирует меандр ~18.2 Hz. Канал 1 заведен сразу на контроллер прерываний 8259, на запрос прерывания 6 (IRQ 6).
http://habrastorage.org/files/c58/77...c4186f882a.jpg
По высокому уровню контроллер прерываний пытается (в зависимости от текущих приоритетов) передать управление на обработку IRQ 6, то есть int 0eh. В обработчике прерывания int 0eh и производится уже программный опрос ВВ55, который дергает линиями матрицы на клавиатуре и в зависимости от расшифровывает символы. Дальше этот же обработчик запихивает код символа в порт 0x60, или если это дополнительный код, то 0xE0 и вызывает программно int 9h.
Таким образом, нужно перепрограммировать интервальный таймер 8253, чтобы на выходе канала 1 всегда был логический "ноль". Тем самым мы программно выключим аппаратное сканирование родной клавиатуры (перестанет вызываться IRQ6/int 0eh). Осложняет ситуацию наличие постоянного высокого уровня на GATE, поэтому я не знаю как точно это сделать. По быстрым прикидкам - перевести 8253 в режим 0 (прерывание терминального счета), загрузить счетчик, на выходе будет 0, пока счетчик уменьшается, а затем сразу перезагрузить только младший байт счетчика, не давая ему старший байт. По идее счет должен остановится, на выходе OUT должен быть по прежнему низкий уровень. Это можно в протеусе проверить, проверю как-нибудь.
Ну а дальше берем микроконтроллер который может PS/2 парсить, организуем какой-нибудь свой левый порт ввода-вывода, заводим с ножки микроконтроллера сигнал на какой-либо свободный IRQ, например на IRQ7. Микроконтроллер как получил от PS/2 клавиатуры байт - распарсил его и выдал в порт, дернув при этом IRQ 7. Поиск свалился в обработчик прерывания IRQ7, где мы взяли байт из нашего левого порта ввода-вывода и кинули его в порт 0x60h, передали управление int 9h.
Контроллер можно сделать со своим BIOS, а можно просто грузить небольшой резидент. Дополнительный BIOS конечно лучше, так как тогда можно на Поиск верхнюю крышку вообще не надевать - клава всегда работает сразу после старта машины.
Вот такие мысли у меня...
- - - Добавлено - - -
Либо, можно отключать аппаратное сканирование родной клавы через контроллер прерываний 8259 - у него есть Interrupt Mask Register. 8 бит маска, если бит установлен в 0 - прерывание разрешено, если 1 - прерывание запрещено. Таким образом что-то вроде:
должно запретить вызывать IRQ6.Код:in al,21h
or al,64 ; установить шестой бит в единицу
out 21h,al
Можно скомбинировать - а) попытаться все-таки настроить таймер 8253, что бы на OUT1 был всегда ноль б) запретить обслуживать IRQ6 в контроллере прерываний через IMR б) поставить заглушку в обслуживающее прерывание int 0eh (mov al,20h; in 20h,al; iret).
Контроллер PS/2 делают на небольших контроллерах ATMEGA, даже в местных проектах вроде видел.
Другое дело, что PS/2 клавиатура и мышь уже дефицит.
Может имеет смысл, подумать про USB?
Скажем взять контроллер STM32F.
И сделать на нём сразу контроллер клавиатуры и мыши, который возвращает код кнопки и движение мыши.
По тому же таймеру 1, писать в буфер клавиатуры код кнопки и мышиное прерывание INT33 поддержать, напрямую, без COM-порта.
А вот тут вопрос, много свободного места в штатном ПЗУ остаётся?
Ничего там не остается, как правило. Но проблему чуть-чуть смягчает тот факт, что у Поиска есть разводка под вторую микросхему. Да и, если речь идет о контроллере, ничего не мешает туда подсадить ещё одну РФку с расширением BIOS
Речь именно об отдельном контроллере, без модификации самого Поиска.Цитата:
Сообщение от DrPass
Оно конечно да. Но, есть нюансы. Во-первых насчет ps/2 клавиатур - полно их. Вот открываем обычную московскую конторку, фарцующую комповым железом - nix.ru (в Питере, кстати, тоже есть офис) : выбираем клавиатуры с ps/2 интерфейсом, выдает список в наличии около 60 различных видов от простых до геймерских, цена от ~200 руб за "обычные" митсуми до ~10000 руб за супер-навороченные. Пол сотни клав, сейчас, в наличии, в преддверие 2016 года 21 века, с доступностью - "пошел и купил". Так что здесь проблемы не вижу пока острой.Цитата:
Сообщение от Копейкин
По поводу stm32 - да, есть вроде бы модели, которые могут одновременно два OTG (ну чтоб одновременно и мышка и клава). Но:
а) модели с двумя OTG на борту - не бюджетники. Начиная с stm32f4 (Cortex M4) серии вроде - стоят вполне ощутимо.
б) в интернете нет документальных подтверждений, что кто-либо смог запустить одновременно два OTG хоть на каком stm32. На форумах одинокие крики о помощи и тишина в ответ. А это значит, что при разработке нужно будет пройтись по всем возможным граблям и костылям, "от" и "до". Что честно говоря мало прельщает, учитывая довольно-таки примитивную и скучную задачу для контроллера. Не та задача, с которой хочется долго возится.
в) не все однозначно у stm32 с параллельными шинами. Оно конечно можно наверное и через LCD-интерфейс, или в новых кортексах черех DCMI для камеры, или просто таймер-тригер на DMA завести, чтоб данные захватывались минуя проц сразу в SRAM. Но, защелок то там нет, а значит нужно еще успевать из высокоимпедального состояния перейти в input или output, в зависимости от.. Короче опять костыли, эксперименты....
г) И последнее - корпус QFN, а значит нужно травить плату. Я пока не освоил, хотя "на подходе".
Поэтому я пока проверю идею в целом на уже имеющейся "базе" от неудавшегося SD-контроллера. Там PIC 40-ногий, с функцией Parallel Slave Port - хорошо согласуется с ISA шиной без мозговыноса. Только USB нету, даже одного, поэтому пока PS/2.
Да, я ведь ещё про совместимость 3/5 вольт не подумал.Цитата:
Но, есть нюансы.
Общение по ISA шине, для высокоскоростного STM32 не проблема - на прерываниях сделать.
-------------------------------
Может всё-таки такой вариант?Цитата:
Сообщение от Tronix
Берётся 5-вольтовый контроллер- PIC или ATMЕЛ - в мелком корпусе DIP, который легко можно подпаять поверх.
Через свободные выводы разъема магнитофона соединяется с PS/2, а ещё 3 (но можно и 2) вывода на свободные ноги 580ВВ55.
мк, соблюдая времянки, опрашивает внешнюю клавиатуру, через PS/2, система, как успевает, по последовательному интерфейсу опрашивает мк.
В общем сегодня на основе старой платформы неудавшегося SD-контроллера провел ряд экспериментов. Припаял выкушенный из материнки PS/2 разъем:
http://habrastorage.org/files/f0b/71...a6449fb978.JPG
Контроллер вместо бывшего PIC18F452 (уехавшего в часы на газоразрядных индикаторах) поставил PIC18F4620. Я его для эмулятора дисковода покупал, но не отважился, с тех пор так и лежит. Конечно контроллер - из пушки по воробьям, можно было бы каким-нибудь PIC16F877A обойтись, но что было под рукой 40-ко ногое. Прокинул дополнительно кабель от какой-то ноги до IRQ7, чтоб дергать его по мере накопления символов. Внутре контроллера идет преобразование AT - XT, имеется кольцевой буфер. Как только сканкод готов на отправку - дергается IRQ7, обработчик которого читает из порта 0x3b0 сканкод, записывает его в порт 60h и вызывает родной int 9. Вот и вся история.
Работает как и задумано:
http://www.youtube.com/watch?v=RWWwnXpdHZ0
Аппаратное сканирование родной клавиатуры прекрасно выключилось через Interrupt Mask Register контроллера прерываний 8259 вышеупомянутой конструкцией:
Если его не выключать - работает и родная клавиатура и PS/2 совместно. Набросал быстренько свой дополнительный BIOS, который устанавливает новый обработчик на прерывание 0x0f (IRQ7). Все прерывание:Код:in al,21h
or al,64 ; установить шестой бит в единицу (IRQ6 = disable)
out 21h,al
В контроллере осталось только сделать общение в сторону клавиатуры, чтоб светодиоды зажигать Num Lock, Scroll Lock, Caps Lock в зависимости от. И в дополнительном BIOS сделать переключение на русские символы. Но это мелочи. В целом - полет нормальный.Код:KB_INT PROC NEAR
PUSH AX
PUSH DX
mov dx,03b0h ; PIC18F data port
in al,dx
out 60h,al ; port 60h, keybd data write
int 9 ; Keyboard
MOV AL,20H ; контроллер прерываний
OUT 20H,AL
POP DX
POP AX
IRET
KB_INT ENDP
Сделал общение в сторону клавиатуры, теперь лампочки NumLock, CapsLock и ScrollLock зажигаются. На этом решил остановится, так как основная цель достигнута - могу управлять Поиском, у которого не работает родная клавиатура. На всякий случай выложу схемку - она немножко поменялась в отличии от SD-контроллера. Схема нарисована тяп-ляп, считайте это просто черновиком в тетрадке. Ну и сорцы прошивки для PIC-контроллера и сорцы дополнительного BIOS.
Сегодня еще попробовал прикрутить Real Time Clock по i2c. Взял какой был под рукой RTC, им оказался PCF8563 в корпусе soic8. Сделал паучка:
https://habrastorage.org/files/6c3/a...0b4dd57d23.JPG
В целом почти отладился, написал обработчик для int 1a. Но еще есть глюки, буду постепенно поправлять.
https://habrastorage.org/files/a59/3...2ec3b284ad.JPG
Пока только читаю-записываю время через свою программу...
Усе, сделал часики. Написал int 1ah обработчик. Долго невкуривал, почему у меня дата в DOS устанавливается согласно RTC, а время - всегда начинает с 12:00. Оказывается, нужно системные тики самому устанавливать согласно RTC. Ну сделал и теперь у меня всегда актуальные дата/время на Поиске :)
Возможно ли эти часики сделать(распаять) прямо на системной плате, т.е. внутри Поиска, не занимая отдельного слота ?Цитата:
Сообщение от Tronix
P/S: Или может можно прицепить внутрь отдельное устройство к системной плате, вроде этого: http://www.ebay.com/itm/Real-time-Cl...AAAOSwHnFV1vGj ?
Увы, просто это сделать не получится. Нужна какая-то прослойка между параллельной 8 битной шиной Поиска и последовательной шиной i2c такого типа RTC. В качестве такой прослойки у меня выступает микроконтроллер, хотя можно сделать и на ПЛИС, например на EPM7064 или есть даже отдельные микросхемы-конвертеры типаЦитата:
Сообщение от Quest
PCA9564. PCA9564 и похожие - труднодостоваемо. ПЛИС - дорого. Микроконтроллер - более-менее дешево и достоваемо, но нужно писать прошивку для него. Также туда нужен отдельный дешифратор адреса в случае с микроконтроллером или с PCA9564. В случае с ПЛИС дешифратор можно внутрь упрятать (если места хватит). В итоге для подключения девайса нужно в любом случае подпаиваться к шине данных (8 проводов), шине адреса (~6 проводов), сигналам IORD (один провод) ну и питание (два провода). Итого внутри Поиска будет висеть паук из ~20 проводов по всей плате.
Тут если уж и встраивать внутрь, то попытаться найти часы с параллельным интерфейсом сразу. Тогда отпадает надобность в конвертере (МК, ПЛИС, спец микруха), но все остальное остается на месте - отдельно дешифратор и клубок проводов.
Tronix, если DOS с часиками работает только через Int 1A, то паук на ~20 проводов - лишний. Если сигналы на шине примерно как здесь, то потребуется только сигнал #RD и сигнал AD7. При чтении на шине микроконтроллер должен отслеживать бит D7 и искать ключевую последовательность. При совпадении ключа микроконтроллер принимает еще несколько бит команды, а далее либо выдаёт данные, либо принимает в зависимости от команды. Чтобы выборка кода BIOS не мешала обмену, код можно поместить в блок с A7=0, а бит D7 микроконтроллер будет анализировать только при A7=1. Для выдачи ключа, команды и данных в блок с A7=1 кладутся две константы - 0 и 128, а BIOS читает либо одну, либо другую в зависимости от того, какой бит нужно выдать. Для приёма данных BIOS читает ячейку с A7=1 из какой либо дыры в памяти и смотрит старший бит, который микроконтроллер формирует если принял ключ и соответствующую команду. Ну и делать это всё нужно естественно при запрещённых прерываниях.
Все это так, все это верно... Кроме одного нюанса - микроконтроллер должен работать на частоте не меньше 200 MHz, что бы успевать что-либо смотреть на шине. И если смотреть в сторону ARM'ов и STM32 в частности - нет у них стандартного средства для ведомого параллельного интерфейса. Ведущий - пожалуйста, DCMI, FSMC. А ведомый - нет. Если в ручную ногами дергать - ARM для ногодрыга плохо подходит, ибо у него кеши, префечи, очереди в нутри, что по сути означает - неведомо за сколько выполнится та или иная операция. Один раз может за столько, а на другой уже не за столько а за столько, потому что очередь внутри переполнилась и он задумался или просто в кеш не попали и тд и тп. А успеть надо переключить порт с input на output, выплюнуть данные и уйти быстренько опять в input, дабы не случилась коллизия на шине данных. Поэтому если кто знает 8-битный микроконтроллер, работающий на ~200 MHz тактовой, то идея имеет право на жизнь. Иначе - очень через костыли и не факт.Цитата:
Сообщение от blackmirror
Tronix, частота ПОИСКа 5 МГц, если взять AVR с частотой 20 МГц, и после выдачи битика поставить команды SBIC PORT,RD_PIN / OUT PORT_DIR,IN_MODE в количестве покрывающем длину цикла, то мы сможем снять данные с шины за 100нс, то есть за пол такта поиска. С циклом ожидания немного похуже, может тут SLEEP поможет, но здесь еще нужно думать А STM32F0 имеет встроенные часики, частоту до 48 МГц, дёргать ногами каждый такт тоже умеет, но с выборкой команд там действительно нужно быть аккуратней.
Это не отменяет того, что частота шины 8 с копейками МГц, так же как и у ISA. При этом цикл выставления адреса происходит за ~14 нс, в которые нужно успеть отдуплить что адрес равен тому что мы ожидаем ( if (PORTXXX = 0xXXXX) ), и успеть среагировать - выставив например данные через ~15 нс на шину данных, а потом быстренько перевести порт обратно в input (в следудующие ~10 нс). Вот такая математика примерно.Цитата:
Сообщение от blackmirror
Рас такие сложности, то разумеется не стоит городить пауков на системной плате. Я думал можно обойтись малюсенькой платкой и тремя проводками... Думаю тогда целесообразнее будет разместить часы на плате HDD контроллера, как и предлагал DrPass.
Tronix, посмотрел документацию на V20, получается, что данные нужно читать до изменения сигнала #RD. Для AVR единственный шанс это Xmega 32 МГц, синхронизация частоты и таблица переходов. Иными словами, в регистре R31 нужно хранить состояние программы(какой бит принимаем или выдаём), командой IN читать #RD и AD7 в регистр R30(1 такт), командой IJMP переходить по адресу R30:R31(2 такта), модифицировать R31 однотактными командами, если нужно перейти в новое состояние или добавлять NOP для сохранения синхронизации. То есть читать сигналы и принимать решение мы сможем 1 раз за такт шины. Выдачу данных придётся делать поймав #RD->0 (значит чтение нужно разместить поближе к этому переходу) и отключаясь от шины через фиксированное время в момент #RD->1, но не проверяя данного факта. Для более быстрых контроллеров синхронизацию частоты делать тоже придётся, то есть как минимум получается три провода, CLK, #RD и AD. Программа тут конечно тоже будет похожа на паука, весь вопрос в том, какие пауки кому больше нравятся :)
blackmirror, я подумал еще раз немного на эту тему и, почти гарантирую - не успеет. Либо, если я все-таки ошибаюсь, успеет, но только обрабатывая параллельную шину и ничем больше не занимаясь. Ни шага в сторону, не говоря уже о PS/2 или светодиодом мигнуть. Мигнул светодиодом - не успел выставить на шину данные по запросу ВНЕЗАПНО пришедшему. Это за гранью добра и зла. И ARM не успеет, если речь идет о STM32. На каких-нибудь NXP LCP мегагерц под ~200-300 попробовать можно конечно, но а) стоимость такого контроллера б) из пушки по воробьям, то есть конечно молотилку отдаем под шину, а остальных 99,9% контроллера простаивают (флеш, рам, модули встроенные, ноги gpio) и в) зачем - если для параллельной шины есть PIC с его PSP (Parallel Slave Port), как и сделано у меня....
Tronix, про параллельную шину речь не идёт, речь идёт про то, как обойтись тремя проводками(не считая питания). Но лучше конечно делать аппаратную поддержку: сигнал IORD будет использоваться как SPI_CLK, сигнал с линии адреса будет SPI_IN, с линией данных (через транзистор или буферный элемент управляемый сигналом IORD) будет соединяться сигнал SPI_OUТ, обычно пребывающий в состоянии входа. Маркер выбираем такой, чтобы при циклическом сдвиге его байты не повторялись, тогда получив из SPI какой либо байт, по таблице находим сколько бит маркера уже принято, программно(или подключив к IORD еще и таймер) выкидываем некоторое количество бит, чтобы остался последний байт маркера, снова включаем SPI, принимаем хвост маркера и если всё нормально, переключаем SPI_OUT на вывод, ну а далее мы можем передать всё что угодно, если конечно DMA не влезет. В таком варианте оно может взлететь даже на tinyAVR.
На моём поиске не работают клавиши. Как-то ситуация прояснилась? Как-то можно отремонтировать то, что у меня есть?
Можно было бы сделать девайс на скромной ОЭВМ и аппаратных ключах пленочной клавы типо 561КП2 в количестве N шт.
Достоинство - полная аппаратная совместимость и дешевизна.
Быстродействие ОЭВМ - в 2 лимона рег-рег вполне можно было бы уложиться, к-во проволок управления ключами - в 16 шт. тоже можно уложиться.
Кстати, ничто не мешает параллельно подключать классическую клаву Поиска из комплекта поставки.
Tronix, Я предлагаю назвать эту разработку как-то так : В619 - адаптер контроллера PS/2 и USB клавиатур.