Прием данных USART, пропускаю данные из за переполнения Опции

[messenger]

Спасибо большое всем за ответы!
Прошу поясните "2. Синхронизировать нужно и вот почему. Вы запускаете программ.." в части

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

"Засинхронизировать просто - примите 1-й байт от ПК, после него запустите таймаут." Данное понятие синхронизации мен не понятно. Режим то асинхронный.

[Палыч]

Про синхронизацию

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

Как, вероятно, происходит работа устройств сейчас:
1. Вы включаете приёмное устройство (подаёте на него питание). МК начинает работать. Производится инициализация устройств МК (таймера, USART). Передаётся управление функции READ_MASS_RS_1. Она (функция) взводит прерывание от таймера (прерывание наступит через какое время? "...много больше чем требуется на передачу пакета". Это сколько? Секунда? Две? 10?), и ждёт приема N байтов...
2. В это время Вы набираете (?) некие символы на терминале (на терминале ли?) и нажимаете (?) кнопку "отправить" (??? В этом пункте сплошные вопросы из-за отсутствия информации...).
3. П.2 занимает у Вас некоторое время.
4. Вполне вероятно, что это время больше, чем величина тайм-аута.
5. МК по тайм-ауту прекратил приём байтов (вероятно, ещё до того, как Вы отправили все данные).
6. ... что происходит далее - сказать нельзя из-за отсутствия информации...

[=GM=]

Какая у вас тактовая частота процессора?

[messenger]

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

ниже как пояснение
рабочая частота МК 1 МГЦ
делитель в таймере =1
время таймера 65,5 мс

описываемое устройство перед началом ожидания приема посылает запрос 1 символ "Q" котрый я вижу принятым в терминале (или в проутесе)
да с терминала я отправляю пакт 123456 (есть окошко куда он вписывается далее нажимается кнопка отправить, проверяю в проутесе и на рабочем железе реакция схожа)
вижу принятым в буфере 126хххх.. где х пустые места в массиве
далее опять идут QQQQQ
если нажать отправить то опять, как я понимаю по завершению таймаута, 126ххх..и QQQQQQ
по наличию Q визуально определяю был ли прием один или несколько, вижу один

Сообщение отредактировал messenger - Jan 19 2012, 15:27

[_Ivana]

А модно дилетанту встрять?

Если я правильно вас понял, вы по каким-то причинам не используете прерывания USART по приему, а просто опрашиваете его с определенной частотой по таймеру? Мне это напоминает анализ нажатия кнопок без прерываний по уровням на ногах, а с таким же "опросом клавиатуры" с определенной частотой. Так и опрашивайте USART всегда. Вообще всегда, и пусть ваш основной процесс крутится параллельно, а по таймеру вы заглядываете, не пришел ли очередной байт - ведь режим асинхронный. И не надо ничего ни с чем синхронизировать, а только складывать байты в мешок, можно кольцевой А если вы асинхронно приходящие байты наделяете каким-то человеческим смыслом, мыслите в терминах "пакетов" и прочих условностей, тогда и сами эти "пакеты" лучше формировать как надо - с детерминирующими символами, определяющими начало и конец пакета, часто используются enter|return как детерминирующий конец. И тогда передающее устройство пусть хоть какие паузы делает в процессе передачи и между пакетами - вы их примете и обработаете нормально. Но не будете определять "конец пакета" по тому факту, что "то символы летели один за другим, а то у нас что-то долго ничего не приходит, значит наверное конец пакета". Или я не правильно понял вашу логику "пакетов"?

[=GM=]

Не понимаю, как вы посылаете 123456 и в приёмном буфере видите 126хххх, вы же обнуляете буфер перед приёмом. Значит вы должны видеть по крайней мере 126000, а лучше бы 120006.

[messenger]

сделал "2. Данные принимаются с ошибкой. Чтобы проверить последнее следует либо проинициализировать массив reading_mass_rs_1 неким значением, отличным от нуля (например, символом 'X'). либо сохранять значение принятого байта, несмотря на ошибку в status (он же - UCSR1A). "

никому не сказал. Извините. буфер не обнуляю а забиваю иксами

опрашивать USART всегда ен могу. Нужно еще обрабатывать принятое

[_Ivana]

опрашивать USART всегда ен могу. Нужно еще обрабатывать принятое

