aesok 0 27 мая, 2008 Опубликовано 27 мая, 2008 · Жалоба Как по мне , то больше на TWI смахивает - по дата-проводу гоняются данные туда/сюда по тактированию с 2-го провода.. Вот только не пойму зачем им такие хитрые реализации, свои протоколы - стандартных не хватает ? В той же меге 2-х проводной присутствует... Или всё таки идея - замучать студента в конец ?? C1 это CS C2 это CLK Data - 2-х направленая шина данных. Анатолий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
svs39 0 27 мая, 2008 Опубликовано 27 мая, 2008 · Жалоба Господа, есть есть сигнал, по стробу которого происходит передача данных - то синхронный. В противном случае - асинхронный :) Что-то всем смешно :):):) Думаю не так! Синхронный способ передачи -передача непрерывно с постоянной скоростью(HDLC), асинхронный- остальное( UART 8N1- асинхронные кадры, но биты в пределах кадра-синхронны). Для синхронного способа не нужен сигнал синхронизации, скорее он нужен для асинхронного ( в случае UART- самосинхронизация) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 27 мая, 2008 Опубликовано 27 мая, 2008 · Жалоба Давайте чтобы поставить точку в определении синхронных/асинхронных интерфейсов обратимся к интернету :) Вот такое определение синхронных интерфейсов предлагается в статье 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. Заменить "приемник сообщает передатчику, что он принял данные" (что есть составной частью асинхронных интерфейсов) на "передатчик генерит клок для приемника, приемник(ки) должен успеть в рамках этого клока принять/передать данные", и все станет на свои места. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 28 мая, 2008 Опубликовано 28 мая, 2008 · Жалоба Вот такое определение синхронных интерфейсов предлагается в статье 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 0 28 мая, 2008 Опубликовано 28 мая, 2008 · Жалоба 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 0 28 мая, 2008 Опубликовано 28 мая, 2008 · Жалоба ИМХО Вы все же занижаете требования. Нисколько, я рассматривал предельные возможности на стандартных 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 0 28 мая, 2008 Опубликовано 28 мая, 2008 · Жалоба А вот Манчестер к какому правильно отнести интерфейсу синхронному или асинхронному? Что думают коллеги. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 28 мая, 2008 Опубликовано 28 мая, 2008 · Жалоба зачем же изобретать новые названия, когда для квитирования уже существует название - асинхронный :) только в МК таких интерфейсов (с квитированием от приемника) нет. Хм, что такое МК? Помните 8080+8255? Это можно отнести к МК или уже все? Так вот, 8255 в режиме 2 обеспечивала аппаратно прямую (от передатчика в приемник) и обратную (от приемника в передатчик) синхронизацию. Надеюсь, мой склероз меня не опозорит :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 28 мая, 2008 Опубликовано 28 мая, 2008 · Жалоба Хм, что такое МК? Помните 8080+8255? Это можно отнести к МК или уже все? МК - это однокристалка, с набортной памятью и набортной периферией + шинами памяти опционально, готовая система в одном корпусе. 8080 это все же МП, т.к. нет набортной памяти/периферии, и наружу выведен local bus, разработчику предоставляется возможность самому подобрать "чип-сет" под свою систему. Так вот, 8255 в режиме 2 обеспечивала аппаратно прямую (от передатчика в приемник) и обратную (от приемника в передатчик) синхронизацию. Надеюсь, мой склероз меня не опозорит :) 8255 со стороны подключения к CPU я бы сказал имеет асинхронный интерфейс, за счет наличия RD. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_dem 0 28 мая, 2008 Опубликовано 28 мая, 2008 · Жалоба ( UART 8N1- асинхронные кадры, но биты в пределах кадра-синхронны). Добавьте к UART сигнал CLK, как это делают в ISO смарт-картах, и вы получите уже синхронный интерфейс :) т.е. USRT :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба 8255 со стороны подключения к CPU я бы сказал имеет асинхронный интерфейс, за счет наличия RD. Хм, при записи - синхронный (WR от МП синхронизирует данные от МП), а при чтении - несинхронный? Наверное, нельзя вообще рассматривать синхронность/асинхронность в применении к параллельным интерфейсам и шинам - там всегда есть клок, а откуда и куда - неважно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба Задача Имеется микроконтроллер (МК) как представлено на прикрепленной картинке МК должен начать принимать информацию от Арбитра после того как на С1 появится 1-ный сигнал. После этого появится 8 1-ных сигналов на С2. По этим сигналам через DATA МК должен принять от Арбитра байт (последовательно). Если значение байта равно 98 (это адрес МК среди других МК) МК должен подать Арбитру через DATA байт со значением 80 (это обозначает что МК "ГОТОВ" принимать информацию). После этого МК получит от Арбитра по DATA последовательность бит (информацию какую-то), завершающуюся последовательностью "конец передачи". --------- Вопрос: Я не понимаю как должна происходить синхронизация МК с Арбитром. - когда МК должен подавать обратно "ГОТОВ": после появления единички на С1? - как МК поймёт, что Арбитр уже начал посылать ему информацию. В какой момент он должен начать её принимать? Синхронный режим всегда требует наличие CLK дабы раделять биты данных Ассинхронный требует наличие маркеров начала и конца передачи данных и использует внутренную синхронизацию приемника Ваша задачка не имеет логического решения . Даже , если производить запуск приёма по C2 вы врядли различите биты информации , кроме случая меандра. Т.е если передается чисдо 0x55 или 0xAA Если это Ваш случай - то проблема решаема Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба Наверное, нельзя вообще рассматривать синхронность/асинхронность в применении к параллельным интерфейсам и шинам - там всегда есть клок, а откуда и куда - неважно. Ну почему же :) В современных чипсетах к примеру доступ к памяти на одной частоте, а к процессору на другой. Есть повод для асинхронности. Асинхронно это когда клок ведущего устройства регулируется ведомым устройством. И это хорошо, т.к. скорость ограничивается не какими-то установками клока ведущего устройства, а предельными возможностями ведомого. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба Ну почему же :) ........... а предельными возможностями ведомого. Ну не всегда так - иногда и линия полное дер... , а приёмник может работать и на более высокой частоте чем передатчик Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба Ну почему же :) ... Асинхронно это когда клок ведущего устройства регулируется ведомым устройством. ... Нет уж, стоп, это отход от определения, найденного в инете! Консенсус был достигнут, не стоит его размывать опять! :) Там ничего про регулировку не говорилось. Ведомое устройство не влияет на суть происходящего - прием данных, существующих на момент фронта сигнала записи (т.е. строба, который формируется мастером). А уж способы достижения валидности данных второстепенны и асинхронной сути не добавляют. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться