UART к PC на CodeVision

[Frensis777]

вот код с кодевижн по обработке прерывания прихода символа в усарт
interrupt [USART_RXC] void usart_rx_isr(void)
{
char status,data;
status=UCSRA;
data=UDR;
if ((status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN))==0)
{
rx_buffer[rx_wr_index]=data;
if (++rx_wr_index == RX_BUFFER_SIZE) rx_wr_index=0;
if (++rx_counter == RX_BUFFER_SIZE)
{
rx_counter=0;
rx_buffer_overflow=1;
};
};
}

#ifndef _DEBUG_TERMINAL_IO_
// Get a character from the USART Receiver buffer
#define _ALTERNATE_GETCHAR_
#pragma used+
char getchar(void)
{
char data;
while (rx_counter==0);
data=rx_buffer[rx_rd_index];
if (++rx_rd_index == RX_BUFFER_SIZE) rx_rd_index=0;
#asm("cli")
--rx_counter;
#asm("sei")
return data;
}
#pragma used-
#endif


тут функция самого прерывания и функция гетчара
так вот в курсе 123авр фрагмент
#asm("cli")
--rx_counter;
#asm("sei")
описан(http://forum.cxem.net/z5.htm)но я его в корне не пойму....зачем и смысл останалиать прерыания потом его заново запускать....непойму...


так тут написано что прерыания блокируютса из за того что цытирую...


"-----
Так как мы считали символ из буфера нужно уменьшить число символов в нем подлежащих считыванию.

#asm("cli") // запретить прерывания глобально
--rx_counter; // вычесть 1 из rx_counter
#asm("sei") // разрешить прерывания глобально

Обратите внимание что перед декрементом мы запрещаем прерывания, а после прерывания включаем опять.

Зачем ? Вот фо ??? воскликнул бы англоязычный читатель ...

А затем, что в обработчике прерывания есть инкремент rx_counter - и если на декременте возникнет прерывание мы можем зациклится в этом месте программы и получить ошибку в числе символов в буфере.

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

[ut1wpr]

1. Ссылка нечитаема.
2. Для того, чтобы англичанин заткнулся, русскому почитать про атомарность.
3. Опытными людьми не рекомендовано обучение по "..123...". Цитировать оттуда тем более.
4. Модераторами всех подобных форумов рекомендовано фрагменты кодов обрамлять специально придуманными для этой цели тегами. Элементарное уважение к читающим.
Сами посмотрите:

#asm("cli") // запретить прерывания глобально
--rx_counter; // вычесть 1 из rx_counter
#asm("sei") // разрешить прерывания глобально

[whoim]

Fogtech, я не увидел никаких модификаторов для хранения данных во флеш, но во входе параметра в функцию передачи у вас не указано что это указатель.
Вот как работает в атмел студио:

//отправка byte в порт модема
void gsm_send_byte(uint8_t chr)
{
	while (!(USARTC0.STATUS & USART_DREIF_bm));
	USARTC0.DATA = chr;
}
//отправка строки в порт модема
void gsm_send_str(const char *str)
{
	while(*str)
		gsm_send_byte(*(str++));
}
//отправка _P_ строки в порт модема
void gsm_send_str_P(char *str)
{
	while(pgm_read_byte(str))
		gsm_send_byte(pgm_read_byte(str++));
}

Вызов

gsm_send_str("test");
gsm_send_str_P(PSTR("test"));

[whoim]

Прошу подсказать как должна выглядеть функция регулярной отправки

о, как раз в моем посте работает на xmega A4. Прием засовываем в прерывание:

ISR(USARTC0_RXC_vect)
{	
	uint8_t _char = USARTC0.DATA; //получим данные
  //...запихнем фкуда нибудь
}

Прерывание надо разрешить вместе с приемом и отправкой

USARTC0.CTRLB = USART_RXEN_bm | USART_TXEN_bm;
	USARTC0.CTRLA =	USART_RXCINTLVL_HI_gc; // Enable Receive Complete, TransmitComplete, RegisterEmpty Interrupt(Low Level)

Да и в общем то, настроить baud и все..

[ut1wpr]

To: fogtech
Ваша проблема не в конкретной функции, а в отработке логики программы.
Много неясного. Прием любого байта по usart можно считать сигналом к разрешению передачи данных? Или это должен быть какой-то конкретный байт-признак? Или Совокупность байтов (команда). В любом случае вы не должны себе позволять такую роскошь, как ожидание байта в цикле ничегонеделания. Переходите на прием по прерыванию от готовности приемника. В обработчике взведите некий флаг, типа "байт принят".
Далее. Не совсем ясно, что вы собрались передать. Судя по выхваченному из контекста примеру, вы собрались выливать некий массив. Учитывая низкую скорость передачи (9600) у вас опять непозволительная роскошь - передавать байт с зависанием на ожидание опустошения буфера. И в этом случае лучше передавать поток данных по прерываниям от готовности передатчика. Работа по прерываниям детально и со вкусом описана на просторах инета. Найти это - ваша задача. Не забывайте, что взведенный в прерывании по приему флаг необходимо сбросить вне прерывания.
Это все справедливо, если у вас процесс передачи будет длительным по времени. Также зависит от характера фоновой задачи и насыщенности ее событиями и их приоритетами. Ничего этого не раскрыто, посему можно предположить, что у вас просто "практикум". Тогда элементарно отрабатывайте умение принимать и передавать по прерываниям. Это почти целая наука.

[whoim]

ut1wpr, дополню очень хорошее изложение: отдельным важным аспектом является организация буфера данных и работа с ним. Мне советовали поизучать прием "Кольцевой Буфер". Очень классный пример (да что там - минилиба) есть в примерах от LUFA, RingBuffer. Можно просто брать на вооружение. Сам еще толком не пробовал, некуда пока приткнуть. Но использовал как есть с примером в конвертере uart/cdc.

[ut1wpr]

ut1wpr, дополню очень хорошее изложение: отдельным важным аспектом является организация буфера данных и работа с ним. Мне советовали поизучать прием "Кольцевой Буфер". Очень классный пример (да что там - минилиба) есть в примерах от LUFA, RingBuffer. Можно просто брать на вооружение. Сам еще толком не пробовал, некуда пока приткнуть. Но использовал как есть с примером в конвертере uart/cdc.

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

[Fogtech]

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

Цель моих зысканий в настройке обмена данных между ПК и МК. То есть у меня есть этакой терминал который на данный момент нажатием кнопки зажигает определенные светодиоды, а также отображает значение АПЦ. Позже через эту программу должны отображаться значения нескольких измерений (АЦП), а также посылаться изменения для разных переменных внутри МК.

[ut1wpr]

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

Цель моих зысканий в настройке обмена данных между ПК и МК. То есть у меня есть этакой терминал который на данный момент нажатием кнопки зажигает определенные светодиоды, а также отображает значение АПЦ. Позже через эту программу должны отображаться значения нескольких измерений (АЦП), а также посылаться изменения для разных переменных внутри МК.

Вам надо определится с пониманием, что такое есть "событие". Понять их хронологию (привязку во времени по отношению одного к другому), оценить, какие события должны вызывать какие действия. И только потом перейти к разрисовке блок-схемы (алгоритмике) программы. В самом конце этих шагов должно стоять написание собственно программы. У вас этот пункт выкарабкался на первое место.
Понимаю, у вас нет уверенности, что вы сможете реализовать тот или иной программный блок. В таких случаях просто придумайте себе задачу попроще, в которой этот блок будет задействован без взаимодействия с остальными, отладьте его раз и навсегда и больше к нему не возвращайтесь. Таким образом у вас в базе ваших знаний (в голове, то есть) будет накапливаться все больше готовых ВАШИХ СОБСТВЕННЫХ пониманий и решений. Из которых вы потом будете складывать кубики вашей программы.

[whoim]

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

ну я сначала свое написал, очередь с кучей трудозатрат на пропихивание снизу вверх при изъятии. Потом уже разжевали тут - мучай указатели и не таскай байтики почем зря Применил это же при работе с буфером в виде файла на сдммц, потом наткнулся и разобрался.