И сколько тактов длится итерация цикла?

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

Ну и работу ускорителей для циклов с переходами тоже никто не отменял.... кто его знает как оно там команды выбирает и хеширует, то у него есть кусок куда переход, то нет... Это же не полноценный кэш, там банки строк в 4-8 команд, да еще поди и с выравниванием....

бросайте вы ваши критерии истины%)))) и делайте как говорят, отдавайте контроль железным блокам с более четкой времянкой....




ну вот пока ехидно разжевывал, опередили%)))))

Раз такое делаете, располагать это надо в ОЗУ (ещё лучше - CCM, если есть) и писать на ассемблере с учётом межкомандных времянок.

ассемблер тут не причем, человека беспокоит не время, а девиации времени начала исполнения. Расположить в РАМ - да, ассемблер - нет необходимости

Похоже, я приближаюсь к пониманию причин флуктуаций фазы выходного сигнала моего STM32F407, хотя до конца ещё не понимаю. Я провёл очередной эксперимент, и теперь пытаюсь его интерпретировать.
У этого МК имеется две области ОЗУ - процессорная CCM (64К) и присоединённая SRAM (128К), которая ещё сама поделена на две неравные части SRAM1 и SRAM2.
Сначала расскажу как было до сегодняшнего дня.
Использовалась ОЗУ у меня так: в SRAM находились 3 массива - 2 больших видеостраницы и 1 промежуточный массив поменьше (все они байтовые). Все остальные переменные лежали в CCM и использовались как фоновой программой, так и всеми обработчиками. Так вот, когда происходила очистка одной из видеостраниц в коротком цикле фона, переменная цикла и указатель оказывались в CCM, а очищаемые элементы - в SRAM. В этот момент и происходил бросок фазы выходного сигнала МК. Причём бросок на опережение - изображение на мониторе подёргивалось влево.
Теперь сегодня я изменил использование памяти. Одну видеостраницу отправил в CCM, а в SRAM остались только другая видеостраница с пром. массивом.
Картина радикально поменялась. Теперь изображение на мониторе просто перепрыгивает - то левее, то правее в соответствии с переключением отображаемой страницы! Получается, что задержка вывода из CCM и из SRAM отличается очень сильно, а именно на 190 нс. С похожей проблемой столкнулся ещё один страдалец (http://cliffle.com/article/2015/06/11/matrix/#how-to-mess-up-an-entire-scanline). Он свои проблемы объяснил конфликтом шин в Multi-AHB матрице! Если правильно понимаю - к CCM ЦП имеет доступ непосредственно, а к SRAM - через шину AHB3 и матрицу. А порты подключены к AHB1 и подключаются к ЦП через матрицу. Получается, где-то там какой-то конфликт? В общем, STM32F407 скучать не даёт!



Четыре такта (если Вы о цикле ожидания).

Сообщение отредактировал ШСА - Aug 1 2015, 15:42

Это будет последнее средство...

Можно увидеть этот цикл в дизассемблированном виде? Не очень представляю, как он может уложиться в четыре такта.

Покажу, но уже не сегодня.

Взять порт
Взять маску
Если ноль прыгнуть
Прыгнуть на взять порт.
Маски и адреса в регистрах уже, в целом можно, но думаю реально там больше.

Переводить на железо это не последние, а правильное решение. Надо дма подтягивать....

Вы не совсем так как надо используете проц, потому у вас много чего интересного вылезает.

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

Загрузка - 2 такта, сравнение - 1, переход - 2. У меня получается минимум 5.

Не вижу возможности вам не верить), а почему загрузка 2?

Да, что-то такое там и было - все константы и указатели в регистрах, сам цикл в кэше... Скорее всего вы правы.
Вообще-то я не заморачивался на этом и такты по тексту не считал. Включил оптимизацию компилятора, взял осциллограф и измерил. Давно это было. Измеренные значения и показали - флуктуации - до 4 тактов.

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

Одиночная LDR выполняется два такта; последовательность из двух LDR может быть выполнена за три такта (а из трех за четыре и т.д.), если адрес для последующей инструкции не зависит от результата предыдущей.

Ваша правда, другое дело пока лдр искал, нашел что переходы условные бывают 1 такт, правда не вдавался в чем дело.
Ну значит 5 тактов...