Tarbal 4 3 октября, 2013 Опубликовано 3 октября, 2013 · Жалоба А там старт и стоп бит между байтами. которые имеют разную полярность. Как только выполз за фрейм, вместо старта получишь стоп или наоборот. B другом порядке стоп, а за ним старт, а потом восемь бит. Kак только выполз за фрейм вместо старта получишь первый нулевой бит из данных. До стопа еще 8 бит. Хорошо еще если разрешено прерывание Frame Error. Его редко обрабатывают. Возникнет прерывание и приемник узнает, что он ошибся, но передача будет сорвана. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
O.L. 0 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба Хоть до этого пока далековато А Вы можете боле менее грамотным техническим языком описать в чем заключается главное на текущий момент Ваше затруднение с этим проектом? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RabidRabbit 0 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба Значит я одна такая бестолковая? Всегда думала, что допуска на частоту около пары процентов достаточно для такой короткой посылки... Как-то работает у меня до 115200. Просто везет? Не Вы одна :) Устройство на ATtiny12 прекрасно работает без кварца (не было под рукой) - правда на 9600, там больше и не надо. Ещё однажды потребовалось организовать отладочный вывод из ATtiny13 - на 19200 всё ОК. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tanya 4 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба что он ошибся, но передача будет сорвана. Какой бы хороший кварц (ы) Вы ни поставили, все равно будет "наползать"... Только позже. Последовательный порт - асинхронный по определению и добиваться излишнего синхронизма не нужно. Для этого есть синхронные протоколы. Не Вы одна Стало не так одиноко... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Smen 1 4 октября, 2013 Опубликовано 4 октября, 2013 (изменено) · Жалоба Стало не так одиноко...Примите ещё меня в компанию. :rolleyes: Реализовывал на ПИКе от внутреннего генератора аппаратный УАРТ до 125 кбит/сек. Испытывали при - 60 грд. Всё работало без сбоев. Правда, ПИК был посовременнее. Насчёт пакетов, так всё зависит от реализации УАРТа (а точнее, сколько и когда делать выборки, в конечном итоге, от быстродействия МК). Нарисуйте осциллограммы, и сами убедитесь. Програмно, на ПИКе, с кварцем, реально получал 31 250 (на современных можно и поболее, но в них уже есть аппаратный). На какой-нибудь Тиньке 45, такую скорость получил от внутреннего генератора (там ещё и ПЛЛка есть), и даже с запасом. P.S.: А на СИ писАть под ПИК12 - жесть. Изменено 4 октября, 2013 пользователем Smen Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Herz 4 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба P.S.: А на СИ писАть под ПИК12 - жесть. И в чём же жесть? И на чём надо писать под PIC12? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 4 октября, 2013 Опубликовано 4 октября, 2013 (изменено) · Жалоба B другом порядке стоп, а за ним старт, а потом восемь бит. Kак только выполз за фрейм вместо старта получишь первый нулевой бит из данных. До стопа еще 8 бит. Хорошо еще если разрешено прерывание Frame Error. Его редко обрабатывают. Возникнет прерывание и приемник узнает, что он ошибся, но передача будет сорвана. "Как только вместо старта получишь нулевой бит из данных", значит вместо стопа предыдущего байта придет старт этого, что есть ошибка. Или туда или сюда фрейм сдвинется, это будет детектед Вот вот этим еджем стоп/старт и будет уарт синхронизироватся. И в чём же жесть? И на чём надо писать под PIC12? Места нет. "Надо на ассемблере". Изменено 4 октября, 2013 пользователем A. Fig Lee Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба А вы попробуйте посылать пакеты по 200 байт или длиннее, да так, чтобы после стоп бита сразу шел старт бит и чтобы был один стопбит, а не два. В одном случае и при определенной температуре это может и заработает, но с перебоями. Я всегда отвергал решения непригодные для массового производства. RC-генератор, 921600, блоки до 64К. Никаких проблем. Что я делаю не так ? даже когда байты идут подряд и передатчик передает быстрее чем принимает приемник? Это никоим образом не мешает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба Разные бывают системы. Зачастую надо выжать как можно более высокую скорость передачи, а периферийное устройство достигло уже своего потолка в 115200, а лишний стоп бит отнимает 10% времени. Вы начинаете вдаваться в частные случаи. Ранее вы говорил о принципиальной невозможности такой реализации. Но с 1% процентом погрешности будет работать даже с одним стоп битом. даже когда байты идут подряд и передатчик передает быстрее чем принимает приемник? Какая разница. Приемник все равно принимает информацию побайтно, и синхронизируется со старт битом каждый раз заново. Считаете вы неправильно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 4 октября, 2013 Опубликовано 4 октября, 2013 (изменено) · Жалоба Возможно я и заблуждаюсь. Видимо для массового производства мы никогда не рисковали и делали наверняка. Наверное у меня и сложилась такая "аксиома". Спасибо за информацию. Буду смотреть на вопрос под другим углом :) Изменено 4 октября, 2013 пользователем Tarbal Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vovken1997 0 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба А Вы можете боле менее грамотным техническим языком описать в чем заключается главное на текущий момент Ваше затруднение с этим проектом? Моё затруднение с этим проектом связано в том, что я ни разу ничего с МК в ПК не передавал. Пока в принципе всё понятно, хочу для начала схему в Альтиуме составить и платку развести, ну а потом видно будет. Изначальный вопрос заключался в том, сколько контактов подключить. На него ответили. Да, можете скинуть библиотеку компонентов под альтиум, где есть CP2102??? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба Последовательный порт - асинхронный по определению и добиваться излишнего синхронизма не нужно. Для этого есть синхронные протоколы. Как говорил мой преподаватель оптики с точностью до наоборот. :) Он не поэтому асинхронный. Асинхронный он потому, что у него нет синхроимпильсов как есть в SPI, I2C или Microwire. А значит в отличие от них он как раз и должен придерживаться строгих временнЫх рамок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 4 октября, 2013 Опубликовано 4 октября, 2013 (изменено) · Жалоба А эти "строгие временные рамки" всего лишь ограничение на разбег в пределах байта (одного байта !), чтобы момент семплирования не слишком далеко уполз. Двухпроцентной точности битовой скорости хватает гарантированно. Изменено 4 октября, 2013 пользователем rx3apf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба Вспомнил истоки своего заблуждения. Когда я писал в 1995 софтверный UART на 16С71, там за 104 микросекунды (длина бита для 9600) надо было делать обработку бита и возможно принимать решения. Самплировать 16 раз за бит как это делается в хардверных UARTах возможности не было. Кажадая инструкция 1 микросекунду занимает. Кстати у меня есть наверное где-то софтверный UART для 16C71 не знаю насколько его ассемблер отличается от PIC12. Ксати если делать софтверный UART , то я прав насчет кварца :) Лихо я выкрутился? А эти "строгие временные рамки" всего лишь ограничение на разбег в пределах байта (одного байта !), чтобы момент семплирования не слишком далеко уполз. Двухпроцентной точности битовой скорости хватает гарантированно. Согласитесь, что по сути я прав и слово асинхронный в названии подразумевает наличие временных рамок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Herz 4 4 октября, 2013 Опубликовано 4 октября, 2013 · Жалоба Ксати если делать софтверный UART , то я прав насчет кварца :) Лихо я выкрутился? Не очень. Зачем программному нужен кварц? Не вижу никакой причины. Согласитесь, что по сути я прав и слово асинхронный в названии подразумевает наличие временных рамок. Мне, например, так не кажется. Абсолютно всё подразумевает наличие временных рамок. Кроме вечности. Асинхронный - значит не нуждающийся в синхронизации. Теоретически, мог бы вообще с произвольной скоростью работать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться