Виртуальная потоковая многозадачность на ATMega

clawham

Здравствуйте!
Хотел поинтересоваться у кого возникали потребности запускать несколько разнообразных процедур(от пары комманд до целого алгоритма на пол секунды) по определённым временным интервалам(от 1 мкс до пол дня) для каждой и в определённой последовательности и при этом интервалы не должны зависеть от времени исполнения всех процедур которые должны например ещё и в фоне мониториться

Реклама

ARV · Сообщение **ARV** » Ср июл 08, 2009 10:56:29

это вам смотреть в сторону RTOS. их есть не одна, многие бесплатные, например, uOS

Реклама

clawham

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

ARV · Сообщение **ARV** » Ср июл 08, 2009 11:11:32

по сути вы сделали свою ось

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

Реклама

clawham

Ну пока что типа как проблем-то и нету

Просто интересно кто какие подходы реализовывал...
В частности например разделение доступа к ресурсу....понятное дело МК не двуядерный и одновременно в полном смысле этого слова 2 кода выполняться не могут...но вот например печатаю я с ком порта текст по символьно в дисплюй....и тут приходит время в другое место экрана вывести например температуру....наверное надо было бы как-то знать что ещё не закончена печать и притормозить вывод другого контента другим обработчиком...

Реклама

VenomXP

clawham писал(а):Ну пока что типа как проблем-то и нету
Просто интересно кто какие подходы реализовывал...
В частности например разделение доступа к ресурсу....понятное дело МК не двуядерный и одновременно в полном смысле этого слова 2 кода выполняться не могут...но вот например печатаю я с ком порта текст по символьно в дисплюй....и тут приходит время в другое место экрана вывести например температуру....наверное надо было бы как-то знать что ещё не закончена печать и притормозить вывод другого контента другим обработчиком...

Почитайте книжечки по теории ОСей, там это очень прекрасно написано, а вообще, нужно зделать что-то типа менеджера/диспетчера задач который как раз и будет это рулить, к примеру делать очереди, и смотреть приоритетности задач, и уже во главу ставить та которая должна выполнятся незамедлительно, делите задачи на 2 типа: требуют немедленного выполнения и могут подождать, и от этого уже пляшите.

Реклама

ikarab

Вот моя папка архива по ОСькам - просто как перечень некоторых

clawham

это всё слишком сложно и применимо больше к большим серьёзным камням типа арма

а у меня только на реализаци. того что уже есть со всеми возможными оптимизациями ушло 75% флешки и 300 байт стека - памяти у меня свободной всего 10 байт

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

VenomXP

Почитайте здесь http://easyelectronics.ru/avr-uchebnyj- ... adach.html. Он хорошо пишет, жаль что на асме.

ikarab

Бредни электроникс ! Теперь понял почему там автор такой бред пишет ! Оказывается забивал на все всю учебу - так похоже и научился.

Как отучиться в Южно Уральском Гос Университете забивая на все и вся

Теперь другим мозги бредом забивает.

Предупреждение! Aheir

clawham

а я там уже бывал и не раз...человечек конечно много чего интересного для новичков выкладывает но...в принципе-то нового для себя я ничего не нашел...да .... всё что можно придумать это операционка уОс или ей подобные но...сношком оно много ресурсов жрёт + привыкать писать по этому шаблону + всёравно это очень приблизительно...да у меня в принципе тот же функционал заложен - в данный момент и последовательности и прерывания и фоновые задачи и приостановки на время и так далее но без стеков без диспетчера задач и таймер - то всего навсего отсчитывает системное время в милимекундах и минутах...в принципе-то всё очень наглядно и по шаблону можно попереповторять все любые вариации требуемые...
Просто как просграммист - чую есть альтернативные методы борьбы с распределением времени ядра и скорее всего более красивые но я пока что их не вижу...итак нормально...но чувствую я что скоро прийдёться пересаживаться на мегу 32

