nedoPC.org

Я имел ввиду хорошая!

А я прочитал - "дорогая"

Шина NI-1 недавно переименована в NI-15 (по числу контактов)

Народ, вы что? ВК28/38 берет слово состояния, что выдается на ШД и защелкивается по SYN. Можно обычный регистр на 8 бит заюзать. Тока привычные !MWR и !MRD там не будут. Там как у Z80. Кста, это во всех древних доках написано. И зачем 2,5 рублика тратить.

Обычный регистр дороже выйдет чем ВК28/38

Наскока? Мне, например, больше нравится набор сигналов IORQ/MREQ/RD/WR чем IORD/IOWR/MEMRD/MEMWR....

Наконец-то раздобыл 15-контактные гнезда для втыкания в них NI-15 устройств! Теперь можно проектировать девайсы

Кто что думает по поводу организации на NI-15 мультимастерного обмена ?

Мне тут интересно стало и надумал я вот что (пока только надумал):

- ограничим шину максимум 8 слотами (больше вряд ли нужно)

- разбиваеим все адресное пространство шины на 8 частей. Старшие три бита - номер слота, младшие 5 - номер порта в слоте. Таким образом кажое устройство, воткнутое в шину окзывается жестко привязано к номеру слота. Адресное пространство устройства будет ограничено 32 портами (более чем достаточно). Старшие 2 порта с адресами 0x1E(регистр данных) и 0x1F (регистр управления (запись) и состояния (считывание)) резервируем для работы с контроллером шины. остальные 30 портов пользователь может юзать как хочет.

- Собственно контроллер шины - ПЛМка с зашитой логикой и ОЗУшка, скажем на 8К. В озу шке каждому слоту будет отвечать 1К.
ПЛМка должна формировать сигналы _RD, _WR и _СS, отдельные для каждого слота (в зависимости от того, является в данный момент устройство в слоте главным на шине или нет). Ну и плюс обрабатывть обращение устройств к кантроллеру шины.

-Процесс мультимастерного обмена выглядит следуюшим образом. Устройство, которое хочет обменяться по шине, записывает определенный бит в регистр управления. Затем ждет пока в регистре состояния не установится определнный бит, указывающий, что шина отдана в пользование этому устройству).
Теперь устройство может либо обменяться непосредственно с другим устройством по шине (скажем записать вывести данные на индикатор), либо записать чтото в ОЗУшку или считать из нее. Протокол обмена через ОЗУшку контроллера шины - произвольный. Собственно ОЗУшка нужна чтобы мастера шины могли обмениваться данными друг с другом, а не только со слэйвами.

Как вам идея ? Насколько реализуема ?

Вполне

Предлагаю такое расширение шины назвать NI-15M

Предложения по улучшению идеи:
1) контроллер шины тоже должен иметь интерфейс NI-15 устройства!
2) количество слотов предлагаю увеличить до 16 (причем один из них уже будет занят контроллером шины - остается 15), при этом мы получим на каждом слоте 16 адресуемых байтов в 2 блоках, переключаемых по M/IO
3) WR/RD/CS - объединены по шине и устанавливаются текущим мастером (как и ALE c M/IO)
4) при включении системы мастером на каждом сегменте считается контроллер - он перебирает все девайсы по их адресам состояния и смотрит кто хочет быть мастером - после этого отдает управление - когда текущий мастер отработает свое, он запишет в регистр управления контроллера шины специальный байт, означающий что он отдает управление контроллеру шины
5) в контроллере шины можно реализовать watchdog, который будет сбрасывать питание на сегменте шины, если ему вовремя не передали управление

Ок. Возражений нет.


Помоему - не попрет. Дело в том, что единственные сигналы шины, которы оговоренно могут быть сформированы отдельно - это сигналы _CSxx. (xx-номер слота). Но в шину выведен только один сигнал _CS - для текушщего слота. Поэтому контроллер мультимастерного обмена должен быть отдельным не NI-15-устройством.


