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

[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