Структура программы (AVR studio) Опции

[pistoletov]

Привет всем. Пытаюсь сделать проектик на xmega. Устройство представляет собой торговый автомат. Задача стоит периодической отправки данных
по гпрс каналу. Работа с модемом требует ожиданий ответов, очень бы не хотелось тормозить работу периферии на эти моменты. С RTOS не хочется связываться пока сложнова-то для меня и много кажется ртос для такой задачи. Я вижу решение что всю перефирию-клавиатуру, датчики итп..повесить на прерывания у xmega их хватает. Нормальное ли это решение или есть какие-о варианты на фоне основного цикла в фоне работает функция отправки данных по гпрс-модему?

[SyncLair]

ну либо вы пишите в виде автоматов -- они же с небольшой дороботкой преврашаются в сопрограммы -- собсвенно так как вы и сказали и получается

либо вариант номер 2 -- ось с двумя потоками один из которых имеет меньший приоритет

[pistoletov]

Подскажите простую оську для авр студии. Что бы не сильно мудренная была

[_Артём_]

Подскажите простую оську для авр студии. Что бы не сильно мудренная была

Для AVRStudio - Windows XP самое то.

[pistoletov]

Спасибо за совет предпочитаю Win 7. А пока в качестве RTOS выбор пала на FreeRtos порт под хmega вроде как имеется.

[Misile_Inc]

Если без оси - в main организовываете петлю while(!Error), внутри вызывает функции вида gprs_handler() , sale_handler(), ну или какие там еще задачи могут быть у торгового автомата. В модуле gprs.c реализуете набор состояний через enum{}, текущее состояние храните в статической переменной. В начале gprs_handler() размещает switch (gprs_state). Если состояние соответствует ожиданию - проверяете буфферы/флаги, если состояние не изменилось - return. И так по кругу.
Мне кажется, так очень просто получается. А операционку можете пока изучать. Как получите готовый прототип - портируете код на операционку при желании.

Сообщение отредактировал Misile_Inc - Mar 7 2013, 09:45

[pistoletov]

спасибо. Классная идея. Попробую так сделать. Ртос как-то не совсем простая для освоения.и Нормального порта под хмеga не нашел. Сам портировать пока не готов-). Вот еще вариант нашел как мне показался интересный но не уверен подойдет ли мне с моими задержками в ожидании сигналов http://habrahabr.ru/post/148992/

[Misile_Inc]

pistoletov решать Вам, но мне не очень понравилась такая архитектура в применении к простой (как Вы сказали) задаче.
Особенно не понравилось выполнение чего - либо в прерывании. Лично мне кажется, что в прерывании таймера без крайней необходимости в точной синхронизации ничего кроме установки флагов делать нельзя. Остальное все в main().
Для задач, которые нужно вызывать по времени можно завести полупрограммные таймеры. Тогда код может выглядеть как-то так:

CODE

enum
{
timer_100ms,
timer_1000ms,
number_of_timers
}
static uint16_t timer_counts[number_of_timers];
void timer_interrupt_handler ()
{
for (i = 0; i<number_of_timers)
{
if (timer_counts[i] > 0)
{
timer_counts[i] -= 1;
}
}
}
void main(void)
{
init_timer ();
while (!Error)
{
gprs_handler();
sale_handler();
if(!get_count(timer_100ms))
{
supply_control();
reinit(timer_100ms) = 0;
}
if (timer_1000ms)
{
coin_control();
reinit(timer_1000ms) = 0;
}
}

}

Естественно, объявление функций, переменных таймера следует вынести в свои модули, чтобы не превращать код в нечто нечитаемое.
От описанного мной приема я тоже не в восторге, но он сопровождаем и понимаем даже для новичков. Значительно проще и короче, чем по вашей ссылке.

Самый главный совет: начните работать над программой. Только на практике Вы сможете выработать свой стиль и понять, какая архитектура больше подходит.

Сообщение отредактировал Misile_Inc - Mar 17 2013, 10:21

[pistoletov]

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