С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ну в нашем случае вроде не по фронту.
Мне просто интересно почему Вы делаете разницу: вот это - битовый поток, а вот это (хотя многие и его так называют) - совсем не битовый. Именно об этом, как мне кажется, не смог сказать LeoN65816.
А тут мне показалось что Вы сформулировали критерий, определили разницу.
Просто в возражениях "это не битовый поток" я-то всё ждал продолжения "потому что ..."
А тут вроде почти дождался и хотел конкретно определиться с этим "потому что", чтобы дальше было что _предметно_ обсуждать. Пока же получалось что-то из серии "я не знаю как надо, но Вы делаете (называете) это неправильно". Или "уж мы-то знаем что ты облажался, но в чем не скажем, надо же тему читать". Оба варианта не от Вас, но это всё-равно огорчало, несмотря на поддержку википедии и инженеров из Шугарта ;-)
Последний раз редактировалось dk_spb; 09.10.2016 в 20:23.
Ну, хотя бы потому, что если единица короче битового окна, то в пределах окна у нас получается два состояния: и 0 и 1. Возникает неопределенность - а в какой, собственно, момент времени железо должно определять текущее значение. Особенно, как в случае с сигналом с дисковода, если импульс узкий и "гуляет" по битовому окну. В случае с UART ситуация выглядит проще - можно защелкнуть в какой-нибудь триггер значение в середине битового окна и дело в шляпе. Поступать так с сигналом с дисковода мы не можем, мы очень быстро защелкнем не то состояние. Значит, схема должна быть построена иначе. Мы должны ловить именно факт присутствия импульса в окне, то есть определить его передний и задний фронты, убедиться что расстояние между ними какое-то разумное (то есть это не случайная "иголка") и что оба фронта находятся внутри окна.
Собственно из-за того, что детектятся вроде бы одинаковые битовые потоки по разному, и хочется их считать разными
Мне кажется Вы преувеличиваете разницу. Вот на что я бы обратил внимание: в обоих случаях для нам критически важно определить размеры окна. В случае UART при определенных особенностях канала и реализации окно тоже может плавать как по длине, так и смещаться. Да, при старт-стопной реализации UART и жесткой фиксации скорости передачи это незаметно . При длительной же передаче никто не гарантирует что наша выборка в середине окна со временем не может оказаться на границе окна.
В КНГМД при условии четкого понимания границы окна нам тоже достаточно защелкнуть тригером импульс в течении этого окна и считать выход этого тригера на заднем фронте окна. С учетом того что этот импульс формируется одновибратором в дисководе вероятностью иголки можно в большинстве случаев пренебречь. В отличии от UART тут у нас и скорость передачи может плавать.
И, опять же, разница схем обуславливается еще и тем, что в случае UART у нас асинхронная передача, а в нашем случае - синхронная. Соответственно совсем по разному определяется и момент времени, в который железо должно определять текущее значение. Так что асинхронный битовый поток и синхронный битовый поток - они уже разные.
Поэтому я целиком с Вами согласен что потоки в нашем случае и в случае UART - разные. Но почему в одном случае у Вас не вызывает возражение "битовый", а в другом - вызывает, я пока не понял.
Знаете, рационального объяснения не нашлось Я почти не встречался с импульсной логикой, поэтому в голове прочно засела потенциальная И при словах "битовый поток" сам собой всплывает NRZ-L поток. Хотя безусловно и NRZ и импульсный поток - это битовые потоки, хотя и кодирующиеся по-разному. Возможно, попадись мне в начале 90-х картинка с 9 разными кодировками одного битового потока как здесь, у меня бы сейчас не было этого возражения.
Мне кажется, Вас цифры FD-55 ввели в заблуждение. У какой-нибудь "Электроники МС5305" максимальная длительность импульса 1,5 мкс, так что уже не будет соотношения 1:1.
В некоторых сепараторах длительность импульса старались искусственно уменьшить. Поскольку "наползание" импульса правым фронтом на границу окна детектирования у некоторых контроллеров считается ошибкой чтения, выгодно иметь этот импульс максимально коротким, чтобы расширить диапазон, в котором этот импульс может "гулять". И сепаратор вовсе не обязан "выравнивать" длительность импульсов. Важен только факт наличия или отсутствия импульса внутри окна детектирования.
Если диск крутился на 10% быстрее чем надо, не в силах сепаратора растянуть время и вернуть битовой позиции длительность 4 мкс. Но у сепаратора есть функция восстановления тактовой частоты. Частота будет пропорционально повышена, окна детектирования уменьшены, и чтение бита пройдет на 10% быстрее, как и запись данных в сдвиговый регистр.
Последний раз редактировалось LeoN65816; 02.11.2016 в 13:55.
Турбо АГАТ-9/16 (ЦП 65C802, 5 Махов, dual-port SRAM).
Давайте я тогда к этому рисунку добавлю окна данных и синхронизации, чтобы было видно, что в каждом битовом элементе есть две части и каждый импульс кодирует определенный бит - бит данных или бит синхронизации. Причем, наличие импульса это 1, а отсутствие - 0. То есть, битовый поток будет 0101000100101001.
Последний раз редактировалось avivanov76; 03.11.2016 в 15:17.
Последний раз редактировалось LeoN65816; 01.01.2017 в 09:43.
Турбо АГАТ-9/16 (ЦП 65C802, 5 Махов, dual-port SRAM).
Турбо АГАТ-9/16 (ЦП 65C802, 5 Махов, dual-port SRAM).
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)