Смотрю я на эти платы 4 на 4 дюйма и обуяла меня идея - построить комп из таких квадратных платок, которые друг на друга насаживаются этажеркой
Все сигналы - сквозные (охватывающие все ноги Z180). Одна плата процессора, а всё остальное - периферия.
Можно ещё сбоку добавить гребёнку - для расширенных сигналов адреса и возможно даже SPI-интерфейса, по которому платы будут договариваться с мастером об адресах в которые будут втыкаться!
В качестве контроллеров этих интеллектуальных плат можно поставить дешёвые пики-однократки PIC12C508, соединёные в Daisy-chained SPI bus.
Отдельные платки могут включать в себя:
- расширения памяти;
- квазидиск на пзухах;
- часы реального времени;
- музыкальный сопроцессор;
- видеоконтроллер;
- сетевой адаптер;
- последовательные COM-порты;
- параллельный LPT-порт;
- интерфейс хард-драйва (IDE);
- интерфейс флоппика;
- интерфейс к SD-карточке и т.д.
Пользователь сможет самостоятельно строить желаемые конфигурации, собирая их из набора плат, которые будут договариваться друг с другом об адресах в которых сидят, причём у процессора будет API по которому можно будет программно достать список устройств с диапазонами их адресов. Как идея?
Daisy-chain SPI:
Надо по быстрому протокол для negotiation придумать...
Last edited by Shaos on 02 Jun 2013 09:22, edited 6 times in total.
Я тут за главного - если что шлите мыло на me собака shaos точка net
Предположим, что каждая плата может нести в себе до 1 мегабайта памяти и скажем до 64 портов ввода-вывода.
Тогда плата может сообщить о своих претензиях на адресное пространство памяти и портов в одном байте - 3 бита на память:
000 - память не используется;
001 - используется 16К памяти;
010 - используется 32К памяти;
011 - используется 64К памяти;
100 - используется 128К памяти;
101 - используется 256К памяти;
110 - используется 512К памяти;
111 - используется 1MB памяти.
000 - порты не используются;
001 - используется 1 порт;
010 - используется 2 порта;
011 - используется 4 порта;
100 - используется 8 портов;
101 - используется 16 портов;
110 - используется 32 порта;
111 - используется 64 порта.
Ещё остаётся 2 бита, в которых можно указать назначение периферийного устройства:
00 - RAM;
01 - ROM;
10 - простейшее устройство ввода-вывода у которого нет памяти и 3 бита, отведённые под указание размера памяти могут быть задействованы под тип устройства (ВВ51, ВВ55, ВИ53 и т.д.);
11 - сложное устройство с памятью и портами, в последнем порту которого будет содержаться более подробная информация о его назначении.
При включении устройства мастер (большой пик) опрашивает все платы и получает от них описанные выше байты назначения, после чего вычисляются начальные адреса в памяти и в области портов (выделения идут начиная с самых больших областей, причём области выровнены в соответствии со своими размерами) для каждой платы и эти адреса засылаются в каждую плату в виде 2 байтов: для памяти это будет A14...A21 (т.к. минимальный размер окна это 16К), а для портов - A8...A15 (младший адрес таких динамических портов всегда будет равен какому-то определённому значению, например #AA). Эти адреса будут использоваться боротвыми дешифраторами адреса на платах для выработки своих сигналов !CS.
Last edited by Shaos on 02 Jun 2013 09:25, edited 1 time in total.
Я тут за главного - если что шлите мыло на me собака shaos точка net
Shaos wrote:
00 - RAM;
01 - ROM;
10 - простейшее устройство ввода-вывода у которого нет памяти и 3 бита, отведённые под указание размера памяти могут быть задействованы под тип устройства (ВВ51, ВВ55, ВИ53 и т.д.);
11 - сложное устройство с памятью и портами, в последнем порту которого будет содержаться более подробная информация о его назначении.
Тип устройства (3 бита для кода 10 и 8 бит для кода 11) можно унифицировать, включив туда же RAM и ROM:
#00 - RAM;
#01 - ROM;
#02 - GPIO (светодиоды, кнопки и т.д.);
#03 - ВВ55 (параллельный интерфейс);
#04 - ВВ51 (последовательный интерфейс);
#05 - ВИ53 (генерация звука);
#06 - COVOX (и возможно ADC на ввод звука);
#07 - AY-3-8910 или YM2149F;
#08 и далее - зарезервировано для сложных устройств.
P.S. ВВ51 вернул, т.к. проц может быть не только Z180, у которого есть встроенная реализация последовательного порта, а также убрал RTC, т.к. часы реального времени это всё-таки сложное устройство с памятью, выдачей прерываний и т.д.
Last edited by Shaos on 16 May 2013 13:45, edited 1 time in total.
Я тут за главного - если что шлите мыло на me собака shaos точка net
Shaos wrote:
При включении устройства мастер (большой пик) опрашивает все платы и получает от них описанные выше байты назначения, после чего вычисляются начальные адреса в памяти и в области портов (выделения идут начиная с самых больших областей, причём области выровнены в соответствии со своими размерами) для каждой платы и эти адреса засылаются в каждую плату в виде 2 байтов: для памяти это будет A14...A21 (т.к. минимальный размер окна это 16К, а максимальный размер используемой памяти - 4 мегабайта), а для портов - A8...A15 (младший адрес таких динамических портов всегда будет равен какому-то определённому значению, например #AA). Эти адреса будут использоваться боротвыми дешифраторами адреса на платах для выработки своих сигналов !CS.
Общение может происходить примерно так - после включения мастер первый раз дёргает !SS и потом засылает в Daisy-Chain байты #00, принимая при этом байты назначения из цепочки - первым будет рапортовать самая ближняя к мастеру плата. Когда из цепочки будет получен #00, то это будет означать, что все платы отрапортовались (нулевого байта назначения платы быть не может). Далее мастер второй раз дёрнет !SS и слейвы перейдут в режим приёма базовых адресов памяти. Третье дёрганье !SS включит режим приёма базовых адресов портов. После этого !SS переводится в "1" и общения между контроллерами больше не происходит. Всё это время главный процессор будет находится в режиме ребута (!RESET=0).
P.S. Примерно вот такие дополнительные сигналы будут нужны каждой "интеллектуальной" плате:
1 - MOSI (вход данных контроллера) сверху и MISO (выход данных контроллера) снизу;
2 - MO (выход мастера, уходящий наверх где у самой верхней платы-заглушки он будет соединён с предыдущим сигналом);
3 - SCLK (клок от мастера);
4 - _SS (выбор всех девайсов в цепочке от мастера);
5 - _CS (выбор динамических портов ввода-вывода вида #xxAA).
Last edited by Shaos on 02 Jun 2013 09:28, edited 4 times in total.
Я тут за главного - если что шлите мыло на me собака shaos точка net
В качестве контроллера у каждой платы будет один мелкий пик-однократка PIC12C508A и в качестве настраиваемого дешифратора адреса - одна или две (а то и три - в зависимости от того какие объёмы памяти и кол-во портов выбраны для каждой конкретной платы) PALCE20V8H (или PALCE16V8 если влезет). В качестве мастера можно поставить пик побольше (так как там лишние ноги будут нужны для ресета и т.д.) - например тоже однократку PIC16C54 (этого добра у меня навалом). Кроме того на мастера можно возложить дополнительную функцию - в момент ребута читать ПЗУ с последовательным доступом и записывать его содержимое в начальную область ОЗУ, подключенного через другие платы для того, чтобы главный процессор сразу начинал бы с быстрой памятью работать.
У PIC12C508A, работающего в режиме внутреннего RC-генератора, есть 6 ног общего назначения - 4 будут отведены под SPI-интерфейс и оставшиеся 2 - под загрузку PALCE, запрограммированных как сдвиговый регистр.
У каждого PALCE будет по 8 выходов, перед каждым из которых стоит D-триггер, управляющийся общим клоком (D-триггер можно исключить из схемы для некоторых выходов при программировании). Входов будет 10 (минус клок) для 16V8 или 14 (минус клок) для 20V8. Один из выходов будет отведён под подсчитанный _CS. Оставшиеся 7 будут являться выходами сдвигового регистра, на котором будут запомнены биты для сравнения с адресом. Теперь по входам: 7 будет отведено под адрес для сравнения, 1 для входного _CS, 1 для последовательного ввода ну и 1 клок. Если у нас будет PALCE, разделяющий компараторы адресов памяти и адресов портов, то там будет уже не 7 битов, а только 6, т.к. 2 выхода будет занято под два _CS, входов будет 6+2+1+1=10. Получается, что по общим прикидкам PALCE16V8 вполне влезает и в худшем случае (три PALCE) оно сможет охватить до 20 (7+6+7) общих битов для сравнения адресов (в случае двух PALCE это будет 7+6=13 бит и в случае одного PALCE - 6 или 7).
P.S. Чтобы яснее понять, что я имею ввиду под битами для сравнения, приведу опять настройки, но с указанием кол-ва хранимых бит для сравнения с адресом - по памяти:
000 - память не используется (храним 0 бит);
001 - используется 16К памяти (храним 8 бит);
010 - используется 32К памяти (храним 7 бит);
011 - используется 64К памяти (храним 6 бит);
100 - используется 128К памяти (храним 5 бит);
101 - используется 256К памяти (храним 4 бита);
110 - используется 512К памяти (храним 3 бита);
111 - используется 1MB памяти (храним 2 бита).
И по портам:
000 - порты не используются (храним 0 бит);
001 - используется 1 порт (храним 8 бит);
010 - используется 2 порта (храним 7 бит);
011 - используется 4 порта (храним 6 бит);
100 - используется 8 портов (храним 5 бит);
101 - используется 16 портов (храним 4 бита);
110 - используется 32 порта (храним 3 бита);
111 - используется 64 порта (храним 2 бита).
т.е. минимальная конфигурация будет 0+2 или 2+0 бит (0+0 быть не может - у платы должна быть или память, или порты, или и то, и другое), а максимальная - 8+8=16 (что есть небольшой недобор т.к. три PALCE могут хранить до 20 битов, как мы выяснили чуть выше).
P.P.S. Можно предположить, что RAM с портами быть не может - тогда 3 бита описателя портов в случае типа "RAM" можно потратить на ещё более мелкое разбиение памяти: 8K (9 бит), 4K (10 бит), 2K (11 бит), 1K (12 бит), 512 байт (13 бит) ну и даже 256 байт (14 бит) - другой вопрос зачем это надо?...
P.P.P.S. С другой стороны наличие портов может быть полезно и для платы с ОЗУ - например чтобы прочитать состояние сдвигового регистра и проверить что там записано то, что надо...
P.P.P.P.S. На самом деле можно и без контроллеров обойтись - всё сделать на PAL/GAL-ках, работающих в режиме сдвиговых регистров, но я не думаю, что получится дешевле...
Я тут за главного - если что шлите мыло на me собака shaos точка net
Чем то напоминает SMBus в x86.
Ну раз ты запланировал использовать SPI, что само-собой подразумевает использование МК на каждой этажерке независимо от ее содержания, так зачем ужимать байты, которые ее описываю!
He3HauKo wrote:Чем то напоминает SMBus в x86.
Ну раз ты запланировал использовать SPI, что само-собой подразумевает использование МК на каждой этажерке независимо от ее содержания, так зачем ужимать байты, которые ее описываю!
Чтобы сократить время инициализации и не усложнять программу микроконтроллеров...
Я тут за главного - если что шлите мыло на me собака shaos точка net
Не помню уже кто и когда(надо в сети поискать)было высказывание,
С стороны "Маздаев":
- Наши системы быстрее загружаются!!!
что в ответ с другой стороны последовало(*nix):
- А Нашу систему нужно только один раз загрузить!!!
Скорость МК к примеру ATMega8, как и ее сложность программирования, здесь погоды не изменит а функциональность повысит.
Shaos wrote:Я так считаю что передавая больше информации по цепочке мы просто повысим вероятность сбоя в передаче - т.е. чем меньше, тем лучше...
"В то время как космические корабли бороздят просторы большого театра..."
Ну на самом деле, не космос запускать будем!!!
Если есть вероятность збоя передачи по SPI, то какая разница сколько передавать
Например если у нас вероятность сбоя 0.1%, то передавая 100 бит за раз, мы в среднем нарвёмся на проблему на каждой десятой посылке, а если 1000 бит, то КАЖДАЯ посылка будет битая...
Я тут за главного - если что шлите мыло на me собака shaos точка net
Shaos wrote:Например если у нас вероятность сбоя 0.1%, то передавая 100 бит за раз, мы в среднем нарвёмся на проблему на каждой десятой посылке, а если 1000 бит, то КАЖДАЯ посылка будет битая...
Что-то у меня такое подозрение, что с вероятностной точки зрения ты не совсем прав...
Приведу пример:
Вероятность тяжелой аварии на АЭС оценивается величиной «10 в минус пятой степени»...
По твоей логике мы бы не должны их наблюдать просто вообще.
Shaos wrote:Например если у нас вероятность сбоя 0.1%, то передавая 100 бит за раз, мы в среднем нарвёмся на проблему на каждой десятой посылке, а если 1000 бит, то КАЖДАЯ посылка будет битая...
Что-то у меня такое подозрение, что с вероятностной точки зрения ты не совсем прав...
Приведу пример:
Вероятность тяжелой аварии на АЭС оценивается величиной «10 в минус пятой степени»...
По твоей логике мы бы не должны их наблюдать просто вообще.
Мы можем наблюдать всё, что угодно с той или иной степенью вероятности, если вероятность события больше нуля...
Я тут за главного - если что шлите мыло на me собака shaos точка net