согласен. только 15 байт из 16 будут доступны пользователю (15 памяти и 15 портов). Байт памяти 0x0F - регистр данных контроллера шины. Порт в-в 0х0F - регистру управления-состояния контроллера шины. Я тут подумал - пусть логика будет такаяже как на модуле WP1602. Т.е. байт в пространстве адресов в\в - регистр управления(состояния), а байт с тем же адресом в пространстве адресов данных - регистр данных. Помоему это логично. И дешифратор проще .


Только WR/RD. _CSxx будет служить для захвата шины. Скажем алгоритм такой. ( _CSxx- с открытым коллектором и поддтяжкой к +5В. Устройство должно уметь выставлять свой _CSxx и опрашивать его текущее состояние.)
Теперь алгоритм.

1. Устройство, желающее стать мастером, на некоторое время (некритично) садит свой _CSxx в 0.
2. Потом отпускает его (он естественно устанавливается обратно в 1). 3. Опрашивать состояние этого самого _CSxx, пока оно не станент равно 0. Контроллер шины определяет когда данное устройство может стать мастером и устанавливает _СSxx в 0. С этого момента устройство считается мастером на шине. _СSxx=0 пока устройство в слоте номер xx не отдаст шину (или контроллер не освободит шину принудительно).
4. После захвата шины устройство может управлять контроллером шины по адресу 0x0F (память (M_IO=1): чтение-запись - регистр данных. порты (M_IO=1): запись - регистр управления, чтение - регистр состояния).
5. Закончив обмен по шине, устройство записывет в регистр управления определенный бит (команда "освободить шину"), после чего контроллер либо отдает управление следующему мастеру, сделавшему запрос на захват шины, либо полностью освобождает ее (если нет запросов) и ждет пока кто-нибудь не запростит захват шины вновь.



Лучше подругому. При включении все мастера дают на запрос шины. Скажем в течении не более, чем 10мс с момента старта. Контроллер запоминает, с каких слотов пришли запросы и помечает их как "активные устройства". Остальные слоты помечаются как "пассивные". Можно так же сделать так, чтобы при инициализации устройства посылали несколько байт расширенной информации в контроллер (тип устройства в слоте, параметры и т.п.).



Согласен. Только устройство захватывающее шину, должно иметь возможность выставить для своего обмена время, отличное от дефолтного.

Еще я подумал - обмен с "пассивными" устройствами так же лучше осуществлять через контроллер шины.

А зачем тогда NI-15?

Сигнализация через CS - не очень хорошая идея по-моему. На самом деле я предлагал всегда сохранять его в 0, когда сегмент шины работает и девайсы просто должны одновременно не засылать на шину и одномоментно мастером должен быть только один из них. И вроде нет ничего плохого в том что контроллер шины будет NI-15 девайсом.

Как зачем ? чтобы было куда слоты втыкать ! Я же не говорю что ТОЛЬКО через контроллер шины. Просто возможность такую иметь охота.
Скажем запихал килобайт в контроллер шины, тот при первой возможности этот килоюайт выплюнул в пассивное устройство по некоему адресу. И все. Разгрузка в общем.


Мне тоже не очень нравится - но сигналов то больше нет. Если только ввести отдельный сигнал и сделать не NI-15, а NI-16



А как ты представляешь алгоритм работы устройства по управлению шиной ? Я вот чтото не очень представляю такой алгоритм... Хочется чтобы запрос на захват шины выставлялся асинхронно.

Народ, а если просто сделать так:
Девайс перед установкой !CS должно просто проверить его состояние. Если 1 - Все ОК, если 0 - ждать. Типа как у I2C. Только, нужен механизм, который даст понять контроллеру, что еще одно устройство хочет шину, при активном другом. Вот тогда то и понадобится таймаут. Это ИМХО, но может есть немного разумного?

Я тут накидал структуру мультимастерного контроллера шины С асинхронным запросом шины, буферной памятью (можно использоватть контроллерную и т.п.)

Оцените - какая примерно нужна ПЛИСка чтобы запизать всю мелкологику ? Если реально по цене - то все войдет в две мелкосхемы - контроллер и плису.

http://www.nedopc.org/nedopc/upload/NI- ... STRUCT.pdf

Ну я написал как представляю - текущее мастер-устройство добровольно отдает управление шиной контроллеру, который передает управление следующему мастер-устройству. Все переговоры ведутся через байт управления-состояния устройств.