Вопросы по С/С++ (СИ)

ARV · Сообщение **ARV** » Вт апр 03, 2018 12:41:26

Ivanoff-iv писал(а):чтобы не было ситуации - что например пора сегмент переключать, а процессор чемто занят...

неужели вы семисегментником управляете из главного цикла?! в принципе, встречал я такое пару раз, но воспринимал это как экзотическое явление...
а при работе динамической индикации "по прерываниям" такого быть не может в принципе.

Реклама

Ivanoff-iv

нет конечно, в цикле в майне у меня вообще только #asm("sleep") и всё

Реклама

ARV · Сообщение **ARV** » Вт апр 03, 2018 12:48:58

вы любитель крайностей

Ivanoff-iv, дак у Вас всё (автомат, флаги всякие, возвраты, ...) крутится из обработчика прерываний ?

Реклама

Ivanoff-iv

Да. я обычно завожу один таймер и по максимуму всё подчиняю его прерыванию: сначала критичные процессы (переключение сегмента...) потом SEI, а дальше менее критичные ко времени задачи, отсюда же запускаю и АЦП и сдесь же ловлю и обрабатываю результат (предыдущего)

Добавлено after 1 minute 1 second:
просто код пишу максимально линейный и быстрый чтобы гарантированно до следующего вызова завершился

Добавлено after 47 seconds:
итак практически РТОС выходит
но самопальная

Добавлено after 5 minutes 22 seconds:
хотя можно и флаг устанавливать об окончании выполнения цикла: если не стоит - делаем холостой ход (делаем только неизбежное: переключение сегмента, да ход счетчиков и выпадаем) а выпадаем в завершение прошлого цикла (согласен - будет проскок, но это лучше чем переполнение буфера)

Реклама

ARV · Сообщение **ARV** » Вт апр 03, 2018 12:59:58

Ivanoff-iv писал(а):я обычно завожу один таймер и по максимуму всё подчиняю его прерыванию: сначала критичные процессы (переключение сегмента...) потом SEI, а дальше менее критичные ко времени задачи, отсюда же запускаю и АЦП и сдесь же ловлю и обрабатываю результат (предыдущего)

ну и в чем смысл? навороченный обработчик напрасно тратит ОЗУ на сохранение рабочих регистров, хотя нужды в этом нет. на сохранение/восстановление этих регистров расходуется время, хотя нужды в этом нет. "потом SEI" - это риск повторного входа в обработчик, если он слишком долгий.

ради чего всё это вы делаете? ради пустого главного цикла?

Ivanoff-iv писал(а):итак практически РТОС выходит

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

я лично никогда не стремился освободить главный цикл не то, чтобы от всего, а вообще от чего-то... и ни о чем не жалею.

имхо, главное - это грамотно распределить задачи на фоновые и основные, и тогда потребность в ОСРВ будет минимальной, если вообще будет.

Реклама

Ivanoff-iv писал(а):просто код пишу максимально линейный и быстрый чтобы гарантированно до следующего вызова завершился

И зачем себя так ограничивать ?
Запустите всё в основном цикле, и пусть там всё крутится. И за время выполнения можно не переживать... А всё, что нужно сделать точно по времени, синхронно с системными тиками - можно и в прерывание засунуть.

Ivanoff-iv

пустой майн это не цель, это так получается

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

Добавлено after 5 minutes 14 seconds:
может както и вручную время можно выбрать - не пробовал... но эти две характеристики присутствуют

Добавлено after 33 minutes 45 seconds:

ARV писал(а):навороченный обработчик напрасно тратит ОЗУ на сохранение рабочих регистров,

а у меня нет навороченного обработчика и переходов к над/подпрограммам - просто линейный код разбвавленный IF и switch-case...

Добавлено after 10 minutes 47 seconds:
кстати приложу ртос с которым работал...это не С конечно..., но вот чтото подобное хочу для С найти:
// Диспетчер задач обеспечивает независимый (паралельный) запуск Задач в соответствии с их парамерами (Period_Task период запуска - может быть 1-255)
// Для основной программы диспетчер "невидим" - не затрагивает стека, не изменяет регистров.
// Диспетчер необходимо периодически вызываеть с постоянной установленной частотой (это можно делать по таймеру или даже по W.Dog-таймеру)
// Период вызова задачи равен периоду вызова диспетчера умноженного на значение Period_Task для этой задачи.
// Период вызова диспетчера должен быть больше чем время выполнения самого диспетчера (иначе он будет вызываться непрерывно)
// Время затрачиваемое на работу диспетчера (22+10*количество_задач)тактов.

