Forth http://fforum.winglion.ru/ |
|
о преимуществах и недостатках существующих стандартов http://fforum.winglion.ru/viewtopic.php?f=36&t=1799 |
Страница 6 из 6 |
Автор: | Hishnik [ Вс янв 14, 2018 17:13 ] |
Заголовок сообщения: | Re: о преимуществах и недостатках существующих стандартов |
Если число задач известно заранее, то где же здесь "много-"? Прочитать датчики и выполнить действия - это по сути одна задача, хотя бы потому что данные как раз общие, а не раздельные, как при многозадачной работе. Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие. А если в программе на МК отвалится датчик, то остальные компоненты программы станут бесполезны. USER-переменные в данном случае успешно заменяются на обычные локальные переменные процедур. Многозадачность тут сильно смахивает на "магию бренда", когда в проект необоснованно добавляются какие-то подходы, которые у всех на слуху, но в конкретном проекте ну совершенно ни к чему. |
Автор: | mOleg [ Вс янв 14, 2018 21:39 ] |
Заголовок сообщения: | Re: о преимуществах и недостатках существующих стандартов |
Hishnik писал(а): Прочитать датчики и выполнить действия - это по сути одна задача, ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать). Но, конечно, это не означает, что нельзя использовать другое решение. Вопрос лишь в том как проще добиться необходимого результата. Я не вижу проблемы с пользовательскими переменными. Они, как и многозадачность, прекрасно уходят в библиотеку, и подключаются при необходимости. |
Автор: | Ethereal [ Вс янв 14, 2018 22:10 ] |
Заголовок сообщения: | Re: о преимуществах и недостатках существующих стандартов |
Hishnik писал(а): Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие. Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить.Hishnik писал(а): Многозадачность тут сильно смахивает на "магию бренда" Решал я задачу воспроизведения WAV-файла с SD-флешки на 20-мегагерцовом PIC18. Так вот со стандартными WAV-файлами с частотой оцифровки 44100 Гц вообще быстродействия не зватило никак. Но поскольку в WAV-ах была не музыка, а вибрации сложной формы, то вопрос решился допустимым занижением частоты оцифровки. Но все равно при вопроизведении оперативная задача жрала львиную долю процессорного времени, а фоновая продвигалась короткими рывками в промежутках. Во время очередного рывка исполнялся лишь небольшой кусочек главного цикла фоновой задачи. Вот пример программы, которую без двузадачности было не написать никак. Такие задачи бывают.Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться. |
Автор: | Hishnik [ Вс янв 14, 2018 23:38 ] |
Заголовок сообщения: | Re: о преимуществах и недостатках существующих стандартов |
mOleg писал(а): ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать). Смотря где. Если датчик в контуре автоматизированного управления, то отрисовки может и вообще не быть. Если же это прибор, то нет смысла измерять и ничего не показывать (включая "показ" по внешнему интерфейсу, т.е. отправку данных). Поэтому двух задач тут нет, тут задача одна - организация измерений, которая без одного из компонентов просто перестанет существовать. Опять же, где именно отрисовка запаздывает? В семисегментном индикаторе? В LCD с SPI? В UART? Большинство устройств отображения не имеет сигналов готовности или же имеют такие режимы, которые без этих сигналов прекрасно обходятся. |
Автор: | Hishnik [ Пн янв 15, 2018 00:10 ] |
Заголовок сообщения: | Re: о преимуществах и недостатках существующих стандартов |
Ethereal писал(а): Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить. А зачем же это рассматривать как что-то отдельное? В процессе выбора архитектуры приняли решение о назначении прерываний и наличии непрерываемых фрагментов кода. Опять же, возможен "прямой" код вида BEGIN play_wav ?check_buttons IF process_buttons THEN AGAIN Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям, а основной цикл может быть и просто пустым. Однако это сильно зависит от МК. Ethereal писал(а): Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться. TCP/IP действительно кандидат на выделение задачи, но опять же - в зависимости от общей архитектуры системы и программного проекта. Слабые МК банально просядут при попытке выделить им отдельный менеджер задач со своими временными ресурсами. Кроме того, без MMU многозадачность представляет собой нечто зыбкое в плане надежности. А уж если TCP принимает данные, нужные спутнику, то необходимо обеспечить совместный доступ к этим данным из двух задач. И даже с задекларированной многозадачностью (в виде какой-то библиотеки), но без настоящего MMU источник потенциальных проблем все равно остается. По впечатлению - искусственные навороты не спасают(чудес не бывает и процессор один). Прерывания спасают слабо (процессор все равно один). Вот аппаратное распараллеливание уже очень хорошо и на корню решает проблему (две задачи так две задачи - значит будет два процессорных ядра). Горыныч оказался совсем удобен - там динамическое распределение временных слотов с нулевым штрафом на переход. |
Автор: | Ethereal [ Пн янв 15, 2018 00:52 ] |
Заголовок сообщения: | Re: о преимуществах и недостатках существующих стандартов |
Hishnik писал(а): Опять же, возможен "прямой" код вида Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кодаBEGIN play_wav ?check_buttons IF process_buttons THEN AGAIN ?check_buttons IF process_buttons THEN Hishnik писал(а): Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся.
|
Автор: | Hishnik [ Пн янв 15, 2018 01:09 ] |
Заголовок сообщения: | Re: о преимуществах и недостатках существующих стандартов |
Ethereal писал(а): Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кода ?check_buttons IF process_buttons THEN Я не то чтобы совсем против, но идея с отдельной явно выраженной многозадачностью у меня вызывает сомнения. Это же тоже отъест ресурсы и полагаться на волшебство в виде run_task/stop_task, не написав и продумав это самостоятельно... ну вот в соседнем треде показательный пример, как там человеку натурально впихнули совершенно ненужные ему дорогие программы. Многозадачность, наряду с ФортОС и IDE для Форта - из разряда несбыточных мечт, которые обязательно должны все исправить, вот только... Пример со звуком скорее тянет на тщательную проработку задачи в машинном коде. По идее, это как раз противоположно тому, чтобы не глядя отдать решение на откуп "бренду". Ethereal писал(а): Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся. Тут надо тщательно обдумать. Мы говорим о многозадачности или многопоточности? И опять же, USER-переменных, или просто локальных переменных потока? |
Страница 6 из 6 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |