[сарматъ 0]

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

[Сергей Борщ 119]

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

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

[сарматъ 0]

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

 

во вторых, как я понимаю вы являетесь одним из разработчиков системы?, в таком случае спешу вам сообщить, что ваше описание системы, вероятно, имеет смыл доработать, в частности самый конец пункта 3.2.7

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

[сарматъ 0]

измерил время выполнения 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...

 

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

 

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

 

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

Изменено 4 сентября, 2013 пользователем сарматъ

[AHTOXA 14]

рекомендуемый вами стиль построения программы при частоте поступления прерываний 10кГц дает потерю обработки около 50% событий, при размещении же обработчика целиком в теле прерывания потери составляют около 10%

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

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

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

[сарматъ 0]

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

 

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

Изменено 4 сентября, 2013 пользователем сарматъ

[AHTOXA 14]

а в вашей задачке на 100кгц сложная логика обработки событий?

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

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

[сарматъ 0]

а приоритет этого процесса наивысший? и этот обработчик вызывается 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();

}

 

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

Изменено 4 сентября, 2013 пользователем сарматъ

[AHTOXA 14]

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

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

extern "C" void ETH_IRQHandler(void)

{

ETH_DMAClearITPendingBit(ETH_DMA_IT_R | ETH_DMA_IT_T);

RxFlag.signal_isr();

}

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

    OS::TISRW ISRW;

 

[Сергей Борщ 119]

Вы забыли:

а) тег [ code ]

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

[сарматъ 0]

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

 

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

 

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

Изменено 4 сентября, 2013 пользователем сарматъ

[сарматъ 0]

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

[AHTOXA 14]

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

[сарматъ 0]

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

Изменено 19 сентября, 2013 пользователем сарматъ