Перейти к содержанию
    

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

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

Вот только не пойму зачем им такие хитрые реализации, свои протоколы - стандартных не хватает ?

В той же меге 2-х проводной присутствует...

 

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

 

C1 это CS

C2 это CLK

Data - 2-х направленая шина данных.

 

Анатолий.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Думаю не так! Синхронный способ передачи -передача непрерывно с постоянной скоростью(HDLC),

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Вот такое определение синхронных интерфейсов предлагается в статье 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.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот такое определение синхронных интерфейсов предлагается в статье 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 практически прав, за исключением одной мелочи, которая и подтолкнула меня к поискам истины :)

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

Угу, синхронизация от передатчика к приемнику несомненно важнее.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Нисколько, я рассматривал предельные возможности на стандартных 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 формируется как обычный бит данных, он не может ускорить или замедлить процесс приема/передачи (повлиять на скважность клока).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

только в МК таких интерфейсов (с квитированием от приемника) нет.

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

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

Надеюсь, мой склероз меня не опозорит :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

МК - это однокристалка, с набортной памятью и набортной периферией + шинами памяти опционально, готовая система в одном корпусе.

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

 

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

Надеюсь, мой склероз меня не опозорит :)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Хм, при записи - синхронный (WR от МП синхронизирует данные от МП), а при чтении - несинхронный?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Задача

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

 

МК должен начать принимать информацию от Арбитра после того как на С1 появится 1-ный сигнал.

После этого появится 8 1-ных сигналов на С2.

По этим сигналам через DATA МК должен принять от Арбитра байт (последовательно).

 

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

 

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

 

---------

Вопрос:

 

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

 

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

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

 

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

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

 

Ваша задачка не имеет логического решения .

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ну почему же :)

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну почему же :)

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

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну почему же :)

...

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

...

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...