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



Не, не лучше. Во-первых, хочется все же высокой частоты, от DCO - это 800кГц, а, во-вторых, не важнее, конечно, просто уменьшение размеров желательно


Спасибо! Я так и думала, что это хорошие Надеюсь, мы тоже будем довольны

Покажите функцию инициализации UART.
Вы опять что-то недочитали в User's Guide Частоту DCO можно изменить программно вплоть до 6,5МГц. А если использовать внешний резистор ROSC, то DCO можно легко разогнать МГц эдак до 50 одной левой. На такой частоте работать кристалл конечно же не сможет, но DCO такую частоту генерировать будет. Самолично проверял Проблема с DCO в том, что частота его зависит от температуры и напряжения питания. Для связи требуется стабильность битовой частоты не хуже 1-2%, 0,5% это вообще для любого случая подойдет. Если напряжения питания стабильно, используется внешний резистор ROSC с хорошим ТКС (не хуже скажем 50ppm/°C), DCO при старте калибруется по часовому кварцу (а при возникновении ошибок по связи происходит перекалибровка), то вполне можно обойтись и без внешнего высокочастотного кварца, одним лишь часовым.

Флаги не сбрасываю, потому что не помогло


Видимо, да

Спасибо, буду иметь ввиду

Ну вот она и ошибка. Первой командой инициализации USART должна быть установка бита SWRST, как это и указано в User's Guide. Вставьте в процедуру инициализации первой командой

А дальше по вашему тексту.
и все лишние нули пропадут.

не-а, не помогло

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

NData - максимальный размер буфера, инициализируется UARTTxBuf.NData = sizeBufTx(16), СData - счетчик.
Такое дело. Как выяснилось, такая работа буфера тоже занимает кучу лишнего времени, так как байты загружаются в буфер, только после того, как будет отправлена предыдущая посылка
if ((IE1 & UTXIE0) == 0)
Т.е. пока 6(в данном случае) байт не передастся, запись в буфер не произойдет. Это же не правильно? Хочу сделать так, что бы запись в буфер и отправка были независимы. Т.е. теперь

А в основной порграмме

Почему <6? Потому, что сейчас посылки по 6 байт.
Т.е., запись происходит только если есть место для следующей посылки(6 байт), а отправка начинается, если предыдущая посылка отправлена - эти два действия независимы. Но - в отладчике все хорошо, а на практике, при большой скорости передачи(т.е. когда идет непрерывная загрузка в буфер), последний байт в посылке теряется. Отчего это происходит? Если делать задержку между посылками, то все нормально, но это же жутко не функционально. тогда вообще нет смысла в буфере а, кстати, не имеет ли смысла перед сбросом IE1 &= ~UTXIE0 проверять бит UTXEPT?
такой вопрос

Сообщение отредактировал Daria - Sep 30 2008, 19:04

Шо це таке "sizeBufTx(16)"? Функция? Или размер буфера?
Дык буфер-то один или буферы для записи и для чтения разные? Если даже один, но размер его больше 12, то почему мешает одно другому?
Раз у вас канал полнодуплексный и прием с передачей независимы, то сделайте вы два разных буфера и всех делов.
Не имеет. Запрет прерываний не влияет ни на текущую передачу байта, находящегося в сдвиговом регистре, ни на передачу следующего байта, находящегося в буфере передатчика USART.
По поводу кода. Извините, но я уже перестал что-либо понимать в этих огрызках функций А отрицательные числа, возвращаемые функцией (как код ошибки?), вместо привычных 0 и 1 или чисел натурального ряда, это вообще нечто

почти весь код два сообщения назад
Раньше делала отправку примерно так, как вы советовали(ссобщений эдак 7-8 назад),
if ((IE1 & UTXIE0) == 0)
запись в буфер
IFG1 |= UTXIFG0;
IE1 |= UTXIE0;
В обработчике прерываний

но так получается, что запись следующей посылки идет только после того, как отправится текущая посылка , условие if ((IE1 & UTXIE0) == 0) - куча времени впустую.
но я пониаю, что вам некогда разбираться во всем этом Ну и ладно, и так помогли уже нехило разберусь. надеюсь
А что касается return -1... случайно return 1, но по большому-то счету есть разница? смысл такой, что не ноль.

Почему впустую? if это ведь не while, т.е. если условие не выполняется идем дальше, а не ждем его выполнения.
тут уже сам замысел, алгоритм непонятен. То ли вы реализуете пакетный протокол, который подразумевает запрос-ответ? То ли у вас информационный канал с контролем управления, построенный в "обертке" пакетного протокола? Если пакетный протокол точка-точка, то все так и должно быть: сначала передача запроса, затем прием ответа. Если же нужно постоянно гнать поток информации, лишь изредка, получая какие-то команды управления, то при наличии раздельных буферов чтения и записи, прерывание передатчика не нужно запрещать вообще. И опрос бита TXEPT тогда как раз нужен перед тем, как программно установить TXIFG для инициации прерываний.
При передаче работайте непосредственно с кольцевым буфером передатчика записывая в него по факту его опустошения. Т.е. в майне, где формируется пакет, счетчик буфера лишь увеличивается, а в прерывании передатчика счетчик буфера уменьшается. Индекс, естественно, только инкрементируется, учитывая переход его в начало буфера.
С буфером приемника аналогично, но наоборот. В прерывании приемника счетчик буфера увеличивается, а в майне вы буфер вычитываете и уменьшаете счетчик буфера. Прерывания ни приемника, ни передатчика при при этом запрещать не нужно. В прерывании приемника запись в буфер по факту наличия свободного места происходит.

Да, но данные обновляются очень быстро, а запись в буфер не идет, пока не отправится предыдущая посылка, в результате данные теряются и сам буфер немного теряет смысл

Будут две платы, на одной пакетный протокол запрос-ответ, на другой - постоянный поток информации, изредка получая команды пока второе

ну, вроде работает, спасибо

Сообщение отредактировал Daria - Oct 1 2008, 18:24

Я вам уже объяснял области применения буферов: а) синхронизация асинхронных потоков, б) сглаживание неравномерностей поступления данных в потоках.
Если у вас данные обновляются быстрее, чем уходят в канал связи и при этом требуется "не потерять" их, то это лишь означает, что у вас канал слишком "узкий" и "тормозной". Причем тут буфера?

Буферы, а не буфера канал вроде наладила

Кстати, по уартам, я как-то выкладывал свои исходники работы с последовательными портами по прерыванию.
Там использую циклические "буфера" :-) своего изготовления.
http://electronix.ru/forum/index.php?showt...mp;#entry194257
Может пригодится...

Наверняка пригодится! Большое спасибо, VAI

Сообщение отредактировал Daria - Oct 4 2008, 17:03