отсутствие необходимой квалификации как минимум

Сравнить текст двух функций? В одной четыре строки кода, во второй - десять. Даже не смешно.

во первых я не ставил целью кого то рассмешить

во вторых, как я понимаю вы являетесь одним из разработчиков системы?, в таком случае спешу вам сообщить, что ваше описание системы, вероятно, имеет смыл доработать, в частности самый конец пункта 3.2.7
"В связи с этим, в большинстве случаев не возникает необходимости размещать код обработки событий на уровне прерываний даже при наличии такого аппаратного контроллера, а использовать прерывания только как источники событий, поместив их обработку на уровень процессов. Это рекомендуемый стиль построения программы." по крайней мере нуждается в существенных оговорках, рекомендуемый вами стиль построения программы при частоте поступления прерываний 10кГц дает потерю обработки около 50% событий, при размещении же обработчика целиком в теле прерывания потери составляют около 10%

измерил время выполнения sleep и wait таким образом

volatile uint32_t hgth;
hgth=DWT_CYCCNT;
sleep(10);
res_table.uregs[55]=DWT_CYCCNT-hgth;

volatile uint32_t hgth;
hgth=DWT_CYCCNT;
OneSecFlag.wait();
res_table.uregs[56]=DWT_CYCCNT-hgth;

получилось в первом случае 41000 тактов, во втором - 31000...

антоха это действительно эти функции выполнятся такое время или у меня что-то не так в программе?

кто-либо измерял аналогичные задержки в фриртос или иных системах?

похоже я что то не то измеряю

Сообщение отредактировал сарматъ - Sep 4 2013, 08:27

Я думаю, что здесь проблема не в стиле, а в программе Я на 72МГц STM32F103 спокойно декодирую 100КГц манчестер. С потерями 0% событий. А тут у вас 168МГц и 10КГц. Это совсем небольшая нагрузка.

Функция sleep() приостанавливает выполнение потока на заданное число тиков системного таймера. То есть, если таймер тикает раз в миллисекунду, то sleep(10) будет длиться от 9 до 10 мс. При частоте 168МГц это будет 168000*[9..10] тиков DWT. Ваши же числа совсем маленькие для 10 мс. С какой частотой у вас тикает системный таймер? С какой частотой взводится OneSecFlag?

да у меня ошибочная методика измерения времени, с малым значением разобрался - регистры у меня 16 разрядные соотв сохраняется не все 32 разр слово а только его хвост, короче те цифры что я привел выше ни о чем

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

Сообщение отредактировал сарматъ - Sep 4 2013, 08:49

В прерывании - минимальная обработка, вычисляю длительность принятого импульса и кладу его в буфер (OS::channel).
А собственно анализ - достаточно сложный, но он выполняется в отдельном процессе. Собственно, всё сделано в точности так, как рекомендует документация

а приоритет этого процесса наивысший? и этот обработчик вызывается 100 раз за мс?
у меня было так

template <>
OS_PROCESS void TProc5::exec()
{
Eth_Slave();
}


OS::TEventFlag RxFlag;

OS_PROCESS void Eth_Slave(void){
for(;;){
RxFlag.wait();
for(;(DMARxDescToGet->Status&ETH_DMARxDesc_OWN) == (uint32_t)RESET;){
формирование отклика на прерывание - 5us;
}
}
}

extern "C" void ETH_IRQHandler(void)
{
ETH_DMAClearITPendingBit(ETH_DMA_IT_R | ETH_DMA_IT_T);
RxFlag.signal_isr();
}

вообще возможность послать сигнал в процесс из прерывания оч красива

Сообщение отредактировал сарматъ - Sep 4 2013, 11:16

Нет, приоритет средний. Были более приоритетные задачи. И вызываться(просыпаться) он мог реже, чем 100 раз за мс. События копятся в очереди, и обрабатываются асинхронно, когда есть для этого время.

У вас не хватает обязательной строчки в начале обработчика прерывания:

Вы забыли:
а) тег [ code ]
б) в начале обработчика прерывания завести объект типа TISRW. Поэтому реальная перепланировка и получение сигнала у вас происходили при вызове перепланировки из какого либо процесса (при вызове функции какого-либо сервиса ОС) или же после прерывания ситемного таймера. Видимо поэтому часть сигналов и была потеряна.

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

да действительно мой косяк сейчас сделал все работает так же как и с полной обработкой в теле прерывания, еще раз спасибо

почитал про OS::channel да создатели молодцы очень красивая система

Сообщение отредактировал сарматъ - Sep 4 2013, 19:33

антоха а в планах не стоит для ф417 контроллера порт сделать? это тот который с периферией для aes

А какая разница с точки зрения порта?

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

Сообщение отредактировал сарматъ - Sep 19 2013, 09:54