Либо записать в массив параметры таймера и отдать процесс записи DMA.

Простите за долгое отсутствие - текучка и изучение мануала по наводке jcxz. Оказывается, я многое упустил в своё время...
Среда у меня, к сожалению, CooCox. Keil прекрасная штука, но мне не по карману, а программа слишком велика для бесплатной версии.
В прерываниях FPU нигде не используется, только в фоне. Ищу способ запретить сохранять FPU регистры в стек - а их там 32, если не ошибаюсь. Если даже по 1 такту на каждого - это уже масштаб моих флуктуаций!
Идея с DMA мною не отброшена. Я её проработаю, но позже. А пока мне надо научиться отключать Lazy context save - я даже это ещё не могу заставить сделать свой кокос.



Да, таймер считает без прескалера. Инициализируеется так:


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


Поясню, что строка, где "//ждём момента для вывода 1 точки" это и есть интервал от начала прерывания до начала вывода. Вот он то и "плавает". Кстати следующая строка и есть ваше "дернуть ногой".

Сообщение отредактировал IgorKossak - Jul 29 2015, 17:16

Конечно! Если удастся уменьшить флуктуации до 4 тактов, их уже никто не заметит при 168 МГц. А вот с ОЗУ напряжёнка: Там две страницы видеополя находятся - формируемая и отображаемая. Так что особо не разбежишься.

Вы как-то странно мануал читаете....
Lazy context save Вам отключать не надо, он никак не увеличивает время входа, а наоборот - предназначен для уменьшения времени входа в ISR (резервирует место в стеке, но не пишет).
Но так как у Вас FPU в фоне используется, а где-то не используется, то из-за Lazy context save у Вас в этих местах и будет разница во времени входа (но место в стеке при стэкинге всё равно
будет выделяться одинаково!). А вот если Вы, как я советовал, вообще отключите автоматическое сохранение контекста FPU при входе в ISR, то всегда на стек будет сохраняться как в M3 только
8 регистров. Это можно сделать, если в ISR-ах у Вас не используется FPU. Но если есть операционка и FPU используется в разных задачах, то в переключателе задач ОС (программном) надо сделать
сохранение контектса FPU ручками.
У нас в наших изделиях я так и делаю, но не для уменьшения времени входа в ISR, а для экономии стеков задач (делаю FPCCR = 0, а потом сохраняю или не сохраняю контекст FPU в
переключателе задач ручками, в зависимости от того - использует данная задача FPU или нет).

И как это сделать - я Вам уже выше писал: FPCCR = 0. Вы как-то читаете выборочно
И от компилятора это никак не зависит, это Вам надо открыть мануал на ядро M4 и найти там FPCCR.

Советую всё-таки открыть мануал на используемый процессор и поискать там что-нить типа Quad-SPI или SDIO. Они позволяют до 4 линий параллельно выводить.
Тогда возможно каждый байт памяти будет использоваться полностью, а не одна тетрада. Да и загрузка шины при DMA-передаче на такой интерфейс
будет ниже чем при передаче DMA->GPIO.
По крайней мере на Tiva (TM4C129), который я сейчас использую, связка Quad-SSI+DMA идеальна для Вашей задачи.
Даже если Вы не будете использовать DMA, то лучше использовать Quad-SPI чем тот ногодрыг, что Вы сейчас пытаетесь сделать.
О ногодрыге вообще стоит забывать сразу после перехода на ARM. Оставить его AVR-щикам.
SPI Вам жёстко даст ту времянку, которую Вы запрограммируете ему, вместо болтанки с программным таймером и ногодрыгом.

Наконец сегодня дошли руки проверить хоть какие-то гипотезы. Собственно, рабочих гипотез осталось две.
Начну с первой. jcxz предположил, что причиной влияния фоновой программы на время реакции обработчика и является сохранение в стеке регистров FPU и предложил его запретить. Такой запрет не помешал бы работе системы, поскольку FPU в обработчиках прерываний не используется, а значит и состояние FPU от прерывания не изменилось бы.
В STM32F4 это делается просто: FPU->FPCCR &= ~((1U << FPU_FPCCR_ASPEN_Pos) | (1U << FPU_FPCCR_LSPEN_Pos));
В результате явление не исчезло, ну существенно уменьшилось. Т.е влияние фоновой программы на прерывания осталось, но флуктуации времени запуска обработчика прерываний снизились не менее чем в два раза.
Мораль: Количество сохраняемых в стеке регистров ЦП при прерывании зависит не от того, выполняло или нет в этот момент FPU какую нибудь команду, а от того, что записано в регистре CONTROL с помощью FPU->FPCCR.
Поэтому запрещая сохранение регистров FPU можно изменить среднее время реакции обработчиков на внешние события и изменить интенсивность использования стека. Но к флуктуациям времени вызова обработчика в зависимости от команды, выполняемой в этот момент фоновой программой, это не имеет отношения.

Осталась вторая гипотеза. scifi полагал, что время реакции обработчика зависит от длины кэша команд МК. Т.е. механизм такой: если фоновая программа выполняет длительный короткий цикл, в течение которого происходит несколько прерываний, то после первого прерывания из кэша не вытесняется начало обработчика прерывания и все последующие прерывания происходят быстрее.
Чтобы проверить эту идею нужно было очистить кэш команд перед выходом из обработчика.
Я не нашёл (да пока и не искал) такой команды, но чтобы проверить эту идею в фоновой программе внутри короткого цикла вставил вызов небольшой функции, которая ничего полезного не делала, но и ничего не портила. Фактически, цикл перестал быть коротким. Результат - эти флуктуации исчезли!
Мораль сногсшибательная: кэш команд в STM32F4, который так здорово "разгоняет" ЦП, может быть причиной непредсказуемых флуктуаций времени реакции обработчиков на внешние события. Причём флуктуаций весьма чувствительных - до 400 нс, когда используется FPU и включено сохранение его регистров в стеке (это происходит по умолчанию при включении FPU), и когда различные прерывания конкурируют между собой. А управлять этой непредсказуемостью будет фоновая программа!

