Потоки в AVR

Я попробовал повесить на прерывание по таймеру простое мигание разделителем времени(двоеточие) на TFT-дисплее

Код (C++):

volatile bool tStep = false;
ISR (WDT_vect)
{
  tStep = !tStep;
  word color = myGLCD.getColor();
  if ( tStep )  myGLCD.setColor(VGA_BLACK);
  else myGLCD.setColor(VGA_WHITE);  
  myGLCD.fillCircle(timeX+74, timeY+35, 4);
  myGLCD.fillCircle(timeX+74, timeY+14, 4);
  myGLCD.setColor(color);  
}

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

 

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

 

Да суть проблемы я уже понял, изначально у меня все в одном потоке уживается, а это просто чтоб попробовать
А почему собачий таймер для этого не стоит использовать? Я понимаю что есть несколько других, но собачий чем хуже для простой задачи?

 

Здесь скорее вопрос касается "правил хорошего тона программирования". По большому счёту таймер "сторожевой собаки" это то же таймер и его можно использовать для решения задач по аналогии с другими таймерами. Но всё же "сторожевая собака" и её таймер предназначены для решения специфичных задач. Так же можно отметить вопрос читаемости кода (скорости вникания в код). Я, например, увидев использование таймера WDT сразу подумаю -- "ага, в решении используется WD" -- а на самом деле никакого WD нет и понять это можно только внимательно вчитавшись в код. Тут ещё нужно отметить что код, написанный Вами (да кем либо), через год для Вас же становиться "чужим" и в нём приходится разбираться так, как будто его писали не Вы. Вот собственно, это единственная причина, по которой не стал бы использовать WDT для выполнения периодичных задач.

 

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

В свое время DI HALT, написал не мало об вариантах архитектур с примерами для AVR, ссылка на водную часть - http://easyelectronics.ru/avr-uchebnyj-kurs-arxitektura-programm.html, там 4 части, последняя от Bargest. А так же тут - http://we.easyelectronics.ru/tag/RTOS/ есть интересные статьи.

Есть большая вероятность, что и при использовании 1 потока у Вас возникнут проблемы (к примеру с появлением энкодера). Лучше выставить в прерывании переменную, а уже в loop выполнить необходимые действия.

 

Не понял где там самые интересные 3 и 4 части. Про RTOS. С остальным то более менее понятно.

 

Часть 2 - http://easyelectronics.ru/avr-uchebnyj-kurs-arxitektura-programm-chast-2.html.
Часть 3 - http://easyelectronics.ru/avr-uchebnyj-kurs-arxitektura-programm-chast-3.html
Часть 4 - http://easyelectronics.ru/avr-uchebnyj-kurs-vytesnyayushhij-dispetcher-zadach.html

А дальше RTOS.

 

у меня каждый второй пост со ссылкой на DiHalt, переход количества в качество...

 

В большинстве случаев да, но в отдельных случаях это не выход, т.к. loop может не скоро (относительно не скоро) добраться до обработки взведенного флага.

 

Не очень понял, что Вы хотели сказать.

DiHalt без условно, очень грамотный специалист, при всем уважении к нему. Но понимание AVR и самое ценное, для меня - это понимание документации, пришло благодаря другим. Возможно, в начале моего пути, его стиль изложения не всегда был столь доходчив для меня. Сейчас читаю его больше.

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

Ваш подход и та архитектура, которую Вы используете, это уровень профессионала. Который наверняка понимает свою архитектуру, ее плюсы и минусы и т.д.. Но таким как мне (простым любителям), нужно дорасти до нее.

Думаю Вы меня правильно поняли.
Конечно в прерывании должно быть только то, что требует немедленной реакции. Говорил о Вашем примере, код в прерывании будет отлично работать в loop.