Как должна происходить синхронизация сигналов? Опции

[Артем Бум]

Задача
Имеется микроконтроллер (МК) как представлено на прикрепленной картинке

МК должен начать принимать информацию от Арбитра после того как на С1 появится 1-ный сигнал.
После этого появится 8 1-ных сигналов на С2.
По этим сигналам через DATA МК должен принять от Арбитра байт (последовательно).

Если значение байта равно 98 (это адрес МК среди других МК) МК должен подать Арбитру через DATA байт со значением 80 (это обозначает что МК "ГОТОВ" принимать информацию).

После этого МК получит от Арбитра по DATA последовательность бит (информацию какую-то), завершающуюся последовательностью "конец передачи".

---------
Вопрос:

Я не понимаю как должна происходить синхронизация МК с Арбитром.

- когда МК должен подавать обратно "ГОТОВ": после появления единички на С1?
- как МК поймёт, что Арбитр уже начал посылать ему информацию. В какой момент он должен начать её принимать?

Прикрепленные изображения

 

[adc]

Мало входных данных. Что за Арбитр? Есть ли возможность изменять алгоритм его работы?

- когда МК должен подавать обратно "ГОТОВ": после появления единички на С1?

"Арбитр" должен после передачи адреса МК (98) "слушать" линию данных на предмет ответа от запрашиваемого МК. Как в Вашем случае поступает арбитр пока это не известно.

- как МК поймёт, что Арбитр уже начал посылать ему информацию. В какой момент он должен начать её принимать?

После того как "арбитр" и МК "разобрались" кто с кем общается и нашли общий язык :-) (после посылки команды 98 контроллер переходит в режим приема данных) МК ожидает прихода импульса на "С1" и принимает уже данные.

[Dog Pawlowa]

Я не понимаю как должна происходить синхронизация МК с Арбитром.

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

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

[Артем Бум]

Спасибо! По Вашим советам узнал логику синхронизации у преподавателя.

[defunct]

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

А не наоборот?
Специальные сигналы могут быть как у синхронного так и у асинхронного интерфейса, также как их может и не быть и там и там. (Синхронизация напр в HDLC осуществляется потоком данных).
В синхронном действуют жесткие времянки, и не приемник, а передатчик стробирует посылку. Приемник обязан успевать! (это главное требование любого синхронного протокола).
а в асинхронном кроме стробов могут быть подтверждения от приемника, которые позволяют передатчику быстрее перейти к отправке следующей порции данных либо наоборот дожидаться, пока медленное устройство не примет данные.

Взять напр. синхронный и асинхронный доступ к памяти:
Синхронный подразумевает строб R/W заранее заданной длительности T (не менее реакции самого медленного модуля памяти), за время которого гарантируется что любой модуль памяти успеет выставить данные. Временная диаграмма жесткая.

Асинхронный подразумевает строб R/W и квитирование завершения записи/чтения по сигналу RD от модуля памяти, т.о. с быстрым модулем памяти обмен будет происходить быстрее, с медленным - медленнее (нет постоянства - это и есть "асинхронный"). Временная диаграмма гибкая и зависит от модулей памяти.

UART асинхронный не потому что должен придерживаться заданной временной диаграммы, а потому что он может ее не придерживаться!!! Разность частот между передатчиком и приемником UART'a может достигать аж 10% без риска искажения данных.

[Dog Pawlowa]

А не наоборот?

Я с памятью работал давно, еще с помощью READY и TEST Так что особенно спорить не буду. Параллельный интерфейс через LPT содержит сигнал строба от передатчика и сигнал подтверждения от приемника. Как называть его - синхронный или асинхронный?
Мне лично кажется, что любое согласование дополнительными сигналами - это синхронность.
Для Ваших примеров с памятью это не так. Что будем делать?

Да, скорость передачи по LPT со стробами и подтверждениями может меняться от нуля до мегабайтов в секунду. Вот уж где не придерживается заданной временной диаграммы

[defunct]

LPT содержит сигнал строба от передатчика и сигнал подтверждения от приемника. Как называть его - синхронный или асинхронный?

