Несколько страниц назад довольно невнятно и совсем незнаючи задавал вопрос про UART. Слегка разобрался. Теперь переформулирую его более конкретно. (+) («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Разработка, производство и продажа радиоэлектронной аппаратуры

| Карта сайта | Пишите нам | В избранное

Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Микроконтроллеры и их применение»

Несколько страниц назад довольно невнятно и совсем незнаючи задавал вопрос про UART. Слегка разобрался. Теперь переформулирую его более конкретно. (+)

Отправлено mayn 19 июня 2007 г. 02:22

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

Я в качестве примера передаю, скажем, байт 0x41 (A, c 5 нулями).
8 байт, нет проверки на четность, 1 стоп бит. При этом у меня цепочка принимаемых компом бит периодична с 6 нулями в периоде (5 нулей в символе + 1 старт бит). Ну, конечно, я и получал цепочку с одним из 6 символов (то есть либо AAAAA..., либо TTTTT... и т.д.), в зависимости от того, какой из нулей будет "опознан" как старт бит.

+ при этом в некоторых случаях будет ошибка стоп бита (0, а не 1), но в некоторых (в данном случае >1) случаях даже ошибки не будет, т.е. определить цепочку AAAAA... как правилиную однозначно не получится.

Замечу, что если программу чтения с COM порта запустить до пересылки данных, то комп принимает то, что надо, что подтверждает правильность и программы чтения с COM порта, и программы в микроконтроллере, которая посылает данные

Составить ответ | Вернуться на конференцию

Ответы

Да все это хорошо, а как физически реализован обмен (т.е. RS232, RS485 и.т.д), длина линии. Может дело в элементарных помехах или в неверном согласовании? — Mk - 51 (19.06.2007 11:24:58 195.28.39.114, пустое)
День УАРТов :) Мне позывы сотворить непрерывный поток непонятны - ну ладно, поймал байтовую синхронизацию, а смысловую синхронизацию как поймать? Или в этом потоке постоянно передается одна переменная размером один байт? — Vladimir Ljaschko (19.06.2007 10:59:57 194.158.204.49, пустое)
- Примените байт-стаффинг, н вроде как в SLIP. Поймаете на раз начало пакета. — SM (19.06.2007 11:10:12 80.92.255.53, пустое)
  - +1 Не раз писал - если ещё и в винде в ВСВ прописать SLIP-овский FEND как EventCharacter - очень удобно работать. — ReAl (19.06.2007 11:22:57 193.111.248.46, пустое)
Пускай комп передаст break, железяка его поймает, отдохнет чуток, а комп потом поймает синхру. — SM (19.06.2007 10:13:33 80.92.255.53, пустое)
А организовать паузу в потоке железки можно? пауза длиной больше байта убьет проблему насмерть — pau62 (19.06.2007 09:13:55 88.86.64.165, пустое)
Ответ: — rezident (19.06.2007 02:33:44 77.43.137.96, 539 байт)
- Просто хочется, чтобы микроконтроллнр был как бы главным и работал непрерывно, а некие отладочные, информационные и т.п. сообщения выводились программой на компе по желанию (при ее загрузке). Я, в принципе, рассматриваю и вариант посылки запроса микроконтроллеру на передачу данных, но, все-таки, это некая заморочка — mayn (19.06.2007 02:41:16 87.245.133.19, пустое)
  - Если хочется, то пускай работает. — rezident (19.06.2007 02:54:28 77.43.137.96, 377 байт, ссылка)
    - Я вот тут на досуге смоделировал передачу по протоколу WAKE и получил фатальную ошибку, неустранимую... — Mk - 51 (19.06.2007 07:44:31 89.178.61.209, 461 байт)
      - Да, здорово туплю!!! Вообщем вопрос снят! — Mk - 51 (19.06.2007 09:53:47 195.28.39.114, пустое)
Хоть данные и непрерывные, но полезно периодически перерывы все-таки делать ;) Короткие - длительностью чуть больше интервала передачи байта. Это снимет все проблемы с синхронизацией... — Гудвин (19.06.2007 02:27:2 195.133.109.197, пустое)
- В принципе, хороший вариант:) Правда, если делать паузы между n байтами, то в худшем случае можно потерять n байт до первой паузы. Получается компромисс между скоростью передачи(< при меньшем n) и задержкой получения правильных, надежных данных (> при большем n), хотя это не проблема. Принимаются предложения и других вариантов:) — mayn (19.06.2007 02:59:27 87.245.133.19, пустое)
  - Какой еще компромисс? Нефиг делать систему без резерва по скорости передачи данных. — Vladimir Ljaschko (19.06.2007 09:21:47 194.158.204.49, пустое)
  - Не надо изобретать велосипед.... — Mk - 51 (19.06.2007 08:00:5 89.178.61.209, 727 байт)
    - Чел озабочен аппаратной синхронизацией usart при произвольном подключении к сплошному потоку, а вы ему про байт стаффинг впрягаете... — Гудвин (19.06.2007 09:00:18 195.133.109.197, пустое)
      - А вот вы ответте, какая может быть проблема с аппаратной синхронизацией при исправном порте и правильных установках скоростей! Не встречал! Вот когда снхронизации от таймеров (или еще там от чего, типа битрейтгенераторов) в UART МК неверные или неисправный COM в компе... Искать причину в этом надо. — Mk - 51   (19.06.2007 10:02:1 195.28.39.114, пустое)
        
        Правда, если товарищ в компе поставил два стоп-бита, а в МК один, и байты идут с интервалом в стоп-бит... Ну, тогда... — Mk - 51   (19.06.2007 10:05:34 195.28.39.114, пустое)
        
        В сплошном потоке (без пауз, длительностью больше интервала передачи одного байта) никакой uart не синхронизируется... — Гудвин   (19.06.2007 10:19:12 195.133.109.197, пустое)
        
        Это верно. Нужны паузы между символами. Хотя на практике обычно UART довольно быстро синхронизируется при случайном потоке данных, но в теории время синхронизации может быть бесконечным :) — Леонид Иванович   (19.06.2007 12:51:5 87.252.227.57, пустое)
        
        Если в МК поставите два стоп-бита (надо полагать, что вы знаете когда вырабатывается прерывание Tx_end), а в компе один стоп-бит, можете до посинения ждать рассинхронизации в любом сплошном потоке. — Mk - 51   (19.06.2007 10:47:40 195.28.39.114, пустое)
        
        Суть не меняется - вы так-же до посинения можете ждать синхронизацию... — Гудвин   (19.06.2007 11:43:26 195.133.109.197, пустое)
        
        А ведь что интересно, есть у меня такое устройство. Монитор напряжения. Шарашит постоянно и, о чудо (судя по вашим постам), может месяцами на компом контролироваться. Для справки пауза между байтами 4 бита, пакет 41 байт, скорость 1024 б/с. (RS МК программный). А контрольный комп на Athlon XP 2500+ и VIA KT-600 с двумя UART. Так, что про паузу в байт и потерю синхронизации сказка мне не нравится. — Mk - 51   (19.06.2007 11:58:3 195.28.39.114, пустое)
        
        Сказка ложь, да вней намек... Вы начните прием посередине байта... — Гудвин   (19.06.2007 12:03:44 195.133.109.197, пустое)
        
        Мил человек, если Вы думеете, что я с осцилоскопом вычисляю, когда включить прогрмму PC, вынужден Вас разочаровать. Дело тут решается очень просто, при неполучении пакета в течении 2 с. идет переинициализация порта. Ну и ... — Mk - 51   (19.06.2007 12:15:59 195.28.39.114, пустое)
        
        А теперь остановимся и внимательно перечитаем первый пост... — Гудвин   (19.06.2007 12:49:10 195.133.109.197, пустое)
        
        Ну, так и я про то же, не в МК ему сразу лезть надо, а грамотно программу на писюке написать, продумать, где и чем пожертвовать, может потеря некоторых пакетов - не проблема, а может полностью пересмотреть весь протокол. Но пауза в > 1 байта совсем не обязательна. Именно это я и хочу сказать. — Mk - 51   (19.06.2007 13:21:44 195.28.39.114, пустое)
        
        Если вам и этого мало, эффект можно усилить введя 9-м битом единицу с двумя стопами, а на компе 8-бит с одним стопом. — Mk - 51   (19.06.2007 10:49:59 195.28.39.114, пустое)
        
        Не забывайте :) — Vladimir Ljaschko   (19.06.2007 10:17:5 194.158.204.49, пустое, ссылка)
        
        Спасибо, не забуду! — Mk - 51   (19.06.2007 10:50:56 195.28.39.114, пустое)