Ерундой не занимайтесь.
Вызывать всё из обработчика таймера, а потом мучительно решать проблемы с разбиванием алгоритма на куски кода, чтобы влезть во временные рамки тика таймера - мазохизм.

И причём тут "опасный производственный объект" я, например, так и не понял. Там есть требования - делать именно такой алгоритм ?
Если есть какой-либо контроль кода, то Вы хоть какую ОСь найдёте - её не пропустят.

ARV · Сообщение **ARV** » Вт апр 03, 2018 14:44:22

Ivanoff-iv писал(а):а у меня нет навороченного обработчика и переходов к над/подпрограммам - просто линейный код разбвавленный IF и switch-case...

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

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

Добавлено after 8 minutes 21 second:
приведу простой пример - традиционный термометр на DS18x20 и семисегментниках

Код: Выделить всё

int main(void){
   init_indication();
   init_1wire();
   int temperature;
   while(1){
      temperature = get_temperature();
      indication(temperature);
   }
}

из кода сразу виден весь основной алгоритм. при этом вы можете заменой функций вывода переделать его на вывод на ЖКИ или запись на SD-карту. переделав функцию получения температуры, вы можете использовать любой другой датчик. и основной алгоритм остается прозрачным.

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

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

по сравнению с вашим подходом - исключительно одни плюсы.

Reflector

[uquote="ARV",url="/forum/viewtopic.php?p=3345425#p3345425"]по сравнению с вашим подходом - исключительно одни плюсы.[/uquote]
После запроса температуры нужно подождать, для 12 бит - целых 750ms, так что твой код очень далек от идеала.

ARV · Сообщение **ARV** » Вт апр 03, 2018 15:01:45

Reflector писал(а):После запроса температуры нужно подождать, для 12 бит - целых 750ms, так что твой код очень далек от идеала

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

Reflector

[uquote="ARV",url="/forum/viewtopic.php?p=3345454#p3345454"]функция get_temperature может не возвращать управление до конца ожидания, может возвращать предыдущее значение до окончания преобразования - это тонкости её внутренней реализации, которая, как я и написал, может быть любой.[/uquote]
Так вроде Ivanoff-iv начал с того, что вот есть функция GetTemp(), внутри конечный автомат, из кода ее периодически вызываем... У тебя в примере циклично вызывается get_temperature(), реализация может быть какой угодно, в том числе и тот же автомат, если не хотим ждать. Существенная разница в чем?

ARV · Сообщение **ARV** » Вт апр 03, 2018 15:28:59

Reflector писал(а):Так вроде Ivanoff-iv начал с того, что вот есть функция GetTemp(), внутри конечный автомат

уж не знаю, с чего он начал, но закончил он вот этим:

Ivanoff-iv писал(а):а у меня нет навороченного обработчика и переходов к над/подпрограммам - просто линейный код разбвавленный IF и switch-case...

и дальнейшие мои рассуждения уже об этом.

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

Reflector писал(а):Существенная разница в чем?

Разница в том, что человек реализует автомат в прерывании. Причём, наживает себе гемор с разделением кода на куски, чтобы вовремя отдать управление обратно.
Ему тут ОС то, скорее всего, и не понадобится совсем. Всё перенести в основной цикл и грамотно распределить задачи (пусть даже тем же автоматом).

Ivanoff-iv

извините, пришлось отлучиться
1) если бы меня в текущем положении дел всё устраивало - я бы сюда не написал...
2) про ОПО там не такой код и его я не пишу, пока нет прав. но смотреть и разбираться в этом коде приходится. там не РТОС, там скорее виртуальная машина (сначала грузится система отладки, которая позволяет на горячую отслеживать и изменять переменные, флаги...) а сам "полезный" код очень линеен.
3) макарон получается немного, вот функцию вы вызываете и она пока датчик не ответил (отдельный вопрос определения что датчик ответил внешнее прерывание или от таймера? опустим пока, но потом всёравно над этим придётся подумать) допустим вылетает со старым значением, чтоб код не подвесить, тогда всё равно будет результат и его придётся обработать; а если виснет, то в это время на её уровне мы ничего не сможем делать.
на счет функций - да это подпрограмма со своим окружением, но если хотите - напишу всё через дефайн

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

