только начал работать с msp430f149. Что-то после AVR и 51-х грустно. Если не трудно, бросьте что-нибудь из примеров использования UART (на Си).

Посмотрите на сайте TI "Code Examples"
http://focus.ti.com/mcu/docs/generalconten...430_desres_code

Ну и прилагаю свои тексты, не судите строго.

не грусти, даже програмка есть, которая все пересчитает
лежит на этой страничке

Более точно можно посчитать значения регистров используя прилагаемые ниже экселевские файлы. Там можно поиграться битами UMCTL и посмотреть полученый результат.
А предлагаемая программа не дает такой возможности.

ModulationRegister.xls - исходный файл
ModRegister_vai.xls - немного подправленый мной, т.к. мой эксель не хотел понимать "вражьи" функции, примененные в исходном файле.

Чтоб не создавать новую тему, решил залать вопрос здесь

Есть сеть микроконтроллеров, канал связи - RS485
т.к. это полудуплекс, то необходимо управление трансмитером - прием/передача.

однако сложность в том чт опрерывание по передачи выставляется не когда передатчик пуст а раньше - когда пуст буфер передатчика.
Соответственно это прерывание мне бесполезно (я не могу здесь перевести трансмиттре на режим приема - еще передача идет)

я конечно выкрутился
вот даже пример


криво это выглядит
может я чего упустил и можно было сделать проще?
как , например в AVR, там есть флаги прывания по передачи как от "буфер пуст", так и от "передатчик пуст"

Это не есть хорошо. Лучше создавать свою тему со своим описанием.

Это не то чтобы криво, а просто неправильно. Нужно не только дождаться окончания передачи символа, но еще и выждать паузу, чтобы возможные помехи от переключения линии (при выключении передатчика) не были восприняты принимающим устройством как начало следующего символа. Пауза эта конечно же зависит от примененного протокола и линии связи. Какие-то протоколу чувствительны к этому, какие-то нет. "Растяжка" линии тоже очень способствует улучшению связи.
А паузы формируйте таймерами, как минимум один таймер есть в любом кристалле MSP430. Посчитайте требуемую паузу, необходимую для передачи символа на данной скорости и паузу достаточную для удержания линии после передачи и сразу же после записи в UxTXBUF последнего байта установите CCRx какого-нибудь таймера. Когда пауза окончится, то при возникновении прерывания от CCRx переключайте линию RS485 на прием. Прерывание от CCRx конечно же должно быть заранее разрешено.

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

Какой протокол связи используете?

Интерфейс RS485
протокол "Многопроцессорный формат с адресным битом"
данных 7 бит, 2 стоповых, скорость 115200.

вот интересно флаг "передатчик пуст" выставляется именно после того как выслан 2 стоповый бит?

Я не совсем про это спрашивал. Меня интересовал протокол верхнего уровня. Т.е. как быстро ведомый будет ответ передавать? Если ли какие-то символы начала и конца фрейма? Как реагирует ведомый на неверно принятый байт?
Например, в протоколе ModBus ASCII есть начало фрейма ":", окончание фрейма 0x0D и после этого передается символ готовности к приему 0x0A. Поэтому ведомый может передавать (если у него ответ уже готов) сразу же после приема символа 0x0A, следовательно ведущий должен освобождать линию сразу же после окончания передачи символа 0x0A.
В ModBus RTU конец фрейма определяется по паузе тишины длительностью 3.5 символа. Следовательно после передачи последнего символа фрейма ведущий должен удерживать линию как минимум в течение 3,5 символов, чтобы помеха от переключения передатчика или наведенная помеха на незанятую (свободную) линию не испортила весь фрейм.
В реальности для транспортной функции в протоколах связи для RS485 желательно реализовывать паузу для минимальной задержки ответа. Во время этой паузы будет происходить переключение линии с приема на передачу и обратно.
Все это делается для более устойчивой связи в условиях протяженных линий и сильных помех. Если же линии RS485 короткие и применены дополнительные растяжки линии, то наверное можно обойтись и без этих задержек.
P.S. флаг TXEPT устанавливается после выдвижения последнего бита в выбранном формате. Если был выбран формат с 2 стоп-битами, то после выдвижения второго стоп-бита.

Если про протокол верхнего уровня, то он у нас свободный
система наша, протокол наш.
пока остановились на таком варианте
мастер опрашивает модули по кругу
посылка мастера :
байт адреса (8ой бит 1) + байт команды (8ой бит 0)
если команда подразумевает чтения из модуля к мастеру то сразуже следует ответ модуля 2-5 байт (от 1 до 4 байт данных + CRC)
если команда - запись данных из мастера в устройство то следует еще 2-5 байт данных , и затем ответ модуля о доставке/ошибке посылки (1 байт)
Количество байт данных определяется командой

В реальной системе будет еще одно усовершенствование - т.к. бОльшую часть времени модули будут в режиме сна, а трансмитеры в режиме PowerDown
то что б не пропустить запрос мастера или модуля вводится однопроводная шина управления.
0 на шине управления - все трансмиеры в PowerDown. Если Модуль желает что б мастер его опросил он выставляем 1 на шине управления.Все модули переводят трансмитеры в режим чтения. Мастер циклически опрашивает модули, каждый из которых отвечает нужен ему запрос или нет. После с обмена с модулем, который послал запрос, шина управления переводтся в 0 - неактивное состояние. Все трансмитеры переводятся в режим PowerDown.

Простите если чего не понял, но зачем еще одна линия?
А нельзя сделать так?...
Допустим модуль спит, передатчик драйвера RS485 в модуле также спит, но линия RX микроконтроллера сконфгурирована как прерывание по фронту, когда начинается передача мастером- модули просыпаются, принимают данные, и т.д.

дело в том что трансмитер в режиме полного сна
т.е. не прием и не передача (приемник и передатчик управляются отдельными линиями)
в случае полоного PowerDownа на линии RX будет постоянная 1
сделано это ради экономии батарейки, трансмитер даже в режиме приема жрет на много больше чем в режиме PowerDown

Вот потому, что у вас нет "обрамления" фрейма, а также длина пакета не имеет фиксированного значения и нужно делать паузы между переключением направления драйвера RS485 и началом/окончанием передачи пакета в начале и в конце фрейма.

Пытаюсь реализовать обмен данными контроллера MSP430F133 и PC по COM-порту. Сейчас на другом форуме разбираемся с проблемами, связанными с программой, выполняющейся на компе (там разберусь и сюда переберусь).

Так вот, задали мне там вопрос вроде простой, а на самом деле коварный (ответа я не знаю ) - программный или аппаратный модуль UART в контроллере? Что скажете?

Извините если что то упустил, но.. Но если есть сетка с одним мастером, то он должен опрашивать все ведомые и дожидаться ответа от опрашиваемого. В случае не ответа в течении определенного времени, предпринемать необходимые действия. Иначе получается широковещательная передача без потверждения приема. Тогда можно использовать таймер после опустошения буфера и ждать ответа или истечения времени на ответ.

подскажите по uart

подскажите пожалуйста, какие уровни соответствуют логической 1 и 0 на выводах UART в MSP430.

лог.1 близка к питанию, лог.0 - к 0(Vss)
Более подробно на стр.27 документа slas272f.pdf для msp430x13x-14x-14x1.
Если Вы имеете ввиду логическое соответствие битов числа, загруженого в UxTXBUF напряжениям на выходе, то бит 1 соответствует лог.1 на выходе.

По RS485: что мешает принимать передоваемое и для контроля верноти пакета и для контроля его конца. Я так и сделал. Передавал текстом с 0х00 в конце.

VAI, спасибо. никак не мог найти.

Может ежли не секрет скажешь на каком форуме. Аналогичную задачку решаю.

Может ежли не секрет скажешь на каком форуме. Аналогичную задачку решаю.

не секрет - http://forum.sources.ru/

а что за задачка? и как успехи?

14 устройств на линии. PC - мастер. Со стороны PC прогу для работы с COM нормально написать не могу. Приём пришлось делать отдельным потоком.
Кто-нибудь ReadFileEx использовал?
p.s. Могу дать свой код MSP430f1xx UART
И прогу для отладки приёма-передачи со стороны PC

в чём проблема заключается? не получется работа именно с com-портом на РС или уже не идёт совместная работа с контроллером?

можно попробовать посмотреть исходники.

кстати, я ОЧЕНЬ много времени потратил на программную часть (вроде всё просто - у меня пока только учебная задача - байт отослать на контроллер, байт от него принять - а не получалось никак). проблема оказалась в железе - преобразователь уровня выдавал "левый" по уровню сигнал. так что рекомендую глянуть напряжение на ножках. сейчас вот переделываю.


ЗЫ. я чайник в этих делах пока что.

Основная проблема, это COM. А именно приём. Я обращаюсь к ReadFile и делаю выход по таймауту. Но прога много процессорного времени жрёт.

мне видится вот какое решение:
создать отдельный поток для чтения, в этом потоке настроить маску отслеживаемых событий так, чтобы отслеживалось событие - приём байта в буфер (см. SetCommMask). затем вызываем функцию ожидания события WaitCommEvent и поток (только он, а не вся программа) тормозится до прихода байта в буфер. ну а потом уже вызываем ReadFile, которая и прочитает пришедший байт. Разница будет в том, что процессорное время мы не занимали.

более подробно это всё описано в статье Олега Титова "Работа с коммуникационными портами (COM и LPT) в программах для Win32." (я по сути лишь кратко пересказал содержание )
Раньше статья была по адресу http://www.rs232.ru/doc002.html но теперь эта ссылка вроде не работает. Поищите в Интернете, её часто цитируют.

Наверное так и придётся делать.
Статья есть здесь: http://morgeyz.narod.ru/comlpt.htm
Сейчас почитаю.

Все это ботва, ребята, на самом деле WaitCommEvent нормально не пашет, он собака пропускает символы через раз. А если плотно на
ComPort сесть, то он подвешивает всю Вашу программу. Выход я нашел такой:
1.Программа плотно садится на Comport. Самое главное символы не теряются.
2. Естественно программы чтения записи в Com сразу поместить в отдельный поток. Подвешиваться будет он, а не вся Ваша графика
3. Настроить таймеры в головной программе так, чтобы через
какое то время через AFXThrowException выдергивать Com из ожидания символа. Тогда во всяком случае головная программа будет знать, что вот мол символ не пришел скажем через 10 сек. И далее пойдет на обработку этого события по алгоритму.
Вообщем там все очень нетривиально...

Прошу прощения за выражение "ботва", это я вчера у компьютера перегрелся

да никак по-другому это не назовёшь!

я рад что у меня хоть что-то наконец-то заработало. проблема оказалась в преобразовaтеле уровня на ULN2003, который в slaa148 описан