Comments 9
Scheduler?
Если есть задачи с точной привязкой ко времени, то их, да, приходится расставлять по сетке вручную. Но обычно таких задач немного, и моё нестрогое решение соседствует со строгим, с прерываниями.
Не понял я только, почему в вашей задаче нельзя одновременно вычислять и сохранять. Первая задача - программная, вторая - аппаратная. И их вполне можно, и даже нужно делать параллельно, тем более при дефиците времени.
я припоминаю, и в это теперь наверно трудно теперь поверить, но там SPI был программный :) ! То есть буквально, выставляешь пин клока в ноль, выставляешь бит данных на пин данных, выставляешь бит клока в единицу - сформировали фронт на клоке передали бит данных. Это хороший-правильный вопрос, коллега! Мне сейчас и не в разум были эти детали, но на ваш вопрос простая логика достала мне из моей же памяти этот ответ.
Это было больше 20-ти лет назад, я честно говоря не уверен, что это был именно SPI, но передача точно выполнялась прямым управлением пинами и клок там точно был! Это был 16-битный Техас-Инструмент (TI) DSP процессор, который наверно и не предназначен был для таких фокусов, для работы с последовательной шиной. Просто когда плату делали кто-то очень умный сказал, что главное, что нужно от процессора - это поддержка DSP операций, а то что надо с последовательной шиной работать, а там соответствующей периферии нет - это ерунда, об этом никто не думал. А когда плату серийно уже выпускали вариантов не было - пришлось выкручиваться. Оно в таком виде уже до меня работало, только с галлюцинациями.
При мне, потом, начинались обсуждения о переходе на новый (тогда) 16-битный тоже MSP- микроконтроллер, относительно новый, для лучшей привязки ко времени.
Глянул иллюстрации к прошлой статье. Получается, что (Тацп + Тсохр) всегда меньше того периода, в который требовалось уложиться. И мешал только вклинивающийся между этих операций процесс вычислений, верно?
А возможна ли была такая реализация, когда мы разделяем приоритеты задач: опрос АЦП и сохранение в EEPROM выполняются с высоким, а обработка данных - с низким? Сейчас поясню.
Нам понадобится два программных неблокирующих FIFO буфера. В один прерывание складывает данные от АЦП, а в другой функция обработки данных помещает результат.
Обработчик прерываний:
• В начале каждого цикла опрашиваем АЦП и помещаем данные во входной буфер.
• Если в выходном буфере есть данные для записи, стартуем цикл записи в EEPROM, иначе сразу выходим - пусть работает основная функция.
Функция вычислений (крутится в poll-цикле):
• Если во входном буфере появились данные, извлекаем их и обрабатываем.
• Если в результате получили полезные данные для записи, помещаем их в выходной буфер. Они будут записаны в EEPROM при старте очередного цикла.
Если какой-либо из буферов у нас переполнился при записи, делаем аварийный останов - у нас явно ошибка либо в логике, либо при подсчёте таймингов.
Получается, что (Тацп + Тсохр) всегда меньше того периода, в который требовалось уложиться. И мешал только вклинивающийся между этих операций процесс вычислений, верно?
так да! конечно меньше, гарантированно меньше! Я даже проценты, вроде где-то написал, сколько они времени примерно занимают от полного периода опроса АЦП.
Но нельзя говорить что "процесс вычислений чему-то мешал" так как эти вычисления вместе с измерениями через АЦП, плюс управление исполнительными устройствами, то есть управление физикой работы прибора составляют основную функцию работы прибора и значит самую приоритетную функцию. Поэтому АЦП делается вообще по прерываниям, а результат его должен сразу обрабатываться-использоваться чтобы обеспечить физику работы прибора в целях корректного и безопасного измерения АД. Нельзя понизить приоритет этой задачи - она самая приоритетная - она задает цель работы прибора, а самое главное безопасность работы прибора.
Задача сохранения данных, с накоплением в промежуточный буфер (без накопления в буфер реализация не возможна) является второстепенной, хоть и очень важной для того чтобы обеспечить доверие алгоритму измерения и просто в любой момент его адекватность проверить. Но мы на самом деле сделали систему которая следит за временем выполнения этих двух основных функций. В этом смысле можно сказать что мы отдали максимальный приоритет логике контроля за временем исполнения основных содержательных вычислительной и коммуникативной функциям.
Ваш планировщик позволяет регулировать фазу старта задачи?
Что если я хочу двумя задачами на двух LEDах сделать ЖД семафор?
У вас серьёзная задача. Тут нужен как минимум двухядерный процессор, обмен данными с синхронизацией, FIFO и все дела. И к процу радиатор из чистого алмазного сплава. Иначе - не взлетит.
Ваш планировщик позволяет регулировать фазу старта задачи?
Если вы уточните фазу старта КАКОЙ задачи надо регулировать и относительно чего эту фазу надо регулировать я смогу ответить на этот вопрос. Хотя в статье, в общем то, ответ уже есть, по моему, но раскрыт этот вопрос, наверно, не очень внятно, признаю.
По поводу семафора - я не думаю что надо создавать задачу на каждый светодиод чтобы моргать этими светодиодами. В порт надо писать либо 01 либо 10 зачем тут две задачи? По моему, так получится только продемонстрировать как плохо использовать лишние абстракции (задачи) которые заведомо не нужны для реализации требуемой функции.
Проще всего написать что-то вроде:
while(1)
{
while(semaOn)
{
setLeds(0bxx01xx);
sleep(Tmorgnul);
setLeds(0bxx10xx);
sleep(Tmorgnul);
}
setLeds(0bxx00xx);
while(!semaOn);
}по моему самый наглядный вариант.
Сам себе шедулер (scheduler) — планировщик