Если скорость передачи одного кадра не меняется (интервал времени затрачиваемый на пересылку кадра постоянный) тогда интерфейс синхронный. Если меняется - асинхронный.
У LPT ведь разные режимы работы есть SPP / EPP / ECP, асинхронно-синхронный?

Мне лично кажется, что любое согласование дополнительными сигналами - это синхронность.

Ну а как насчет HDLC? Синхронный? Да. И нет упр. сигналов.

Да, скорость передачи по LPT со стробами и подтверждениями может меняться от нуля до мегабайтов в секунду. Вот уж где не придерживается заданной временной диаграммы

Вот это и делает его асинхронным.

[VladimirYU]

Разность частот между передатчиком и приемником UART'a может достигать аж 10% без риска искажения данных.

Это интересно как? Обычная арифметика подсказывает, что при передачи 8бит +1старт+1стоп разность не может быть больше 4%.

[Dog Pawlowa]

Со скоростью кадра - допустим, есть USART и UART, оба передают кадры со отклонением скорости 0,1%.
Так они оба синхронные, оба асинхронные, или таки разные?

У LPT ведь разные режимы работы есть SPP / EPP / ECP, асинхронно-синхронный?

А там во всех случаях есть сигналы хэндшэйкинга, они отличаются количеством направлений и DMA и еще "мелочами".

Вот это и делает его асинхронным.

И мне смешно

[defunct]

Это интересно как? Обычная арифметика подсказывает, что при передачи 8бит +1старт+1стоп разность не может быть больше 4%.

5-N-2 / 6-N-2 - суммарная ошибка бит интервала будет до 50%, что приемлемо для устойчивого приема.
По старту приемник синхронизируется с передатчиком, т.о. 1-й бит данных всегда будет принят верно.
На каждый последующий бит данных действует смещение в разность частот (10%) для 5-N-2 имеем 40% отклонение для 6-N-2 - 50%.

[_dem]

Господа, есть есть сигнал, по стробу которого происходит передача данных - то синхронный. В противном случае - асинхронный

Что-то всем смешно

[defunct]

Со скоростью кадра - допустим, есть USART и UART, оба передают кадры со отклонением скорости 0,1%. Так они оба синхронные, оба асинхронные, или таки разные?

Разные, отличие не в передатчиках (хотя и в них тоже), а в приемниках.

А там во всех случаях есть сигналы хэндшэйкинга, они отличаются количеством направлений и DMA и еще "мелочами".
И мне смешно

Если сигналы квитирования передаются на каждый кадр (передатчик не может перейти к отправке сл. кадра без подтверждения текущего) - интерфейс асинхронный.
У LPT порта есть сигнал ACK, но используется ли он для квитирования передачи каждого байта?
Если нет (а насколько я знаю ничто не мешает не использовать этот сигнал) то интерфейс будет синхронным, в противном случае - асинхронным.. Кстати LPT это не интерфейс, это все-таки порт, со своей фантазией сигналов, также как и COM это не интерфейс, а порт - со своей фантазией.

Господа, есть есть сигнал, по стробу которого происходит передача данных - то синхронный. В противном случае - асинхронный

Асинхронный тоже может быть со стробом.

[=GM=]

Это интересно как? Обычная арифметика подсказывает, что при передачи 8бит +1старт+1стоп разность не может быть больше 4%

Обычная арифметика говорит немного иное. Погрешность из-за нестабильности частоты приёмника при приёме абсолютно точно сформированного по времени сигнала составит ±0.5/8.5=0.059 или ±5.9%, поскольку последний отсчёт делается при t=8.5*To, а допустимые временные рамки не превышают ±0.5*То. Так что РАЗНОСТЬ может доходить до 5.9%.

Однако частота передатчика гуляет независимо от частоты приёмника. Если предположить, что передатчик и приёмник имеют похожие генераторы, то погрешность приёмника (как и передатчика) надо уменьшить вдвое. Таким образом, имеем допустимую погрешность частот расстройки передатчика и приёмника, равную ±2.9%.

[aesok]

Обычная арифметика говорит немного иное. Погрешность из-за нестабильности частоты приёмника....