Так что мой обработчик придётся выбросить.
Всем, кто принял участие в этом мозговом штурме ОГРОМНОЕ СПАСИБО!
И, конечно, jcxz и scifi от меня особая благодарность, за активизацию моих мозгов.




У STM32F407 есть одна неприятная особенность - пины SDIO пересекаются с пинами видеокамеры DCMI. Придётся выбирать. А Quad-SPI там нет.

Сообщение отредактировал ШСА - Jul 30 2015, 19:02

Думаю что всё-же зависит если включено Lazy context save. При этом если FPU не использовался, то место просто резервируется в стеке без реальной записи, а на это такты не тратятся, только память.

Вы хотя бы задумались. А как может быть по другому?!
Какая разница где именно в фоновой задече используется FPU? Если имеется шанс запортить используемые регистры, то их надо сохранять!
Здесь на крайняк, может компилятор грамотно обсчитывать имеется ли в Ваших прерываниях работа с FPU. Но учитывая как работает компилятор, и этого не получается.
Например Вы можете вызвать из прерывания ф-цию, которая использует FPU. Или Вы можете написать обработчик на ассемблере и компилятор даже знать не будет о том, что Вы в прерывании используете FPU. Поэтому действия разработчиков процессора единственно верны.


А здесь Вы просто капитан очевидность!
Именно за счёт этого и получен выигрыш в быстродействии. Я вообще не понимаю что Вас удивляет? Так работают все процы CISC, в частности. И совершенно очевидно, что в Cortex-M7 джитер будет ещё выше.
Он будет в любом процессоре. В процах без кэша он будет меняться на разницу в времени исполнения команд, которые Вы используете в фоновой задаче. Например в AVR, при применении умножения +1 такт.

Поэтому Вам несколько раз настойчиво советуют использовать аппаратные средства либо самого процессора либо внешнего устройства.

А кто говорит, что разработчики из ST что-то сделали неправильно? STM32F4 - серия шикарных микроконтроллеров! Но, как всё шикарное, требуют аккуратного обращения.
А удивляет меня не задержка вызова прерываний, и не джиттер при разборках обработчиков между собой. Это всё общеизвестно. А вот то, что на время вызова обработчика может влиять содержимое фоновой программы - для меня открытие. Я с таким никогда не встречался и не читал о таком. Результат проведённого исследования - понимание механизма взаимовлияния фона на реактивность системы, которое позволит осознаннее выбирать программные средства. Правильно заметил jcxz, что от AVR-ные подходы для ARM-ов не всегда годятся.
И понять это явление помогло именно включённое FPU, которое на порядок увеличило этот эффект, и заставило разбираться до конца.

Нет-нет, рано класть AVR-ные подходы на дальнюю полку. Возьмите многоядерный МК типа LPC4370. Там 3 процессора. Один из них можно натравить на узкую задачу с жёсткой времянкой - и дело в шляпе :-)

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

У вас проц молотит на частое за 100 МГц, при этом из флеши можно выбирать команды на частоте порядка 20 МГц, и должно стать ежу понятно что никакие увеличения шины выбора команд не смогут решить эту разность частот, за исключением линейных участков кода....

А обдумав этот факт становиться понятно что вид программы с точки зрения переходов, должен влиять на времянку выполнения программы.

АВР просто не превысила по своей скорости, скорость флешь, потому там такого и не было. Возьмите АРМ, перепихайте всю программу в ОЗУ и погнали...

Кстати - всё хотелось узнать поподробнее про эти многоядерные LPC: а как там память программ и данных организована?
Общая или для каждого ядра своя? И как шины к памяти проложены?
Можно-ли написать ПО так, чтобы каждое ядро работало со своим набором регионов памяти/шин доступа к ним, оставив только один общий регион для межпроцессорного обмена?
Если всё-таки там ядра конкурируют за какие-либо ресурсы (регионы памяти, шины), или программа так написана, что имеется много
конфликтов по ресурсам, то ядра будут влиять друг на друга (на скорость выполнения кода друг друга).

Конкретно в LPC4370 нет наботной флеши, но есть несколько банков ОЗУ, подключенных разнообразными способами к многопортовому шинному коммутатору. Так что да, там есть возможность распределить банки памяти так, чтобы процессоры трудились, не мешая друг другу.

Согласен. И хотя вы все будете смеяться, но я опять чего-то недопонимаю.
Чтобы не связываться с DMA, решил попытаться использовать захват сигнала через таймер. Но перед этим, чтобы быть уверенным в конечном результате, решил проверить экспериментально верность нашей "гениальной теории".
Способ мне пришёл в голову очень простой: Вызов обработчика происходит по переднему фронту синхроимпульса, и пусть флуктуации вызова обработчика достигают 0,2 мкс. Поскольку длительность этого внешнего синхроимпульса равна 4,7 мкс, то очевидно, что его задний фронт будет гарантированно в то время, когда обработчик уже будет вовсю работать. Значит, если вставить цикл ожидания окончания синхроимпульса и сбрасывать таймер после этого, я должен получить гарантированное избавление от зависимости от времени вызова обработчика, а значит, и от содержимого фоновой программы.
Но эксперимент (критерий истины) показал, что эффект влияния фоновой программы остался! Хотя, величина флуктуаций фазы первого выводимого импульса стала значительно меньше, чем раньше (на глазок - в 2,5 - 3 раза).




А что это такое "наботная?"

Сообщение отредактировал ШСА - Jul 31 2015, 18:31

набортная, на борту проца....