Интерфейс NI-15

cr0acker · Post by **cr0acker** » 23 Sep 2004 17:25

Shaos wrote:
cr0acker wrote:Цена у этого контроллёра хъорогая 2,75руб
Ну значит совсем простые NI-15-девайсы получатся - только в адресном пространстве памяти

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

Shaos · Post by **Shaos** » 23 Sep 2004 17:42

cr0acker wrote:
Shaos wrote:
cr0acker wrote:Цена у этого контроллёра хъорогая 2,75руб
Ну значит совсем простые NI-15-девайсы получатся - только в адресном пространстве памяти
Я имел ввиду хорошая!

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

Shaos · Post by **Shaos** » 08 Jan 2005 17:18

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

HardWareMan · Post by **HardWareMan** » 31 Mar 2005 21:25

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

Shaos · Post by **Shaos** » 01 Apr 2005 07:15

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

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

HardWareMan · Post by **HardWareMan** » 03 Apr 2005 05:10

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

Shaos · Post by **Shaos** » 30 Jun 2005 19:19

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

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

SfS · Post by **SfS** » 12 Jul 2005 19:10

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

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

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

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

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

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

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

Shaos · Post by **Shaos** » 12 Jul 2005 20:21

SfS wrote:Кто что думает по поводу организации на 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, который будет сбрасывать питание на сегменте шины, если ему вовремя не передали управление

SfS · Post by **SfS** » 13 Jul 2005 19:02

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

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

Shaos wrote: 1) контроллер шины тоже должен иметь интерфейс NI-15 устройства!

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

Shaos wrote: 2) количество слотов предлагаю увеличить до 16 (причем один из них уже будет занят контроллером шины - остается 15), при этом мы получим на каждом слоте 16 адресуемых байтов в 2 блоках, переключаемых по M/IO

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

.

Shaos wrote: 3) WR/RD/CS - объединены по шине и устанавливаются текущим мастером (как и ALE c M/IO)

Только 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. Закончив обмен по шине, устройство записывет в регистр управления определенный бит (команда "освободить шину"), после чего контроллер либо отдает управление следующему мастеру, сделавшему запрос на захват шины, либо полностью освобождает ее (если нет запросов) и ждет пока кто-нибудь не запростит захват шины вновь.

Shaos wrote: 4) при включении системы мастером на каждом сегменте считается контроллер - он перебирает все девайсы по их адресам состояния и смотрит кто хочет быть мастером - после этого отдает управление - когда текущий мастер отработает свое, он запишет в регистр управления контроллера шины специальный байт, означающий что он отдает управление контроллеру шины

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

Shaos wrote: 5) в контроллере шины можно реализовать watchdog, который будет сбрасывать питание на сегменте шины, если ему вовремя не передали управление

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

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

Shaos · Post by **Shaos** » 13 Jul 2005 19:16

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

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

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

SfS · Post by **SfS** » 13 Jul 2005 21:41

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

Как зачем ? чтобы было куда слоты втыкать !

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

Shaos wrote:Сигнализация через CS - не очень хорошая идея по-моему.

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

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

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

HardWareMan · Post by **HardWareMan** » 13 Jul 2005 22:05

SfS wrote:
Shaos wrote:Сигнализация через CS - не очень хорошая идея по-моему.

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

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

SfS · Post by **SfS** » 14 Jul 2005 20:53

Я тут накидал структуру мультимастерного контроллера шины

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

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

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

Shaos · Post by **Shaos** » 15 Jul 2005 03:56

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

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