Ну допустим
//-------------------------------------------------
class TTimer : public OS::TEventFlag
{
int Delay;
int Setting;
public:
TTimer(x) { Setting=x;Delay=x;};
void Run(void) { if(--!Delay) {Delay=Setting; FL.Signal();};};
};

TTimer Tim100(100);
Все нормально, но мы откажемся от возможности начальной инициализации TEventFlag (только по умолчанию). Но это не страшно.


Понятно. Я почему-то подумал про for процесса.
PS. Я вчера тоже под конец дня зациклился.

Вчера был явно день торможения, хотя у меня, например, выходные прошли без возлияний :

Мущщины, я в упор не понимаю, почему вы используете для генерации задержек флаг события, а не специально существующую для этого функцию Sleep. Ведь она легче и быстрее, а флаг тянет за собой дополнительную функциональность, которая здесь не используется. Оверхед и загромождение кода.

Вопрос стал о точном среднем выдерживании по времени процессных задач (ради чистого искусства).
PS. Предложение. Давайте обсудим какую-нибудь полезную тему типа "Обмен ModBus пакетами средствами scmRTOS".
Я знаю, у Сергея есть наработки, у меня тоже кое-что есть.

Нету. С MODBUS никогда не работал.


Мы всех окончательно запутали Я в последних сообщениях обсуждал возможность использовать какой-либо сервис как члена какого-либо объекта. А против Sleep() не возражал, только отметил, что для периодического выполнения какого-либо куска время задержки надо бы рассчитывать, чтобы вычесть из него собственно время выполнения самого полезного кода.

Ну, и пожалуйста - заверните Sleep в свой объект TTimer, внутри которого будут вычисляться точные значения аргумента Sleep, и все. Флаг события-то тут зачем?

Хорошо, тогда предлагаемая тема для обсуждения "Обмен пакетами по RS485 с помощью средств scmRTOS".


Идея ясна.

Я так понял, что молчание - знак согласия. Ну тогда поехали.

Вопросы для обсуждения (хочется применительно к LPC).
Выскажу свое видение вопроса.
1. Приоритет прерывания по приему символов .
Для определенности. Выше системного таймера, но ниже, чем готовность данных ADC.
2. Для обработки принятого пакета - формирования пакета ответа - передачи подготовленного пакета организуется свой процесс (назовем процессом на передачу).
2.1. Запуск процесса на передачу для master.
- запуск процесса осуществляется по таймеру временных интервалов (пакет запроса с передачей);
- запуск процесса от органов управления (с передачей);
- обработка принятых данных от slave (без передачи).
2.2. Запуск процесса на передачу для slave.
- по истечению таймаута на отсутствие принятых символов (с передачей или без нее);
- по каким-то явным признакам прошедшего или сбойного пакета запроса (с передачей или без нее).
3. Прерывание по приему символов осуществляет запись в приемный буфер, с которым и производится работа в процессе на передачу.

Думаю, вопросов для начала обсуждения пока достаточно.

"UP"

+1
Более того - если от момента, когда время Sleep для данного процесса истекло (его занесли в готовые), до того, как он реально получит управление, проходит меньше времени одного системного тика - то вообще ничего не надо. В среднем будет всё нормально.
Конечно - если процесс по приоритету где-то внизу и старшие вечно толпятся - то будет проскакивать. Тогда действительно обернуть в класс с поведением "типа OCR += PERIOD".
А если задержки до "всплытия" процесса могут быть такими большими, что оставшееся время может
оказаться равно 0 - то оно и "отрицательным" может оказаться, тут уж переход к TEventFlag тоже ничего не даст.

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

Привет всем!
решил поиграться с scmRTOS. Скачал исходники версии 3.0. Скомпилил - НО то ли день не мой, то ли дело не в бобине...
Компилятор IAR 4.30A/W32 [Evaluation] (4.30.1.3). Попробовал поэмулировать ОС с примером из папки [3-Channel] в AVRStudio 4.12 SP2.
В конфиге scmRTOS_config.h установил

После запуска симулятор выдает предупреждение

Это возникает после выхода из процедуры OS_Start(sp)
Где грабли, не пойму. Просвятите, плиз. Сенькс.

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

Расскажу по порядку, что у меня происходит:

1. выполняется конструктор OS::Kernel

2. выполянется конструктор OS::PrioMaskTable

3. выполняются последовательно кострукторы 3-х процессов

4. вызывается OS::Run()

5. в OS::Run() вызывается OS_Start(sp)

6. Попадаем в OS_Target_asm.s90 на метку OS_Start:

7. Далее переход на метку L_RestoreContext:

8. После команды RET симулятор вываливает

Вроде бы нашел косяк:
Я использую в проекте ATmega128, под него и компилил проект. После мучительных размышлений на 1,7 кБайтами кода попробовал сменить МК на м64 - все заработало!!! Сразу возникла мысль про RAMPZ!
В файле OS_Target_asm.s90 есть макросы #if HAS_RAMPZ == 1 ... #endif - так вот, они почемуто не хотятЪ работать:-( Сделал в данном файле принудительно #define HAS_RAMPZ 1 - все заработало... Я в тонкостях компиляторов не сильно силен, как победить баг?

Макрос HAS_RAMPZ генерируется компилятором из заданного процессора. Но это компилятором. А ассемблер, насколько помню, не поддерживает задание конкретного типа процессора, там все опции целевого процессора надо задавать через -v и -m опции. Соответственно, означенный макрос ассемблер не генерирует, поэтому его надо задавать руками. Удобно сделать это через опции проекта, а не править исходник. Если сборка идет из командной строки (makefile etc), то задать макрос через ключ командной строки -D, если из оболочки, что в опциях проекта, в разделе асма, во вкладке define указать макрос.