|
nedoPC.orgElectronics hobbyists community established in 2002 |
|
|
Page 1 of 1
|
[ 13 posts ] |
|
[ASM] nedoNet for i8080 (aka "Home Control System")
Author |
Message |
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
Отпочковано от: viewtopic.php?t=7540&start=60Про разные процы 8080 подцепленные вместе через некоторое подобие сети я ещё в 1997 году своим эмулятором эмулил: Тексты принимающих и передающих программ (передача идёт побайтно) для операционной системы ShaOS: | | | | Code: \ ШАБАРШИН А.А. 28.06.97 \ NETWARE FOR HOME CONTROL SYSTEM
\########################### \# ORG #NNNN # \# JMP START # \# +INCLUDE\NET # \# START: ... # \###########################
NET_N DB #C0
\ ЗАДЕРЖКА D*32 ТАКТОВ \ ВХ: D - КОЛ-ВО ЦИКЛОВ
NET_D: NOP NOP NOP MOV_A,A DCR_D JNZ NET_D RET
\ ВЫДАТЬ БАЙТ В СЕТЬ \ ВХ: A - БАЙТ ДЛЯ ПЕРЕДАЧИ
NET_O: PUSH_B PUSH_D PUSH_H PUSH_PSW MOV_B,A LDA NET_N MOV_E,A \ ФОРМИРОВАНИЕ СТАРТОВОГО БИТА "1" MVI_A, 1 OUT 0 MOV_D,E CALL NET_D \ ФОРМИРОВАНИЕ СТАРТОВОГО БИТА "0" XRA_A OUT 0 MOV_D,E CALL NET_D DCR_E \ ПЕРЕДАТЬ 8 БИТ ИЗ РЕГ.B MVI_C, 8 NET_O2: MOV_A,B RLC MOV_B,A ANI 1 OUT 0 MOV_D,E CALL NET_D DCR_C JNZ NET_O2 MOV_A,B \ СФОРМИРОВАТЬ БИТ ЧЁТНОСТИ ORA_A JPE NET_OP XRA_A JMP NET_O3 NET_OP: MVI_A, 1 NET_O3: OUT 0 MOV_D,E CALL NET_D \ ФОРМИРОВАНИЕ СТОПОВОГО БИТА MVI_A, 1 OUT 0 MOV_D,E CALL NET_D MVI_A, 0 OUT 0 NET_OE: POP_PSW POP_H POP_D POP_B RET
\ ПРИНЯТЬ БАЙТ ИЗ СЕТИ \ ВЫХ: A - ПРИНЯТЫЙ БАЙТ \ FLAG-C - СИГНАЛ ОШИБКИ
NET_I: PUSH_B PUSH_D PUSH_H \ ОЖИДАНИЕ СИГНАЛА В СЕТИ NET_I0: IN 0 ORA_A JZ NET_I0 \ ПОДСЧЁТ СКОРОСТИ ОБМЕНА MVI_C, #FF NET_I1: INR_C IN 0 CPI 1 JZ NET_I1 MOV_A,C CPI 3 \ ОШИБКА ЕСЛИ МЕНЬШЕ 3 JC NET_I0 STA NET_N \ ЗАДЕРЖКА 1.5 Tc ANI #FE RRC ADD_C MOV_D,A CALL NET_D MOV_E,C DCR_E \ ПРОЧИТАТЬ 8 БИТ В РЕГ.B MVI_B, 0 MVI_C, 8 NET_I2: IN 0 ORA_B RLC MOV_B,A MOV_D,E CALL NET_D DCR_C JNZ NET_I2 RRC MOV_B,A \ ПРОЧИТАТЬ БИТ ЧЁТНОСТИ IN 0 MOV_C,A \ ЗАДЕРЖКА MOV_D,E CALL NET_D \ ПРОЧИТАТЬ СТОПОВЫЙ БИТ IN 0 ORA_A JZ NET_IR \ ЗАДЕРЖКА ДО КОНЦА ПОСЛЕДНЕГО БИТА MOV_D,E CALL NET_D MOV_A,C ORA_A JNZ NET_I3 \ ДАННЫЕ ДОЛЖНЫ БЫТЬ НЕЧЁТНЫМИ (PO) MOV_A,B ORA_A JPE NET_IR JMP NET_IK \ ДАННЫЕ ДОЛЖНЫ БЫТЬ ЧЁТНЫМИ (PE) NET_I3: MOV_A,B ORA_A JPO NET_IR JMP NET_IK \ ОШИБКА NET_IR: MOV_A,B STC JMP NET_IE \ ВСЁ НОРМАЛЬНО NET_IK: STC CMC NET_IE: POP_H POP_D POP_B RET
| | | | |
NETR.COM: NETW.COM:
Last edited by Shaos on 25 Jun 2011 11:49, edited 1 time in total.
|
25 Jun 2011 09:39 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
Суть протокола - сначала передаётся стартовый бит - иголка, по которой принимающая сторона настраивает скорость приёма (все остальные биты должны иметь ширину первой иголки). Далее идёт пауза длительностью 1-бит. Далее восемь бит байта - "1" передаётся высоким уровнем, "0" - низким. Далее идёт бит чётности (вместе с ним количество единиц должно быть чётным). Ну и завершает пачку стоповый бит, который всегда "1" - по нему тоже проверяется корректность передачи. На какртинке в нижней части можно пронаблюдать как это выглядит в проводе.
|
25 Jun 2011 09:45 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Я второй раз смотрю на эту картинку - что у неё там "потекло" внизу?
http://nedopc.org/nedopc/upload/shaos/net8080.jpg
|
25 Jun 2011 10:11 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
там бежит сетевой сигнал - слева-направо
когда добегает до конца, то начинает снова бежать сначала, перебивая старую отрисовку
вот справа видно начало передачи - #00, #01, #02, #03, #04 и т.д., а слева - продолжение вплоть до #09, передача которой ещё не завершилось
кликни на картинку, чтобы виднее было
|
25 Jun 2011 10:46 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
Над низкоуровневым протоколом передачи байтов предполагалось построить некий сетевой протокол с одним мастером и несколькими узлами. Мастер периодически бы посылал команду каждому узлу рапортовать - если рапортовать нечего, то ответ будет просто "я жив". Это всё предполагалось вот для этого:
|
25 Jun 2011 21:02 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
Примерно вот так можно всё организовать (по мотивам вычитанного из старой тетрадки 1997 года):
Предположим, что на одной шине могут находиться до 16 устройств (включая мастера). Каждая команда как минимум состоит из одного байта, старшая половинка которого задаёт команду, а младшая - получателя (или отправителя, если это ответ). Команды: 0 - я жив, ничего не изменилось (в ответ на команду A); 1 - орган управления активирован (в ответ на команду B плюс 1 байт); 2 - орган управления деактивирован (в ответ на команду C плюс 1 байт); 3 - дамп памяти (в ответ на команду D плюс 3+N байт); 4 - расширенная команда (далее 1 байт размера данных и далее данные); 5 - кое-что изменилось после предыдущего сеанса связи (в ответ на команду A); 6 - передать управление на адрес (далее 2 байта адреса - команда не подразумевающая ответа); 7 - полный статус (в ответ на команду F плюс 1 байт на размер и далее N байтов статуса); 8 - контрольная сумма записанного (в ответ на команду 9 плюс 4 байта - адрес, размер и контрольная сумма); 9 - записать блок памяти (далее идут 2 байта адреса, 1 байт размера и N байт данных); A - запросить краткий статус; B - активировать орган управления (далее идёт 1 байт идентифицирующий орган); C - деактивировать орган управления (далее идёт 1 байт идентифицирующий орган); D - запросить дамп памяти (далее идут 2 байта адреса и 1 байт размера); E - ошибка (далее идёт 1 байт кода ошибки); F - запросить полный статус.
Список возможных кодов ошибок: #E0 - команда не поддерживается; #E1 - орган управления с таким номером отсутствует (в ответ на команды B или C); #E4 - формат расширенной команды не распознан (в ответ на команду 4); #E9 - указанная область памяти защищена от записи (в ответ на команду 9); #EE - узел находится в ошибочном состоянии.
Обмен примерно такой - мастер знает какие узлы живы и периодически посылает им команду A (предположим у нас в наличии 3 узла с номерами 1,2 и 7): #A1 - мастер спрашивает как дела у узла 1 #01 - узел 1 отвечает, что всё ок - ничего не изменилось #A2 - мастер спрашивает как дела у узла 2 #52 - узел 2 сообщает, что кое-что изменилось #A7 - мастер спрашивает как дела у узла 7 #07 - узел 7 отвечает, что всё ок - ничего не изменилось #F2 - мастер спрашивает полный статус у узла 2 (т.к. он чуть ранее отвечал, что есть изменения в статусе) #72 #04 #04 #0F #02 #00 - узел 2 передаёт полный статус (значения 4 цифровых входов и 2 цифровых выходов)
Периодически мастер может пытаться опрашивать несуществующие узлы на предмет их горячего включения.
|
25 Jun 2011 22:17 |
|
|
VituZz
God
Joined: 13 Nov 2010 04:06 Posts: 1345
|
Вроде бы всё ничего, но не зря же очень живучи протоколы на основе простого текста. Они на порядки проще в отладке, чем основанные на двоичных форматах. К примеру, такой вот запрос:
- От: Хост <CR>
К: Контроллер ¹1 <CR>
Команда: Выдать краткий статус <CR>
и ответ:
- От: Контроллер ¹1 <CR>
К: Хост <CR>
Ответ: Статус ОК <CR>
Такой протокол очень легко расширять. Недостаток же - бОльший объём передаваемых данных - представляется мне совершенно малосущественным, поскольку всё равно обмен будет происходить достаточно быстро. В текстовый протокол также легко включать передачу дампов, если необходимо.
|
25 Jun 2011 22:44 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
в данном случае текст не пройдёт, т.к. каждый байт на счету - программно ведь биты из среды передачи данных читаем...
|
26 Jun 2011 08:56 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
А для примера можно чего-нибуть попробовать замутить в тестовом режиме?
Я бы мог соединить "Специалист" по RS-232 (он может у меня до 9600),
эмулятор "Специалиста-МХ" на ноутбуке (он тоже может достать последовательный
порт)... Ну и если надо 3 компа минимум - рабочая "Микроша" есть..
Потащит такая конфигурация?
_________________ iLavr
|
29 Aug 2012 22:50 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
А тут не RS-232 - тут однопроводная шина, к которой подключены до 16 компов...
|
29 Aug 2012 23:06 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
Плюс тут адаптивный последовательный протокол - нет заранее известной скорости передачи - приёмник настраивается по первому импульсу от передатчика: Перенёс экранчики поближе и подписал под "осциллограммками" какое число передаётся где: В каждой посылке 12 битов: первый бит - всегда "1" (по этому стартовому импульсу приёмник вычисляет скорость) второй бит - всегда "0" (чтобы точно определить момент, когда закончился стартовый импульс) третий бит - бит 7 передаваемого байта (самый старший) четвёртый бит - бит 6 передаваемого байта пятый бит - бит 5 передаваемого байта шестой бит - бит 4 передаваемого байта седьмой бит - бит 3 передаваемого байта восьмой бит - бит 2 передаваемого байта девятый бит - бит 1 передаваемого байта десятый бит - бит 0 передаваемого байта (самый младший) одиннадцатый бит - бит чётности (обязательный!) двенадцатый бит - всегда "1" (стоповый бит также может быть использован для проверки корректности приёма ну и просто удобно на осциллограммы смотреть - видно где байт начинается и где заканчивается) далее идёт нулевая пауза длительностью несколько битов (в примере на картинке около 5 - при 2 МГц процессоре и константе 0x20 как на картинке это примерно 230 байт в секунду). В реальных передатчиках скорее всего надо делать общий коллектор, чтобы разные устройства могли по очереди на этот провод говорить - тогда физически уровни будут инвертированные, т.к. нормальное состояние общего коллектора это подтянуто к напряжению питания. Интересный вопрос - где ставить подтягивающий резистор? Прямо на мастере можно или где-то в конце линии типа терминатор? В инете есть даже с двух сторон: Кроме сигнального провода в этой "домашней шине" предполагалась земля, питание и один резервный провод (например для передачи звукового сигнала) т.е. всего 4 - и мне тогда виделось, что будет это всё 4-жильным телефонным проводом растягиваться по дому... P.S. Тут такое дело всплыло - все узлы будут всегда слушать все передаваемые байты (неважно от мастера или от слейвов) - тогда чтобы защититься от ошибочного срабатывания контроллеров на передаваемые байты данных (например в дампе памяти может попасться байт #F2, который ошибочно можно принять за команду "запрос полного статуса у контроллера №2") надо ввести правило, что командой считается байт, перед которым в течение какого-то времени (например равного длительности предыдущего прочитанного байта) ничего не передавалось (на сигнальной линии была тишина) - в этом случае мы гарантированно будем срабатывать только там, где надо. Ну и отвечать в линию надо только если там какое-то время (опять же равное длительности предыдущего прочитанного байта) была тишина...
|
27 Dec 2018 21:17 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
вот тут человек советует кроме пул-ап резисторов ставить терминаторы 50 Ом: http://www.sigcon.com/Pubs/news/2_5.htmэто чтоли между сигналом и землёй?...
|
28 Dec 2018 05:17 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22606 Location: Silicon Valley
|
А у нас оказывается тут уже было про ОК магистрали больше СЕМИ лет назад! http://www.nedopc.org/forum/viewtopic.php?f=92&t=10748P.S. Если магистраль с ОК съедает только фронты: то наверное в мой протокол надо внести изменения - замерять не ширину первого инвертированного импульса (от спада до заваленного фронта), а скажем расстояние между двумя незаваленными спадами, тогда вместо стартовых 1 и 0 до данных надо будет иметь 1,0,1 и уже потом данные: Для 8085 надо будет переписать код, чтобы были задействованы последовательные вход SID и выход SOD, при этом инвертироваться сигнал будет внешними схемами, а вот для исполнительных устройств и датчиков, скажем если они будут на пиках, сигнальный провод этой недосети можно прямиком к ОК-пину A4 цеплять и пик сам будет при чтении-передаче программно инвертировать сигнал и переключать направление вход-выход когда надо... P.P.S. С другой стороны у Хоровица с Хиллом по ссылке выше получилось, что время нарастания и время спада очень близки (и спад даже немного длиннее), т.е. особого смысла в таком "улучшении" нет и лучше всё оставить как было, раз уж растягивание фронтов длится менее микросекунды:
|
06 Jan 2019 11:42 |
|
|
|
Page 1 of 1
|
[ 13 posts ] |
|
Who is online |
Users browsing this forum: No registered users and 63 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|