Либо вы меня не поняли, либо одно из двух
Сколько тактов у вас уйдет на разовый опрос USARTа? Правильно, мизер. И с точки зрения основной программы, у вас будет лежать где-то мешок, куда "сами собой" будут сыпаться принятые байты - и этой основной программе будет все равно как они туда сыпятся - по прерываниям от USART или по прерываниям от таймера его опрашивающего. А как придет байт конца "пакета" - тогда либо выставляется флаг "посылка пришла", либо вы выходите из спячки и начинаете обрабатывать принятое, а параллельно у вас принимается следующий пакет. И не надо "все бросать" и сидеть и ждать, когда же примется вся посылка, а потом что-то делать. И ещё - если вы не успеваете "обрабатывать принятое" при той скорости входящего потока, которую выдает ваше передающее устройство, то вас не спасут ни прерывания ни опрос ни вообще ничего.

[messenger]

Прошу еще помощи
Вот что я сделал на данный момент

void READ_MASS_RS_1()
{
char status, data;
flag_stop_timer=0;
flag_eroor_rs=0;
RxTimOvf=0;

for (temp_1_i=0;temp_1_i<20;temp_1_i++)
{reading_mass_rs_1[temp_1_i]='z';} //Обнуление массива

TIMSK &= ~(1<<TOIE1); //Запретить прер. переполнения T1
TCCR1B=0x04; //! Изменить делитель
TCNT1H=0x7F;TCNT1L=0xFF; //переполнение =1 сек
TIFR |= (1<<TOV1); //Сброс флага прер. переполнения T1
TIMSK |= (1<<TOIE1); //Разрешить прер. переполнения T1


for (temp_1_i=0;temp_1_i<20;temp_1_i++)
{
while (((((status=UCSR1A) & RX_COMPLETE_1)==0)) && RxTimOvf==0) ;
data=UDR1;
if (((status & (FRAMING_ERROR_1 | PARITY_ERROR_1 | DATA_OVERRUN_1 ))==0))
{reading_mass_rs_1[temp_1_i]=data;}
}


for (temp_1_i=0;temp_1_i<20;temp_1_i++)
{putchar1(reading_mass_rs_1[temp_1_i]);}

}





interrupt [TIM1_OVF] void timer1_ovf_isr(void)
{
TIMSK &= ~(1<<TOIE1); //Запретить прер. переполнения T1
RxTimOvf=1;
flag_timer_1_set=1; //Используется в задержках(паузах)
}

основной цикл
void START()
{ delay_500_ms();
putchar1('X');
READ_MASS_RS_1();//В reading_mass_rs лежит все что пришло за таймут по RS


}

Я увеличил таймаут до 1 сек. Учел сделанные мне замечания.
Что получил. Если после прихода на терминал символа Х не посылать посылку то МК отвечает буфером из ХХХХ... (это нормально)
Если после прихода на терминал символа Х посылать посылку, например, 123456 то все ок
но если ее же послать в момент паузы т.е до прихода Х то с МК что то происходит и он шлет пустой буфер zzzzzzzzz..
исправить это не получается

я думал что это связано с наличием флагов ошибки USART пробовал обнулять status, не помогло

[Палыч]

если ее же послать в момент паузы т.е до прихода Х то с МК что то происходит и он шлет пустой буфер zzzzzzzzz..

Объяснить такое поведение программы - можно:
1 выполнение программы не дошло до функции READ_MASS_RS_1;
2 байты по USART доходят до МК, но программа их из UDR не "выгребает";
3 фиксируется DOR и RXC;
4 как только МК начинает выполнять READ_MASS_RS_1, то "замечает", что байт принят USART и забирает его, но по DOR в буфер не помещает;
5 дальше МК ждёт прихода следующего байта, не ничего не дожидается (все байты уже были переданы) и выходит из READ_MASS_RS_1 по тайм-ауту

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

[messenger]

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

И конечно вопрос а как правильно? но без прерываний.

Может я и остановлюсь на этом варианте, т.к. второе устройство (датчик) не ответит пока не придет подтверждение и ен отправит до разряшения. Все дубово. А вто что будет если что то ложное придет...помеха какая, непонятно. Точнее понятно. Больше двух и будет плохо.

Сообщение отредактировал messenger - Jan 20 2012, 16:03

[Палыч]

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

Флаги-то сбросить можно... Но, все байты были благополучно отправлены до того, как их прихода ждал МК и, поэтому не забрал из UDR.

A data overrun occurs when the receive buffer is full (two characters), it is a new character waiting in the Receive Shift Register, and a new start bit is detected.

Если на вход USART пришло 6 байт - куда "бедному" устройству их "складывать"?

[messenger]

Да мне их не нужно складывать. Просто проигнорировать все до старта таймера

[Палыч]

Просто проигнорировать все до старта таймера

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

[messenger]

while (((status & (FRAMING_ERROR_1 | PARITY_ERROR_1 | DATA_OVERRUN_1 ))==0))
{data=UDR1;}

Я уже кажется понял ошибку.
Все огромное спасибо за поддержку!