Студенту задали SPI интерфейс реализовать, а вы тут арифметику разводите...

Анатолий.

[Kuzmi4]

Студенту задали SPI интерфейс реализовать, а вы тут арифметику разводите...

Анатолий.

Как по мне , то больше на TWI смахивает - по дата-проводу гоняются данные туда/сюда по тактированию с 2-го провода..
Вот только не пойму зачем им такие хитрые реализации, свои протоколы - стандартных не хватает ?
В той же меге 2-х проводной присутствует...

Или всё таки идея - замучать студента в конец ??

[aesok]

Как по мне , то больше на TWI смахивает - по дата-проводу гоняются данные туда/сюда по тактированию с 2-го провода..
Вот только не пойму зачем им такие хитрые реализации, свои протоколы - стандартных не хватает ?
В той же меге 2-х проводной присутствует...

Или всё таки идея - замучать студента в конец ??

C1 это CS
C2 это CLK
Data - 2-х направленая шина данных.

Анатолий.

[svs39]

Господа, есть есть сигнал, по стробу которого происходит передача данных - то синхронный. В противном случае - асинхронный

Что-то всем смешно

Думаю не так! Синхронный способ передачи -передача непрерывно с постоянной скоростью(HDLC),
асинхронный- остальное( UART 8N1- асинхронные кадры, но биты в пределах кадра-синхронны). Для синхронного способа не нужен сигнал синхронизации, скорее он нужен для асинхронного ( в случае UART- самосинхронизация)

[defunct]

Давайте чтобы поставить точку в определении синхронных/асинхронных интерфейсов обратимся к интернету

Вот такое определение синхронных интерфейсов предлагается в статье Volker Soffel'a Microcontroller Interfaces Part1:

Synchronous interfaces are characterized by the presence of a dedicated receive/transmit clock signal. A "Master" device usually outputs a clock signal that is received by all "Slave" devices to receive and transmit data in synch. The advantage: Each device works with the transmit/receive clock of the master independent of any oscillator variations of each individual device; so these interfaces are very suitable for use with cheap oscillators that have large frequency variations

от туда же определение асинхронных интерфейсов:

Asynchronous Interfaces
While synchronous interfaces transmit and receive data in sync with a dedicated receive/transmit clock signal, asynchronous interfaces embed the clock information into the data stream. Therefore they are characterized by the absence of a dedicated receive/transmit clock signal. For devices to communicate in sync with each other, they need to agree on the same transmission speed (kbits/sec), the same protocol (number of data bits, stop bits, parity, etc), and they need to constantly re-sync to the clock embedded into the data stream. Re-syncing is usually achieved through start and stop bits (or frames) at defined positions in the data stream. To keep in synch, it is also required that the devices' system clock is stable within a few percent - simple R/C oscillators with +-25% tolerances or more will not work.

В контексте интерфейсов МК, я с такими определениями абсолютно согласен.

Получается Dog Pawlowa практически прав, за исключением одной мелочи, которая и подтолкнула меня к поискам истины

В синхронном есть специальные сигналы, где приемник сообщает передатчик, что он принял данные - например, LPT.

Заменить "приемник сообщает передатчику, что он принял данные" (что есть составной частью асинхронных интерфейсов) на "передатчик генерит клок для приемника, приемник(ки) должен успеть в рамках этого клока принять/передать данные", и все станет на свои места.

[Dog Pawlowa]

Вот такое определение синхронных интерфейсов предлагается в статье Volker Soffel'a

Я тоже стал искать в интернете, но не хватило терпения. В статье написано логично, но всегда можно найти к чему придраться :

To keep in synch, it is also required that the devices' system clock is stable within a few percent - simple R/C oscillators with +-25% tolerances or more will not work.

Если вырвать эту фразу из контекста обычного асинхронного последовательного интерфейса, она не совсем справедлива, поскольку есть десятки других интерфейсов, где частота может меняться долговременно в десятки раз - например интерфейс радиоприемников фирмы Linx.

