сарматъ 0 3 сентября, 2013 Опубликовано 3 сентября, 2013 · Жалоба отсутствие необходимой квалификации как минимум Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 3 сентября, 2013 Опубликовано 3 сентября, 2013 · Жалоба отсутствие необходимой квалификации как минимумСравнить текст двух функций? В одной четыре строки кода, во второй - десять. Даже не смешно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 3 сентября, 2013 Опубликовано 3 сентября, 2013 · Жалоба во первых я не ставил целью кого то рассмешить во вторых, как я понимаю вы являетесь одним из разработчиков системы?, в таком случае спешу вам сообщить, что ваше описание системы, вероятно, имеет смыл доработать, в частности самый конец пункта 3.2.7 "В связи с этим, в большинстве случаев не возникает необходимости размещать код обработки событий на уровне прерываний даже при наличии такого аппаратного контроллера, а использовать прерывания только как источники событий, поместив их обработку на уровень процессов. Это рекомендуемый стиль построения программы." по крайней мере нуждается в существенных оговорках, рекомендуемый вами стиль построения программы при частоте поступления прерываний 10кГц дает потерю обработки около 50% событий, при размещении же обработчика целиком в теле прерывания потери составляют около 10% Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 4 сентября, 2013 Опубликовано 4 сентября, 2013 (изменено) · Жалоба измерил время выполнения 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 4 сентября, 2013 Опубликовано 4 сентября, 2013 · Жалоба рекомендуемый вами стиль построения программы при частоте поступления прерываний 10кГц дает потерю обработки около 50% событий, при размещении же обработчика целиком в теле прерывания потери составляют около 10% Я думаю, что здесь проблема не в стиле, а в программе:) Я на 72МГц STM32F103 спокойно декодирую 100КГц манчестер. С потерями 0% событий. А тут у вас 168МГц и 10КГц. Это совсем небольшая нагрузка. измерил время выполнения sleep и wait таким образом Функция sleep() приостанавливает выполнение потока на заданное число тиков системного таймера. То есть, если таймер тикает раз в миллисекунду, то sleep(10) будет длиться от 9 до 10 мс. При частоте 168МГц это будет 168000*[9..10] тиков DWT. Ваши же числа совсем маленькие для 10 мс. С какой частотой у вас тикает системный таймер? С какой частотой взводится OneSecFlag? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 4 сентября, 2013 Опубликовано 4 сентября, 2013 (изменено) · Жалоба да у меня ошибочная методика измерения времени, с малым значением разобрался - регистры у меня 16 разрядные соотв сохраняется не все 32 разр слово а только его хвост, короче те цифры что я привел выше ни о чем а в вашей задачке на 100кгц сложная логика обработки событий? манчестер это протокол передачи данных типа модбас? у меня - прием и ответ на небольшой eth пакет размером в 100 байт (типа ответ на пинг) Изменено 4 сентября, 2013 пользователем сарматъ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 4 сентября, 2013 Опубликовано 4 сентября, 2013 · Жалоба а в вашей задачке на 100кгц сложная логика обработки событий? В прерывании - минимальная обработка, вычисляю длительность принятого импульса и кладу его в буфер (OS::channel). А собственно анализ - достаточно сложный, но он выполняется в отдельном процессе. Собственно, всё сделано в точности так, как рекомендует документация:) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 4 сентября, 2013 Опубликовано 4 сентября, 2013 (изменено) · Жалоба а приоритет этого процесса наивысший? и этот обработчик вызывается 100 раз за мс? у меня было так template <> OS_PROCESS void TProc5::exec() { Eth_Slave(); } OS::TEventFlag RxFlag; OS_PROCESS void Eth_Slave(void){ for(;;){ RxFlag.wait(); for(;(DMARxDescToGet->StatusÐ_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 4 сентября, 2013 Опубликовано 4 сентября, 2013 · Жалоба а приоритет этого процесса наивысший? и этот обработчик вызывается 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 4 сентября, 2013 Опубликовано 4 сентября, 2013 · Жалоба Вы забыли: а) тег [ code ] б) в начале обработчика прерывания завести объект типа TISRW. Поэтому реальная перепланировка и получение сигнала у вас происходили при вызове перепланировки из какого либо процесса (при вызове функции какого-либо сервиса ОС) или же после прерывания ситемного таймера. Видимо поэтому часть сигналов и была потеряна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 4 сентября, 2013 Опубликовано 4 сентября, 2013 (изменено) · Жалоба спасибо, не помню ставил ли я эту строчку... в другом прерывании она есть а тут не помню, сейчас еще раз попробую этот вариант да действительно мой косяк сейчас сделал все работает так же как и с полной обработкой в теле прерывания, еще раз спасибо почитал про OS::channel да создатели молодцы очень красивая система Изменено 4 сентября, 2013 пользователем сарматъ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 19 сентября, 2013 Опубликовано 19 сентября, 2013 · Жалоба антоха а в планах не стоит для ф417 контроллера порт сделать? это тот который с периферией для aes Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 19 сентября, 2013 Опубликовано 19 сентября, 2013 · Жалоба А какая разница с точки зрения порта? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 19 сентября, 2013 Опубликовано 19 сентября, 2013 (изменено) · Жалоба сейчас вот подумал может действительно никакой, просто там доп регистры есть для поддержки шифрования, но ведь скажем регистры управления какой нить spi тоже же не сохраняются, похоже меня просто в виртуализацию устройств занесло Изменено 19 сентября, 2013 пользователем сарматъ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться