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

подскажите по 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 сек. И далее пойдет на обработку этого события по алгоритму.
Вообщем там все очень нетривиально...