Получается Dog Pawlowa практически прав, за исключением одной мелочи, которая и подтолкнула меня к поискам истины
Заменить "приемник сообщает передатчику, что он принял данные" (что есть составной частью асинхронных интерфейсов) на "передатчик генерит клок для приемника, приемник(ки) должен успеть в рамках этого клока принять/передать данные", и все станет на свои места.

Угу, синхронизация от передатчика к приемнику несомненно важнее.
Но если есть еще и обратная синхронизация ...назовем это суперсинхронным интерфейсом?

[VladimirYU]

5-N-2 / 6-N-2 - суммарная ошибка бит интервала будет до 50%, что приемлемо для устойчивого приема.
По старту приемник синхронизируется с передатчиком, т.о. 1-й бит данных всегда будет принят верно.
На каждый последующий бит данных действует смещение в разность частот (10%) для 5-N-2 имеем 40% отклонение для 6-N-2 - 50%.

ИМХО Вы все же занижаете требования. Как правило УАРТ при считьывании бита оцениваются три центральные выборки и мажорирование результатов, поэтому при длинном фрейме 10бит (без паритета) ( 1+8+1) 10% многовато. Об этом, кстати, указано в DS на USART на любой МК AVR ( пример: ATmega128 таблицы 75 и 76).

[defunct]

ИМХО Вы все же занижаете требования.

Нисколько, я рассматривал предельные возможности на стандартных 5-ти битовых посылках (5-N-2).

Как правило УАРТ при считьывании бита оцениваются три центральные выборки и мажорирование результатов, поэтому при длинном фрейме 10бит (без паритета) ( 1+8+1) 10% многовато. Об этом, кстати, указано в DS на USART на любой МК AVR ( пример: ATmega128 таблицы 75 и 76).

Не буду спорить насчет 8-N-1 - для такого включения 10% многовато.

Но если есть еще и обратная синхронизация ...назовем это суперсинхронным интерфейсом?

Вы же работали с памятью асинхронно TEST / READY.
зачем же изобретать новые названия, когда для квитирования уже существует название - асинхронный
только в МК таких интерфейсов (с квитированием от приемника) нет. Скажете а как же ACK в I2C?
Это немного ни то, ACK от слейва в I2C формируется как обычный бит данных, он не может ускорить или замедлить процесс приема/передачи (повлиять на скважность клока).

[VladimirYU]

А вот Манчестер к какому правильно отнести интерфейсу синхронному или асинхронному? Что думают коллеги.

[Dog Pawlowa]

зачем же изобретать новые названия, когда для квитирования уже существует название - асинхронный
только в МК таких интерфейсов (с квитированием от приемника) нет.

Хм, что такое МК? Помните 8080+8255? Это можно отнести к МК или уже все?
Так вот, 8255 в режиме 2 обеспечивала аппаратно прямую (от передатчика в приемник) и обратную (от приемника в передатчик) синхронизацию.
Надеюсь, мой склероз меня не опозорит

[defunct]

Хм, что такое МК? Помните 8080+8255? Это можно отнести к МК или уже все?

МК - это однокристалка, с набортной памятью и набортной периферией + шинами памяти опционально, готовая система в одном корпусе.
8080 это все же МП, т.к. нет набортной памяти/периферии, и наружу выведен local bus, разработчику предоставляется возможность самому подобрать "чип-сет" под свою систему.

Так вот, 8255 в режиме 2 обеспечивала аппаратно прямую (от передатчика в приемник) и обратную (от приемника в передатчик) синхронизацию.
Надеюсь, мой склероз меня не опозорит

8255 со стороны подключения к CPU я бы сказал имеет асинхронный интерфейс, за счет наличия RD.

[_dem]

( UART 8N1- асинхронные кадры, но биты в пределах кадра-синхронны).

Добавьте к UART сигнал CLK, как это делают в ISO смарт-картах, и вы получите уже синхронный интерфейс т.е. USRT

[Dog Pawlowa]

8255 со стороны подключения к CPU я бы сказал имеет асинхронный интерфейс, за счет наличия RD.

Хм, при записи - синхронный (WR от МП синхронизирует данные от МП), а при чтении - несинхронный?
Наверное, нельзя вообще рассматривать синхронность/асинхронность в применении к параллельным интерфейсам и шинам - там всегда есть клок, а откуда и куда - неважно.

