Вектор06Ц, клава и мышь PS/2 через "ПУ"

[KTSerg]

Только на ПУ, конечно. ВУ ни разрядов не хватит, ни быстродействия для опроса. А для ПУ должно хватить: всего на пипико выведено 26 gpio. Если сделать как ты сказал, один порт адрес регистра, второй данные, + строб и r/w. Получается 18 пинов, ...

Если пользователю не давать доступа к настройкам мыши, то одного порта "ПУ" для чтения с мыши вполне достаточно. А вот если захочется её программировать вручную, то нужен ещё порт на выход, что-бы не приходилось ещё и направление портов "ПУ" менять постоянно.

[Advertiser]

[ivagor]

У простого варианта кстати есть потенциальный плюс - проще добавить в v06cc на девбордах с мышью.

[svofski]

Если пользователю не давать доступа к настройкам мыши, то одного порта "ПУ" для чтения с мыши вполне достаточно. А вот если захочется её программировать вручную, то нужен ещё порт на выход, что-бы не приходилось ещё и направление портов "ПУ" менять постоянно.

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

[KTSerg]

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

Двунаправленность шины это чаще всего удобно, но у ВВ55 для смены направления РУС нужно переписывать, данные в портах сбрасываются... хлопотно за этим всем следить. Проще выделить отдельные порты на вход и на выход, пользоваться ими и нещёлкать направлениями постоянно. Да, больше расход пинов/портов/разрядов, но код программы проще, отслеживать направление данных не нужно.
Но это моё личное мнение хронического лентяя...

[svofski]

Один раз достаточно написать процедуры для ввода и вывода и следить больше не нужно.
Но по-моему 8255 уже дает все, что нужно как раз примерно для такого обмена: порт А в режиме 2 (двунаправленные данные), порт B в режиме 0 (адрес), порт C[3:7]- гандшейк для порта А.

[ivagor]

Мне кажется проще выделить один порт на запись, а другой на чтение, чтобы не заниматься двунаправленным обменом через A. Или для экономии портов (и возможно совместимости с другими устройствами подключенными к ПУ) все же переключать направление обмена, для мыши и клавиатуры это сравнительно малозатратно.

[PPC]

Должно быть просто и быстро. Направление настраивается один раз и больше не трогается. Думаю, при разумно сделанном контроллере, фулл даплекс режим нибблов порта C вообще будет не востребован. Кидаем номер регистра в порт (A или B) настроенный в режиме запись потом либо туда же пишем Дату Туташхию либо читаем данные из порта (B или A) настроенного на чтение. На запись получается регистр-секвенсер. На чтение, 2 разных порта. Не стоит направления переключать. Это лишние такты проца. Итого 256 регистров. Их разрядность можно оговаривать, но в первом приближении, пусть будут все по 8 бит.

ЗЫ. Биты третьего двунаправленного порта можно завести под status/control самого контроллера. Типа:
ожидание чтения (данных)
ожидание записи (данных)
keep in reset
discard command (типа игнорировать последний выбранный регистр).

Но это плюшки уже

[svofski]

Дату Туташхию

Оценил

[KTSerg]

Если подумать о предполагаемых плюшках типа представления данных от мыши (или подключенных к девайсу джойстиков), в виде, совместимом с данными от джойстика, то наверное стоит посмотреть, будет-ли он полностью совместим с уже существующим стандартом джойстика по подключению и управлению... или это будет ещё одна разновидность, под которую будут свои дрова, и существующие софт его не будет видеть как джойстик...

[Improver]

будет-ли он полностью совместим с уже существующим стандартом джойстика по подключению и управлению

Правильное замечание. Можно и нужно сделать возможность переключения контроллера в режим такой совместимости, кнопкой и/или программно.

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