Помогите с USART на Atmega8-16AU

[Frosty85]

Доброго времени уважаемые форумчане.
Занесла меня нелегкая снова на путь AVR ))))
Есть готовая плата, но нужно модернизировать а лучше с нуля написать прошивку под USART.
У самого весит очень большой проект, над которым сейчас работаю и времени на решение этой задачки попросту нет, к томуже с рождением сына его катастрофически стало не хватать. Вот и прошу помощи. Писал раньше в Atmel Studio 6.0, сейчас просто сменил архитектуру с AVR на ARM и чтобы заняться этим вопросом многое надо вспоминать.

Данные:
Async Serial
4800 bit rate
8 bit
1 stop bit
Even parity bit
LSB first

Используемый мк - Atmega8-16AU
Выводы PD2 - на прием, PD6 или PB1 - на передачу.


Цель организовать прием и передачу с заданными параметрами.

При приеме данных 1E 66 FF передавать в ответ FF FB CD 21
При приеме первого пакета данных в начале передачи ответа формировать сперва данные 21 21 21 а после передавать ответы на запросы.
Если после прекращения на приеме отсутствую пакеты данных и устанавливается лог 1 то постоянно выдавать данные 21 21 21 21.....

Пример:

USART.jpg

Фрагмент приема передачи начало - конец

(152.86 KiB) Скачиваний: 434

PS платные варианты помощи тоже приветсвуються (в личных сообщениях)

Добавлено after 9 hours 29 minutes:
Ну что-же, начну понемногу сам отвечать на свои вопросы, попутно вспоминая азы AVR

Настройка AVR:

Код:

#ifndef F_CPU
#define F_CPU 8000000UL   //   рабочая частота
#endif

#include <avr/io.h>
#include <avr/interrupt.h>

int init_UART(void)
{
   //   Установка скорости 4800
   UBRRH=0;   
   UBRRL=103;   
   UCSRA=0b00000000;
   UCSRB|=(1<<RXEN)|(1<<RXCIE)|(1<<TXEN);
   UCSRC=0b10100110;   //   8bit EPB 1Stop
}


Прием данных и их обработка:

Код:

volatile unsigned char i=0;
volatile unsigned long data;
ISR(USART_RXC_vect)   //прерывание по приему
{
   temp[i]=UDR;
   if (temp[i]==0xFF)
   {
      data = 0;
      S = 1;
      for(i=i-1; i!=0; i--)
      {
                    data = data+temp[i];
      }
   }
   else
   {
      i++;
   }
}


По факту мы приняли 0x1E 0x66 0xFF и записали его в буфер.
Прошу дальнейшей помощи.

[akl]

...Используемый мк - Atmega8-16AU
Выводы PD2 - на прием, PD6 или PB1 - на передачу.
Цель организовать прием и передачу с заданными параметрами.

Вам нужно, для начала, открыть DS ATmega8. Сразу станет понятно, что прерываний от RxC при приеме на PD2 программа никогда не дождется. Приём на PD0/RxD гораздо проще. Передавать через лапы "PD6 или PB1" можно, но для этого придется использовать самописную программу. Опять же, лучше использовать лапу PD1/TxD.

Код:

#ifndef F_CPU
#define F_CPU 8000000UL   //   рабочая частота
#endif

   //   Установка скорости 4800
   UBRRH=0;   
   UBRRL=103;   
   UCSRA=0b00000000;
   UCSRB|=(1<<RXEN)|(1<<RXCIE)|(1<<TXEN);
   UCSRC=0b10100110;   //   8bit EPB 1Stop
}


Можно записать так

Код:

BAUD=4800
UBRRH=HIGH(F_CPU/BAUD/16-1)
UBRRL=LOW(F_CPU/BAUD/16-1)
UCSRC=0b10100110;   //   8bit EPB 1Stop; Сначала устанавливается режим работы, затем оная разрешается
UCSRB|=(1<<RXEN)|(1<<RXCIE)|(1<<TXEN)


[Frosty85]

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

[Alkul]

тут не получится как на ARM перекинуть на свободные выводы

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

[Frosty85]

Я уже так и сделал.

[servmv]

Код:

for(i=i-1; i!=0; i--)
      {
                    data = data+temp[i];
      }


Плохая затея в прерываниях циклы делать.
По прерыванию тянешь данные из UDR, кладешь в буфер, делаешь инкремент счетчика. Прерывание должно отработать за небольшое количество тактов МК, иначе это все плохо кончится, будут такие глюки что ты долго будешь искать ошибки в проге.

[Pink-Pank]

А залить прошу используя ардуиновский скетч, не? Там вообще все просто. все обращение идет через класс Serial.
P.S. Да не закидают меня тухлопомидорами олдскульные дяденьки...
P.P.S. Есть еще несколько проектов студий разработки, в которых можно прогать блок-схемами. С использованием вставок из СИ. На вскидку не вспомню, но знающие люди подскажут. Порог вхождения околонулевой. И довольно быстро можно состряпать вполне рабочую прогу.

[Ярослав555]

Здравствуйте, не хочу плодить отдельных тем, возможно мой завтык пустяковый.
Имею три платы - мастер и два слейва. Один слейв (А) оригинальный, и его мастер воспринимает. Другой слейв (В) - имитация оригинала, его я программирую. Проблема в том, что мою плату пастер понимать не хочет. Пакет по юсарту я шлю верный, по их протоколу. Пакеты оригинал и копия по дампу через отдельный 485й преобразователь ИДЕНТИЧНЫ. Если смотрю осциллом - последние байты не совпадают. Значит режим - 19200, 8 бит, even, 1 стоп бит. Пакет вида d0 08 05 06 02 00 00 00 00 00 00 00 00 d9 e5, где последние два байта это контрольная сумма. Прилагаю скриншоты окончания всего пакета.
То что мастер принимает как верный ответ:
http://img.radiokot.ru/files/88294/medium/19s99o62s3.jpg
То что отправляет мой МК:
http://img.radiokot.ru/files/88294/medium/19s99n5vyq.jpg

[Ярослав555]

Прогнал прошивку в протеусе - выдает пакет 1 в 1 как оригинальный слейв. Подозревая чип, заменил плату - ситуация осталась.
PS. Ок, половину проблемы нашел. Изменил в программе парность на NONE и в протеусе тоже пошли пакеты как в шелезяке, отсюда делаем вывод, что парность железяки NONE не зависимо от того что я выставляю.

[Ярослав555]

В общем чем все закончилось. Режим, как оказалось, 9-1-N. То что я в начале принимал за бит четности, оказалось 9м битом данных. Так получилось, потому что моя прога (RS-Monitor), которой я смотрел пакеты, не имеет режима 9 бит, только 8. Экспериментируя с настройками и пытаясь получить адекватный поток данных, я увидел что если включить режим четности то данные идут систематизированные и их можно расшифровывать (походу программа просто игнорирует бит четности). А собственно этот 9й бит в передаче обозначает старт пакета - проприетарный протокол будь он не ладен
А по поводу протеуса - наверное дело было в изначальном состоянии регистров после ресета, поэтому поведение отличалось. Я у себя нашел не работающую инициализацию, что тоже изначально усложнило поиск корня проблемы.