Jump to content

    

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

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

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

 

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

 

 

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

 

Share this post


Link to post
Share on other sites
Хоть до этого пока далековато

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

 

Share this post


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

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

Share this post


Link to post
Share on other sites
что он ошибся, но передача будет сорвана.

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

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

 

Не Вы одна

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

Share this post


Link to post
Share on other sites
Стало не так одиноко...
Примите ещё меня в компанию. :rolleyes:

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

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

 

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

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

 

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

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

 

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

Edited by Smen

Share this post


Link to post
Share on other sites
P.S.: А на СИ писАть под ПИК12 - жесть. :wacko:

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

Share this post


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

 

 

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

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

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

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

 

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

 

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

Места нет.

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

 

Edited by A. Fig Lee

Share this post


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

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

 

 

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

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

Share this post


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

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

 

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

 

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

 

Share this post


Link to post
Share on other sites

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

Edited by Tarbal

Share this post


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

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

 

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

Share this post


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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Edited by rx3apf

Share this post


Link to post
Share on other sites

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

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

 

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

 

 

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

 

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

 

Share this post


Link to post
Share on other sites
Ксати если делать софтверный UART , то я прав насчет кварца :)

 

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

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this