Страница 1 из 1

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

Добавлено: Ср июл 08, 2009 09:58:48
clawham
Здравствуйте!
Хотел поинтересоваться у кого возникали потребности запускать несколько разнообразных процедур(от пары комманд до целого алгоритма на пол секунды) по определённым временным интервалам(от 1 мкс до пол дня) для каждой и в определённой последовательности и при этом интервалы не должны зависеть от времени исполнения всех процедур которые должны например ещё и в фоне мониториться

Добавлено: Ср июл 08, 2009 10:56:29
ARV
это вам смотреть в сторону RTOS. их есть не одна, многие бесплатные, например, uOS

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

Добавлено: Ср июл 08, 2009 11:11:32
ARV
по сути вы сделали свою ось :) немного кривенькую и не универсальную - вот и вся разница. но с каждым новым нюансом проблему станут нарастать, как снежный ком - и что тогда? имхо, если такая многозадачность действительно требуется - сразу лучше в сторону RTOS смотреть и ее осваивать.

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

Добавлено: Ср июл 08, 2009 11:45:39
VenomXP
clawham писал(а):Ну пока что типа как проблем-то и нету :)
Просто интересно кто какие подходы реализовывал...
В частности например разделение доступа к ресурсу....понятное дело МК не двуядерный и одновременно в полном смысле этого слова 2 кода выполняться не могут...но вот например печатаю я с ком порта текст по символьно в дисплюй....и тут приходит время в другое место экрана вывести например температуру....наверное надо было бы как-то знать что ещё не закончена печать и притормозить вывод другого контента другим обработчиком...
Почитайте книжечки по теории ОСей, там это очень прекрасно написано, а вообще, нужно зделать что-то типа менеджера/диспетчера задач который как раз и будет это рулить, к примеру делать очереди, и смотреть приоритетности задач, и уже во главу ставить та которая должна выполнятся незамедлительно, делите задачи на 2 типа: требуют немедленного выполнения и могут подождать, и от этого уже пляшите.

Добавлено: Ср июл 08, 2009 11:54:48
ikarab
Вот моя папка архива по ОСькам - просто как перечень некоторых

Изображение

Добавлено: Ср июл 08, 2009 12:37:16
clawham
это всё слишком сложно и применимо больше к большим серьёзным камням типа арма :)
а у меня только на реализаци. того что уже есть со всеми возможными оптимизациями ушло 75% флешки и 300 байт стека - памяти у меня свободной всего 10 байт :(
хочется какого-то простого алгоритма создания очереди выполнения и отсроченного выполнения. Любая задача может попасть под периодичность выполнения....вот и получаемые приоритеты...
в общем пока получается ничего лучшего и не предвидется :)

Добавлено: Ср июл 08, 2009 12:47:52
VenomXP
Почитайте здесь http://easyelectronics.ru/avr-uchebnyj- ... adach.html. Он хорошо пишет, жаль что на асме.

Добавлено: Ср июл 08, 2009 19:34:36
ikarab
Бредни электроникс ! Теперь понял почему там автор такой бред пишет ! Оказывается забивал на все всю учебу - так похоже и научился.
Как отучиться в Южно Уральском Гос Университете забивая на все и вся
Теперь другим мозги бредом забивает.

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

Добавлено: Ср июл 08, 2009 22:06:29
clawham
а я там уже бывал и не раз...человечек конечно много чего интересного для новичков выкладывает но...в принципе-то нового для себя я ничего не нашел...да .... всё что можно придумать это операционка уОс или ей подобные но...сношком оно много ресурсов жрёт + привыкать писать по этому шаблону + всёравно это очень приблизительно...да у меня в принципе тот же функционал заложен - в данный момент и последовательности и прерывания и фоновые задачи и приостановки на время и так далее но без стеков без диспетчера задач и таймер - то всего навсего отсчитывает системное время в милимекундах и минутах...в принципе-то всё очень наглядно и по шаблону можно попереповторять все любые вариации требуемые...
Просто как просграммист - чую есть альтернативные методы борьбы с распределением времени ядра и скорее всего более красивые но я пока что их не вижу...итак нормально...но чувствую я что скоро прийдёться пересаживаться на мегу 32 :))) - не справляется моё чудо со всем что я на него нагородил - в частности обновление 20 раз в секунду экрана потоковыми данными из ком-порта....и было б всё хорошо если б эта сволоч работала быстрее....никак не могу поднять на своей мамке скорость выше 115200...

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

Добавлено: Вс июл 19, 2009 00:15:51
DIHALT
Простейший диспетчер (который я описывал) и две очереди (задач и таймеров) это мизер ресурсов. На асме занимает не более 300байт флеша и десяток байт ОЗУ(я в Тини2313 ее пихаю и еще остается вагон места)

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

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

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

Добавлено: Пн июл 20, 2009 15:36:40
clawham
Аlex писал(а):
но вот например печатаю я с ком порта текст по символьно в дисплюй....и тут приходит время в другое место экрана вывести например температуру....наверное надо было бы как-то знать что ещё не закончена печать и притормозить вывод другого контента другим обработчиком...
Сделай буфер, и обновляй свой дисплюй из буфера каждые, например, 20 мс. А прогой выводи в буфер. И проблема решена :)
для того же примера скажу что 48*84 точек гораздо больше чем памяти МК не говоря уже о свободной :) да и не забываем что экран у меня на 8 мегагерцах шмалит а ком порт всего 115200 бит/с так что именно в ком порту дело и правильной организацией синхронизаций потоков большого пк....я например думаю делатьхитрее...отдельный поток заставить следить за массивом и как только там чтото появляется выпаливать его в ком порт тогда получится что очереди не надо ибо саму очередь и будет организовывать промежуточный массив...правда получается много проблем например мамка может притупить и не успеть выгружать в МК 20 раз в секунду скриншот...я на время вывода притормаживаю таймер и следующие 20 мс начинаю отсчитывать только после окончания вывода....вот так ... а как иначе? не ставить жеж своей проге приоритет реалтайм....всётаки она на сервере запускается....малоли чего ... сервер у меня порой на грани рабоатет...особенно при вырубании инета

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

Добавлено: Чт июл 23, 2009 01:40:26
DIHALT
Дикий Кот писал(а):Ну вы, господа, даёте.... RTOS на AVR ставить.
Кооперативку почему бы нет? Памяти она сожрет мизер. Та же Сальва например.