- не справляется моё чудо со всем что я на него нагородил - в частности обновление 20 раз в секунду экрана потоковыми данными из ком-порта....и было б всё хорошо если б эта сволоч работала быстрее....никак не могу поднять на своей мамке скорость выше 115200...

Аlex

но вот например печатаю я с ком порта текст по символьно в дисплюй....и тут приходит время в другое место экрана вывести например температуру....наверное надо было бы как-то знать что ещё не закончена печать и притормозить вывод другого контента другим обработчиком...

Сделай буфер, и обновляй свой дисплюй из буфера каждые, например, 20 мс. А прогой выводи в буфер. И проблема решена

DIHALT

Простейший диспетчер (который я описывал) и две очереди (задач и таймеров) это мизер ресурсов. На асме занимает не более 300байт флеша и десяток байт ОЗУ(я в Тини2313 ее пихаю и еще остается вагон места)

Если не знаете асма, то на Си то же самое будет весить не намного больше (думаю очередь задач можно через указатели легко реализовать). Зато будет единый скелет который остается только обвесить мясом. И который не надо будет править при изменении/наворачивании алгоритма.

Классические же способы разделения времени на основании флажков/переходов страдают тем, что для того чтобы подправить прогу нужно заново переписать всю управляющую структуру. Это во первых нетехнологично, а во вторых ошибок можно нагородить которые фиг найдешь.

Полноценные ОС с вытесняющим мультитаскингом ИМХО на МК уровня АВР избыточны, тут вполне можно обойтись грамотно настроенной кооперативкой.

clawham

Аlex писал(а):
но вот например печатаю я с ком порта текст по символьно в дисплюй....и тут приходит время в другое место экрана вывести например температуру....наверное надо было бы как-то знать что ещё не закончена печать и притормозить вывод другого контента другим обработчиком...
Сделай буфер, и обновляй свой дисплюй из буфера каждые, например, 20 мс. А прогой выводи в буфер. И проблема решена

для того же примера скажу что 48*84 точек гораздо больше чем памяти МК не говоря уже о свободной

да и не забываем что экран у меня на 8 мегагерцах шмалит а ком порт всего 115200 бит/с так что именно в ком порту дело и правильной организацией синхронизаций потоков большого пк....я например думаю делатьхитрее...отдельный поток заставить следить за массивом и как только там чтото появляется выпаливать его в ком порт тогда получится что очереди не надо ибо саму очередь и будет организовывать промежуточный массив...правда получается много проблем например мамка может притупить и не успеть выгружать в МК 20 раз в секунду скриншот...я на время вывода притормаживаю таймер и следующие 20 мс начинаю отсчитывать только после окончания вывода....вот так ... а как иначе? не ставить жеж своей проге приоритет реалтайм....всётаки она на сервере запускается....малоли чего ... сервер у меня порой на грани рабоатет...особенно при вырубании инета

Дикий Кот

Ну вы, господа, даёте.... RTOS на AVR ставить. Для обучения, ознакомления с ОС оно, возможно, и стоит, но для реального дела вряд ли.
На 128-й Меге делал аппарат (коммерческий), выполняющий "одновременно" до 10 задач, порой достаточно ресурсоёмких (2 из них были связаны с фильтрацией сигналов). Для сравнения - коллега написал ОС для той же самой меги, но вот для приложений ресурсов почти не осталось (в первую очередь оперативной памяти). В итоге в продажу пошёл мой вариант.
Если нет необходимости запускать/останавливать произвольные приложения, то никакой RTOS не требуется. Достаточно распределить задачи по приоритетам, оценить затраты процессорного времени на каждую, оценить допустимые задержки обработки событий (в принципе связано с определением приоритета задачи) и на основе этой информации написать простейший диспетчер, выделяющий каждой задаче определённое время на выполнение. Очень высокой частотой системного таймера увлекаться не стоит - машинка то слабая. Наиболее критичные ко времени выполнения задачи придётся реализовывать на прерываниях.
Если нужно более подробно - опишите что должно делать устройство.

DIHALT

Дикий Кот писал(а):Ну вы, господа, даёте.... RTOS на AVR ставить.

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