[ILYAUL]

Задача
Имеется микроконтроллер (МК) как представлено на прикрепленной картинке

МК должен начать принимать информацию от Арбитра после того как на С1 появится 1-ный сигнал.
После этого появится 8 1-ных сигналов на С2.
По этим сигналам через DATA МК должен принять от Арбитра байт (последовательно).

Если значение байта равно 98 (это адрес МК среди других МК) МК должен подать Арбитру через DATA байт со значением 80 (это обозначает что МК "ГОТОВ" принимать информацию).

После этого МК получит от Арбитра по DATA последовательность бит (информацию какую-то), завершающуюся последовательностью "конец передачи".

---------
Вопрос:

Я не понимаю как должна происходить синхронизация МК с Арбитром.

- когда МК должен подавать обратно "ГОТОВ": после появления единички на С1?
- как МК поймёт, что Арбитр уже начал посылать ему информацию. В какой момент он должен начать её принимать?

Синхронный режим всегда требует наличие CLK дабы раделять биты данных
Ассинхронный требует наличие маркеров начала и конца передачи данных и использует внутренную синхронизацию приемника

Ваша задачка не имеет логического решения .
Даже , если производить запуск приёма по C2 вы врядли различите биты информации , кроме случая меандра. Т.е если передается чисдо 0x55 или 0xAA

Если это Ваш случай - то проблема решаема

[defunct]

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

Ну почему же
В современных чипсетах к примеру доступ к памяти на одной частоте, а к процессору на другой. Есть повод для асинхронности.
Асинхронно это когда клок ведущего устройства регулируется ведомым устройством. И это хорошо, т.к. скорость ограничивается не какими-то установками клока ведущего устройства, а предельными возможностями ведомого.

[ILYAUL]

Ну почему же
........... а предельными возможностями ведомого.

Ну не всегда так - иногда и линия полное дер... , а приёмник может работать и на более высокой частоте чем передатчик

[Dog Pawlowa]

Ну почему же
...
Асинхронно это когда клок ведущего устройства регулируется ведомым устройством.
...

Нет уж, стоп, это отход от определения, найденного в инете! Консенсус был достигнут, не стоит его размывать опять! Там ничего про регулировку не говорилось.

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

[ILYAUL]

Нет уж, стоп, это отход от определения, найденного в инете! Консенсус был достигнут, не стоит его размывать опять! Там ничего про регулировку не говорилось.

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

Да его никто и не размывает. Просто существует протокол обмена DUPLEX по RS-232 где передатчик получает от приёмника свои же отосланные данные и если они не совпадают - снижает частоту передачи

[Dog Pawlowa]

Да его никто и не размывает. Просто существует протокол обмена DUPLEX по RS-232 где передатчик получает от приёмника свои же отосланные данные и если они не совпадают - снижает частоту передачи

Ну, мы в такие высокие протоколы не заглядываем, ограничиваясь передачей одного кванта информации.

[defunct]

Нет уж, стоп, это отход от определения, найденного в инете! Консенсус был достигнут, не стоит его размывать опять! Там ничего про регулировку не говорилось.

Да отход за рамки интерфейсов МК. Но отошел не я, а Вы говоря о всех параллельных интерфейсах.

Ну не всегда так - иногда и линия полное дер... , а приёмник может работать и на более высокой частоте чем передатчик

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

[svs39]

Синхронный режим всегда требует наличие CLK дабы раделять биты данных

Синхронный( НЕ СИНХРОНИЗИРОВАННЫЙ, а синхронный) способ передачи -передача непрерывно с постоянной скоростью. Для синхронного способа не нужна отдельная цепь СLK (сигнал синхронизации). Этот сигнал формирует приемник и производит его автоподстройку по моментам переключения бит данных. Для исключения возможности потери фазы при длительном отсутствии изменений в данных их вводят искусственно (рекуренты. бит-стаффинг). Такой способ обеспечивает более высокую проп.способность по сравнению со стартстопным типа UART.