Добавлено after 13 minutes 7 seconds:
размещение и компоновку кода я продумал, с этим вопросов нет.
пишу, чтобы получить совет - как красивее это всё оформить,
задача сделать конструкцию, чтобы при наступании на её запоминалась позиция выполнения и подпрограмма завершалась, а при следующем запуске подпрограммы (возможно там ответная конструкция) вернуться на прежнее место выполнения кода.

viiv

[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=3345603#p3345603"]задача сделать конструкцию, чтобы при наступании на её запоминалась позиция выполнения и подпрограмма завершалась, а при следующем запуске подпрограммы (возможно там ответная конструкция) вернуться на прежнее место выполнения кода.[/uquote]

Хм. Классическое переключение контекста на другую задачу. Тогда как обычно: сохраняем контекст (все регистры + адрес возврата), далее, в общем случае начинает работать планировщик, который определяет, какой задаче дать процессорное время. Естественно, для каждой задачи требуется память (сообственно дескриптор задачи, стек задачи).
Или я не понял твои хотелки?

ЗЫ. Какого рода совет нужен?

ARV · Сообщение **ARV** » Вт апр 03, 2018 18:58:11

Ivanoff-iv писал(а):а чем код конечных автоматов тяжел?

он не столько тяжел, сколько сложен для понимания. да и получается путаным частенько после пары-тройки корретировок

Ivanoff-iv писал(а):задача сделать конструкцию, чтобы при наступании на её запоминалась позиция выполнения и подпрограмма завершалась, а при следующем запуске подпрограммы (возможно там ответная конструкция) вернуться на прежнее место выполнения кода

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

viiv писал(а):Классическое переключение контекста на другую задачу

характерное для многозадачных ОС. к чему это в собственных поделках - пока не ясно. особенно, если мы говорим о малоресурсных МК типа AVR

Ivanoff-iv писал(а):допустим вылетает со старым значением, чтоб код не подвесить, тогда всё равно будет результат и его придётся обработать; а если виснет, то в это время на её уровне мы ничего не сможем делать.

давайте неспеша разберемся. если функция не виснет, то очевидно, что её результат следует обработать. и это очень правильно и логично. задача функции - сделать свои дела и сообщить наружу о результате, задача "главного" цикла - понять, что с этим результатом делать. и очень даже хорошо, когда именно так. в частности, есть и стандарты, ПРЕДПИСЫВАЮЩИЕ только так и делать, т.е. нельзя игнорировать результат функции.
а теперь вторая часть вашего рассуждения - про зависшую функцию. вы абсолютно правы, что в этом случае на уровне вызывающего такую функцию кода все подвисает. но это абсолютно не касается фоновых процессов, работающих по прерываниям, например, динамической индикации или чего-то еще. поэтому, если функция должна работать долго - пусть работает. а вот если она зависла из-за ошибки, то и в вашем случае с автоматом состояний все будет стоять колом... поэтому для случая ошибок в коде вообще все равно. и, кстати, даже ОСРВ тут ничем не поможет: даже если она сумеет прервать "зависшую" функцию, то спустя некоторое время все равно вернется в неё. и та часть кода, которая ждет результатов из этой подло зависшей функции, так никогда и не дождется его, и все ваши старания пойдут коту под хвост.

Ivanoff-iv

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

Добавлено after 40 minutes 49 seconds:
Re: Вопросы по С/С++ (СИ)
хотя нет не разобрался - там для выхода изконструкции применён брейк, а в цикле он скорее всего сделает не то.

наверно GOTO придётся применять.

Добавлено after 53 seconds:
Re: Вопросы по С/С++ (СИ)
завтра поэкспериментирую

Reflector

[uquote="ARV",url="/forum/viewtopic.php?p=3345686#p3345686"]очень странная постановка задачи. тут на форуме не один раз сталкивался с тем, что то одному, то другому начинает хотеться то из прерывания возвращаться не туда, откуда вышел, то из функции возвращаться в другое место... то главный цикл продолжать сначала... что-то и в вашей задаче есть такое, странненькое.[/uquote]
В плюсах сейчас обкатывают coroutines/resumable functions(в VS уже работают), во многих языках корутины идут из коробки. Если это stackless реализация, то компилятор по сути преобразовывает код в конечный автомат, т.е. получается именно то, что Ivanoff-iv и хочет. Не знаю насколько это в данном случае будет эффективно, но хотеть такое совсем не странно, потому подобную функциональность в языки и добавляют.