Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт июн 21, 2018 18:35

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 82 ]  На страницу Пред.  1, 2, 3, 4, 5, 6
Автор Сообщение
 Заголовок сообщения: Re: о преимуществах и недостатках существующих стандартов
СообщениеДобавлено: Вс янв 14, 2018 17:13 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6329
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
Если число задач известно заранее, то где же здесь "много-"? Прочитать датчики и выполнить действия - это по сути одна задача, хотя бы потому что данные как раз общие, а не раздельные, как при многозадачной работе. Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие. А если в программе на МК отвалится датчик, то остальные компоненты программы станут бесполезны. USER-переменные в данном случае успешно заменяются на обычные локальные переменные процедур. Многозадачность тут сильно смахивает на "магию бренда", когда в проект необоснованно добавляются какие-то подходы, которые у всех на слуху, но в конкретном проекте ну совершенно ни к чему.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: о преимуществах и недостатках существующих стандартов
СообщениеДобавлено: Вс янв 14, 2018 21:39 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4920
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 56 раз.
Hishnik писал(а):
Прочитать датчики и выполнить действия - это по сути одна задача,

ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать).
Но, конечно, это не означает, что нельзя использовать другое решение. Вопрос лишь в том как проще добиться необходимого результата. Я не вижу проблемы с пользовательскими переменными. Они, как и многозадачность, прекрасно уходят в библиотеку, и подключаются при необходимости.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: о преимуществах и недостатках существующих стандартов
СообщениеДобавлено: Вс янв 14, 2018 22:10 
Не в сети
Аватара пользователя

Зарегистрирован: Ср фев 23, 2011 20:42
Сообщения: 519
Откуда: Карелия
Благодарил (а): 3 раз.
Поблагодарили: 21 раз.
Hishnik писал(а):
Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие.
Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить.
Hishnik писал(а):
Многозадачность тут сильно смахивает на "магию бренда"
Решал я задачу воспроизведения WAV-файла с SD-флешки на 20-мегагерцовом PIC18. Так вот со стандартными WAV-файлами с частотой оцифровки 44100 Гц вообще быстродействия не зватило никак. Но поскольку в WAV-ах была не музыка, а вибрации сложной формы, то вопрос решился допустимым занижением частоты оцифровки. Но все равно при вопроизведении оперативная задача жрала львиную долю процессорного времени, а фоновая продвигалась короткими рывками в промежутках. Во время очередного рывка исполнялся лишь небольшой кусочек главного цикла фоновой задачи. Вот пример программы, которую без двузадачности было не написать никак. Такие задачи бывают.
Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: о преимуществах и недостатках существующих стандартов
СообщениеДобавлено: Вс янв 14, 2018 23:38 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6329
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
mOleg писал(а):
ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать).

Смотря где. Если датчик в контуре автоматизированного управления, то отрисовки может и вообще не быть. Если же это прибор, то нет смысла измерять и ничего не показывать (включая "показ" по внешнему интерфейсу, т.е. отправку данных). Поэтому двух задач тут нет, тут задача одна - организация измерений, которая без одного из компонентов просто перестанет существовать.

Опять же, где именно отрисовка запаздывает? В семисегментном индикаторе? В LCD с SPI? В UART? Большинство устройств отображения не имеет сигналов готовности или же имеют такие режимы, которые без этих сигналов прекрасно обходятся.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: о преимуществах и недостатках существующих стандартов
СообщениеДобавлено: Пн янв 15, 2018 00:10 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6329
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
Ethereal писал(а):
Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить.

А зачем же это рассматривать как что-то отдельное? В процессе выбора архитектуры приняли решение о назначении прерываний и наличии непрерываемых фрагментов кода. Опять же, возможен "прямой" код вида

BEGIN
play_wav
?check_buttons IF process_buttons THEN
AGAIN

Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям, а основной цикл может быть и просто пустым. Однако это сильно зависит от МК.

Ethereal писал(а):
Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться.

TCP/IP действительно кандидат на выделение задачи, но опять же - в зависимости от общей архитектуры системы и программного проекта. Слабые МК банально просядут при попытке выделить им отдельный менеджер задач со своими временными ресурсами. Кроме того, без MMU многозадачность представляет собой нечто зыбкое в плане надежности. А уж если TCP принимает данные, нужные спутнику, то необходимо обеспечить совместный доступ к этим данным из двух задач. И даже с задекларированной многозадачностью (в виде какой-то библиотеки), но без настоящего MMU источник потенциальных проблем все равно остается.

По впечатлению - искусственные навороты не спасают(чудес не бывает и процессор один). Прерывания спасают слабо (процессор все равно один). Вот аппаратное распараллеливание уже очень хорошо и на корню решает проблему (две задачи так две задачи - значит будет два процессорных ядра). Горыныч оказался совсем удобен - там динамическое распределение временных слотов с нулевым штрафом на переход.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: о преимуществах и недостатках существующих стандартов
СообщениеДобавлено: Пн янв 15, 2018 00:52 
Не в сети
Аватара пользователя

Зарегистрирован: Ср фев 23, 2011 20:42
Сообщения: 519
Откуда: Карелия
Благодарил (а): 3 раз.
Поблагодарили: 21 раз.
Hishnik писал(а):
Опять же, возможен "прямой" код вида
BEGIN
play_wav
?check_buttons IF process_buttons THEN
AGAIN
Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кода
?check_buttons IF process_buttons THEN
Hishnik писал(а):
Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям
Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: о преимуществах и недостатках существующих стандартов
СообщениеДобавлено: Пн янв 15, 2018 01:09 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6329
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
Ethereal писал(а):
Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кода
?check_buttons IF process_buttons THEN

Я не то чтобы совсем против, но идея с отдельной явно выраженной многозадачностью у меня вызывает сомнения. Это же тоже отъест ресурсы и полагаться на волшебство в виде run_task/stop_task, не написав и продумав это самостоятельно... ну вот в соседнем треде показательный пример, как там человеку натурально впихнули совершенно ненужные ему дорогие программы. Многозадачность, наряду с ФортОС и IDE для Форта - из разряда несбыточных мечт, которые обязательно должны все исправить, вот только...

Пример со звуком скорее тянет на тщательную проработку задачи в машинном коде. По идее, это как раз противоположно тому, чтобы не глядя отдать решение на откуп "бренду".

Ethereal писал(а):
Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся.

Тут надо тщательно обдумать. Мы говорим о многозадачности или многопоточности? И опять же, USER-переменных, или просто локальных переменных потока?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 82 ]  На страницу Пред.  1, 2, 3, 4, 5, 6

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB