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

Передача данных с PIC12F679 в ПК

А там старт и стоп бит между байтами. которые имеют разную полярность.

Как только выполз за фрейм, вместо старта получишь стоп или наоборот.

 

B другом порядке стоп, а за ним старт, а потом восемь бит. Kак только выполз за фрейм вместо старта получишь первый нулевой бит из данных. До стопа еще 8 бит.

 

 

Хорошо еще если разрешено прерывание Frame Error. Его редко обрабатывают. Возникнет прерывание и приемник узнает, что он ошибся, но передача будет сорвана.

 

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


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

Хоть до этого пока далековато

А Вы можете боле менее грамотным техническим языком описать в чем заключается главное на текущий момент Ваше затруднение с этим проектом?

 

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


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

Значит я одна такая бестолковая? Всегда думала, что допуска на частоту около пары процентов достаточно для такой короткой посылки... Как-то работает у меня до 115200. Просто везет?

Не Вы одна :) Устройство на ATtiny12 прекрасно работает без кварца (не было под рукой) - правда на 9600, там больше и не надо. Ещё однажды потребовалось организовать отладочный вывод из ATtiny13 - на 19200 всё ОК.

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


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

что он ошибся, но передача будет сорвана.

Какой бы хороший кварц (ы) Вы ни поставили, все равно будет "наползать"... Только позже.

Последовательный порт - асинхронный по определению и добиваться излишнего синхронизма не нужно. Для этого есть синхронные протоколы.

 

Не Вы одна

Стало не так одиноко...

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


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

Стало не так одиноко...
Примите ещё меня в компанию. :rolleyes:

Реализовывал на ПИКе от внутреннего генератора аппаратный УАРТ до 125 кбит/сек. Испытывали при - 60 грд. Всё работало без сбоев.

Правда, ПИК был посовременнее.

 

Насчёт пакетов, так всё зависит от реализации УАРТа (а точнее, сколько и когда делать выборки, в конечном итоге, от быстродействия МК).

Нарисуйте осциллограммы, и сами убедитесь.

 

Програмно, на ПИКе, с кварцем, реально получал 31 250 (на современных можно и поболее, но в них уже есть аппаратный).

На какой-нибудь Тиньке 45, такую скорость получил от внутреннего генератора (там ещё и ПЛЛка есть), и даже с запасом.

 

P.S.: А на СИ писАть под ПИК12 - жесть. :wacko:

Изменено пользователем Smen

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


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

P.S.: А на СИ писАть под ПИК12 - жесть. :wacko:

И в чём же жесть? И на чём надо писать под PIC12?

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


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

B другом порядке стоп, а за ним старт, а потом восемь бит. Kак только выполз за фрейм вместо старта получишь первый нулевой бит из данных. До стопа еще 8 бит.

 

 

Хорошо еще если разрешено прерывание Frame Error. Его редко обрабатывают. Возникнет прерывание и приемник узнает, что он ошибся, но передача будет сорвана.

"Как только вместо старта получишь нулевой бит из данных",

значит вместо стопа предыдущего байта придет старт этого, что есть ошибка.

Или туда или сюда фрейм сдвинется, это будет детектед

 

Вот вот этим еджем стоп/старт и будет уарт синхронизироватся.

 

И в чём же жесть? И на чём надо писать под PIC12?

Места нет.

"Надо на ассемблере".

 

Изменено пользователем A. Fig Lee

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


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

А вы попробуйте посылать пакеты по 200 байт или длиннее, да так, чтобы после стоп бита сразу шел старт бит и чтобы был один стопбит, а не два. В одном случае и при определенной температуре это может и заработает, но с перебоями. Я всегда отвергал решения непригодные для массового производства.

RC-генератор, 921600, блоки до 64К. Никаких проблем. Что я делаю не так ?

 

 

даже когда байты идут подряд и передатчик передает быстрее чем принимает приемник?

Это никоим образом не мешает.

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


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

Разные бывают системы. Зачастую надо выжать как можно более высокую скорость передачи, а периферийное устройство достигло уже своего потолка в 115200, а лишний стоп бит отнимает 10% времени.

Вы начинаете вдаваться в частные случаи. Ранее вы говорил о принципиальной невозможности такой реализации. Но с 1% процентом погрешности будет работать даже с одним стоп битом.

 

даже когда байты идут подряд и передатчик передает быстрее чем принимает приемник?

 

Какая разница. Приемник все равно принимает информацию побайтно, и синхронизируется со старт битом каждый раз заново. Считаете вы неправильно.

 

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


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

Возможно я и заблуждаюсь. Видимо для массового производства мы никогда не рисковали и делали наверняка. Наверное у меня и сложилась такая "аксиома". Спасибо за информацию. Буду смотреть на вопрос под другим углом :)

Изменено пользователем Tarbal

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


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

А Вы можете боле менее грамотным техническим языком описать в чем заключается главное на текущий момент Ваше затруднение с этим проектом?

Моё затруднение с этим проектом связано в том, что я ни разу ничего с МК в ПК не передавал. Пока в принципе всё понятно, хочу для начала схему в Альтиуме составить и платку развести, ну а потом видно будет. Изначальный вопрос заключался в том, сколько контактов подключить. На него ответили.

 

Да, можете скинуть библиотеку компонентов под альтиум, где есть CP2102???

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


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

Последовательный порт - асинхронный по определению и добиваться излишнего синхронизма не нужно. Для этого есть синхронные протоколы.

 

Как говорил мой преподаватель оптики с точностью до наоборот. :)

 

Он не поэтому асинхронный. Асинхронный он потому, что у него нет синхроимпильсов как есть в SPI, I2C или Microwire. А значит в отличие от них он как раз и должен придерживаться строгих временнЫх рамок.

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


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

А эти "строгие временные рамки" всего лишь ограничение на разбег в пределах байта (одного байта !), чтобы момент семплирования не слишком далеко уполз. Двухпроцентной точности битовой скорости хватает гарантированно.

Изменено пользователем rx3apf

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


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

Вспомнил истоки своего заблуждения. Когда я писал в 1995 софтверный UART на 16С71, там за 104 микросекунды (длина бита для 9600) надо было делать обработку бита и возможно принимать решения. Самплировать 16 раз за бит как это делается в хардверных UARTах возможности не было. Кажадая инструкция 1 микросекунду занимает. Кстати у меня есть наверное где-то софтверный UART для 16C71 не знаю насколько его ассемблер отличается от PIC12.

Ксати если делать софтверный UART , то я прав насчет кварца :)

 

Лихо я выкрутился?

 

 

А эти "строгие временные рамки" всего лишь ограничение на разбег в пределах байта (одного байта !), чтобы момент семплирования не слишком далеко уполз. Двухпроцентной точности битовой скорости хватает гарантированно.

 

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

 

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


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

Ксати если делать софтверный UART , то я прав насчет кварца :)

 

Лихо я выкрутился?

Не очень. Зачем программному нужен кварц? Не вижу никакой причины.

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

Мне, например, так не кажется. Абсолютно всё подразумевает наличие временных рамок. Кроме вечности.

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

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


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

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

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

Гость
Ответить в этой теме...

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

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

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

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

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

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