привет✋, нашёл я статью - http://easyelectronics.ru/avr-uchebnyj-kurs-ocenka-zagruzki-kontrollera.html, мне показалось таковая реализация мониторинга проста и эффективна. !нО, не писал бы я сюда если бы у меня не возникли вопросы. А именно как это реализовать на практике, в теории то оно ВСЁ идеально. т.е по сути для подобного мониторинга стоит всего-то перед выполнением задачи в монитор порты вывести "1" и в конце программы сделать вывод "0", это позволило бы средствами самой Ардино иде мониторить график работы процессора. (оооооочень утрированно). так вот малоли у кого есть исходник или правки реализации. буду благодарен каждому толковому комментарию, спасибо.
Ну тут не все так просто. В статье описан вариант с диспетчером задач, или очередью сообщений. В многозадачных системах все задачи ждут событий, нет событий задача стоит в его ожидании, механизмы - разные: обменники, семафоры, каналы, очереди, и т.д. У задач есть приоритеты, самый низкий - у задачи idle. Поэтому, чем больше процессорного времени достается idle тем меньше загрузка системы. Если idle время не выделяется - загрузка слишком высокая. Тут данный вариант - проходит. А вот с применением стандартного, для обычных ардунщиков стиля написания программы, для МК все несколько не так. Большей частью все, не столь критичное к быстродействию, - запихивается в loop. Тут мы можем в начале loop() просто считывать значение millis() или micros(), и вывести в порт максимальное, минимальное и среднее значение за какое-то кол-во циклов loop. Сразу станет ясно насколько тяжел код loop, и не только loop. Есть же еще прерывания. А вот тут нужно быть как можно аккуратнее. Так как слишком длинный код в прерывании, может не успеть доработать до возникновения следующего прерывания. Например в прерываниях по таймеру, я обычно смотрю регистры таймера перед выходом из прерывания, чтобы понять, через сколько он щелкнет снова и прикинуть запас по времени.
статья очень старая и неактуальная. Неактуальная она и для 8-ми и 16-ти битных МК, которые программируются в "лоб". Для оценки энергоэффективности работы МК (про график работы процессора МК здесь говорить глупо - у 8-ми и 16-ти битных МК проц всегда нагружен на 100%, или 0% - состояние IDLE) существуют различные амперметры. Для MSP430 я уже про такие рассказывал. У SiLabs EnergyProfiler, но по ощущениям, он хуже, чем у TI. У других производителей тоже есть такие штуки. В ардуине такой функции нет. Если мы говорим про встроенные RTOS системы, то есть прекрасный инструмент uc/Probe. Но он оцениает не энергопотребление, а именно загрузку процессора активными задачами (IDLE задача в простых процессорах тупо исполняет 'nop', т.е. ядро всё равно загружено). У segger тоже есть такой инструмент, но называется - не помню))
честно говоря меня мало интересует энергопотребление мк))) хочется просто знать что и когда делает процессор(как на том примере), выводя всю информацию в плоттер. лично мне кажется это очень удобно для отладки большой программы)
для этого существует дебаггер. На старых тинях, для которых у меня нет дебаггера, я в теле программы расставлял числа и выводил их через SPI. Так я понимал, как выполняется программа. Но на полноценный отладчик это никак не похоже.
Элементарно. Существует по крайней мере два способа: 1 - CPU Events ставим в событиях USART - Full Trace. 2 - в обработчике прерывания USART RX делаем Break Point.
В какой именно регистр и зачем вообще там что-то менять? И ещё - кто мешает поставить в симуляторе сам порт и соединить его с дурдуиной и там-же лог. анализатор. Имеем картину маслом по обмену данными всего порта.
