Как правильно организовать архитектуру программы?, Архитектура для часов Опции

[Maxi_Man]

Как правильно организовать архитектуру программы для часов?
Часы должны показывать время дату и температуру, по очереди с определённой задержкой.
Как организовать настройку времени?
Контроллер: Mega8;
IDE: Atmel Studio.

[Onkel]

порядок гуглим "AVR. Учебный курс. Операционная система. Введение.", и не пугайтесь слов "операционная система" - это просто опыт нескольких десятилетий по программированию мелких мк, очень полезная и очень очень простая инфа.

[demiurg1978]

Крайне вредный совет и цикл статей. В этой "операционной системе" занесен большущий дамоклов меч. Мина непредсказуемого замедленного действия. Я о таймерной службе в этом опусе.

[Onkel]

Крайне вредный совет и цикл статей. В этой "операционной системе" занесен большущий дамоклов меч. Мина непредсказуемого замедленного действия. Я о таймерной службе в этом опусе.

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

[demiurg1978]

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

CODE

//========================================================================
__C_task main ()
{
wdt_enable (WDTO_15_MS);

/*
dsp_buf [0] = 1;
dsp_buf [1] = 2;
dsp_buf [2] = 3;
dsp_buf [3] = 4;
dsp_buf [4] = 5;
dsp_buf [5] = 6;
*/

init_sys_timer ();

__enable_interrupt ();

Init_Events ();

while (1)
{
__watchdog_reset ();

service_timers ();

proc_amplifier ();

proc_7_segm_ind ();

Process_Events ();
}
}
//========================================================================

Запуск процесса каждое определенное время, на этом примере можно посмотреть, как запускать процессы периодически или через определенное время:

CODE

//========================================================================
void proc_7_segm_ind (void)
{
static u08 _proc_7_segm_ind;

static u08 cnt_7_segm_ind;

switch (_proc_7_segm_ind)
{
case 0:
ANODS_DDR = 0xFF;
cnt_7_segm_ind = 0;
set_timer (ST_PROC_7_SEGM_IND, NO_RERUN_TIMER, 1);
_proc_7_segm_ind = 1;
break;

case 1:
if (wait (ST_PROC_7_SEGM_IND))
{
u08 cnt = cnt_7_segm_ind;

volatile u08 anods;
volatile u08 katods;

ANODS_PORT = 0;
KATODS_DDR = 0;

cnt_7_segm_ind = tab_index_anods [cnt].i;
anods = tab_index_anods [cnt].anod;

katods = table_7_segm_char [dsp_buf [cnt_7_segm_ind]];

ANODS_PORT = anods;
KATODS_DDR = katods;

set_timer (ST_PROC_7_SEGM_IND, NO_RERUN_TIMER, 1);
}
break;

default:
_proc_7_segm_ind = 0;
break;
}
}
//========================================================================

Сообщение отредактировал demiurg1978 - Aug 21 2015, 07:37

[Onkel]

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

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

Сообщение отредактировал Onkel - Aug 21 2015, 07:59

[demiurg1978]

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

Сообщение отредактировал demiurg1978 - Aug 21 2015, 08:08

[Onkel]

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

***Только если не учел взаимосвязи и нюансы.*** - это относится к любому применению любого алгоритма. Я нелюбимый вами диспетчер юзаю и проблем не имею, в том числе и на задачах уровня автоматизации цеха или контроллера умного дома. Засим предлагаю пофиксить дискуссию в связи с наметившимся переходом во флейм / халивар.

Сообщение отредактировал Onkel - Aug 21 2015, 08:15

[demiurg1978]

Не торопитесь. Давайте продуктивно обсудим.

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

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

Сообщение отредактировал demiurg1978 - Aug 21 2015, 08:27

[Onkel]

Не торопитесь. Давайте продуктивно обсудим.

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

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

1 моргать - ну примерно моргать, но посложнее- у меня шим светодиодный, прерывание по таймеру смотрит - включить, выключить, или ничего не делать, сравнивает текущую переменную (счетчик) с установкой шим (0-255), если счетчик <установки - включате, иначе- выключает. Меняем режим - меняем установку шим, приходит время обработать , вызывается прерывание по таймеру - а у нас установка шим стоит какая надо для этого режима. Так и работают 8 канальные шимы, 8же (2х4 фазные обмотки) контроллеры шаговых 4хфазных униполярных двигателей. В вашем примере - раз в секунду вызываем функцию "моргать светодиодом", а в функции этой есть свич (например) по переменной "режим".
2 похожая задача - управление шаговым двигателем с концевиками. Данные с концевиков обрабатываются раз в миллисекунду (по главному таймеру прерывание ), вызывается по другому таймеру периодически (собственно период есть период переключения обмоток шаговиков) функция управления выходами подачи напряжения на шаговики, если переменная "концевик начало" или "концевик конец" единица то прокрутку (шаг шаговика) в "ненужную" сторону не делаем. Теперь , если у нас сработал концевик "конец по часовой", мы можем хоть тысячу раз командовать "100 шагов по часовой" - шаговики по часовой не повернутся. Собственно как я и писал - параметр "номер режима" обрабатывается и внутри функции.

Да, про режим "авария" - имхо тут должна быть не просто остановка, ведь у вас же не один параметр вызывает режим "авария" - скажем, при опускнии напряжения ниже 180 В -один алгоритм остановки, при потере герметичности пневмосистемы - другой, при получении сигнала "авария" от частотника - третий и т.д., истина она всегда конкретна. Но про два ваших случая я вроде ответил?

Сообщение отредактировал Onkel - Aug 21 2015, 09:19