Сейчас точно не скажу,делал давно,но равномерный захват был,точно. Это видно если подать пилообразный сигнал на вход. Изгибов наклона пилы не наблюдал, подъем ровный,прямой. Опять же все укладывалось в 320 отсчетов,ровно по ширине экрана. На видео это видно. При подсчете получается 64МГц такт / 0,05МГц сигнал /320 пикселей = 4
писал именно
buff = GPIOA->IDR;
i++;
в случае buff[i++] команды асм могут быть другие
[uquote="Sergi",url="/forum/viewtopic.php?p=3566689#p3566689"]писал именно
buff = GPIOA->IDR;
i++;
в случае buff[i++] команды асм могут быть другие[/uquote]
Команды другие могут быть и с другим компилятором или уровнем оптимизации, вопрос в том какие там в принципе могут быть команды чтобы получилось 4 такта для 320 отсчетов. Максимум 200-250 отсчетов, тогда если массив будет локальный, а элементы массива 32-х битными компилятор может использовать индексирование относительно SP и действительно получится 4 такта. Реально я сейчас так сделал и первые 32 STR индексируются относительно обычных регистров, потом еще 68 - относительно SP, дальше первой сотни уже идет инкремент и это больше 5 тактов. Не получается как ты говоришь, даже в теории, тем более реальная картина совсем не похожа на сказанное ранее, типа 2 такта на чтение из IDR, 1 такт на сохранение buff, 1 такт на инкремент...
Я уже показал реальную картину на видео. Для себя выяснил что можно сделать захват за 4 такта и главное быстрее чем через DMA. Таким способом проверил на F103,F207. Там захват за 6 тактов, DMA- за 7. Все это проверял когда делал свой второй осциллограф. С целью удешевления и повышения скорости ввел внешний буфер на ОЗУ. F030 + ОЗУ вышло чуть дешевле F407 и захват за один такт.
Исходники тестов затерялись на старом компе, я не старался их сохранить.
[uquote="Sergi",url="/forum/viewtopic.php?p=3566889#p3566889"]Исходники тестов затерялись на старом компе, я не старался их сохранить.[/uquote]
Зачем там исходники? Дублируешь чтение из порта 320 раз, замеряешь таймером время выполнения, делишь на 320, если получилось 4 такта, что очень сомнительно, то показываешь что там компилятор нагенерил... Я сам делал осциллографы, на F0/F3/F4, но там был еще ЛА и т.д., данные отправлялись на комп и там их можно было рассмотреть в том числе в числовом виде. Если генеришь меандр и в буфере размером десятки KB длительности всех уровней абсолютно одинаковые, значит все нормально, а у тебя аналоговый сигнал который умещается на мелком экране, даже если он выглядит похожим, это еще ни о чем не говорит. Я когда первые разы захватывал при помощи DMA, то ожидал окончания его работы проверяя флаг, потом решил по захваченному сигналу посчитать частоту и она немного не сходилась, хотя визуально все было очень похоже. Оказалось проверка флага добавляется периодические тормоза, стал вгонять мк в сон и стало считать правильно. А буфер на 320 выборок слишком мелкий чтобы обнаруживать подобные ошибки, тем более на аналоговом сигнале, наверняка во многих самодельных осциллах такая ошибка есть...
[uquote="Sergi",url="/forum/viewtopic.php?p=3566954#p3566954"]Конкретно но видео цифровой сигнал. Подключен к PC6. Это уровни 0 и 64.[/uquote]
Цифровой сигнал с лесенкой на меандре? Ну ладно
Добавлено after 33 minutes 53 seconds:
Вообще компилятор вполне мог обойтись одним 5-ти битным смещением. Читаем 32 раза, прибавляем к указателю на массив 32, читаем дальше... Для 320 выборок прибавлять нужно 9 раз, даже если в худшем случае дополнительно добавится 18 тактов, то среднее количество таковых на выборку будет 4.06, визуально от 4 не отличить, хотя смещение в конце будет достаточно ощутимое. В любительских осциллографах такую погрешность никто не заметит, хотя, конечно, было бы неправильно говорить, что захват происходит каждые 4 такта.
Лесенка на меандре из-за вывода линии соединения точек по алгоритму Брезенхе́ма. На видео я меняю частоту и скважность, можете сравнить рисунок из 10 периодов при частоте 500кГц.Я с вами не спорю, еще раз говорю, я для себя выяснил - на F030 захват и сохранение происходит за 4 такта, линейность захвата проверял на пилообразном сигнале. Меня это устроило.
Задержка в 18 тактов в моем случае 0,28 мксек на фоне периода сигнала в 2 мксек была бы заметна (14% периода).
[uquote="Sergi",url="/forum/viewtopic.php?p=3567018#p3567018"]Лесенка на меандре из-за вывода линии соединения точек по алгоритму Брезенхе́ма.[/uquote]
По алгоритму Брезенхе́ма замечательно рисуются прямые линии без никаких лесенок.
На видео я меняю частоту и скважность, можете сравнить рисунок из 10 периодов при частоте 500кГц.Я с вами не спорю, еще раз говорю, я для себя выяснил - на F030 захват и сохранение происходит за 4 такта, линейность захвата проверял на пилообразном сигнале. Меня это устроило.
Задержка в 18 тактов в моем случае 0,28 мксек на фоне периода сигнала в 2 мксек была бы заметна (14% периода).
18 тактов - это максимум, может быть и 9 или нечто среднее, а если индексирование относительно SP, даже одного сложения хватит и добавится всего 1-2 такта, но это скорее всего нужно самому на ассме писать... А у тебя еще и внешний генератор, по нормальному нужно генерить тестовый сигнал тем же мк, которым захватываешь. Недавно меня в одной из тем пытались убедить, что кварц на 16MHz работает нормально если тактироваться от него напрямую, но если затактировать от него PLL, то частота кварца становится 4MHz. Стали разбираться и оказалось, что PLL тактируется от HSI/2 Так что я не знаю, вдруг в данном случае тоже по ошибке выбран HSI, мк в разгоне, частота может уплыть на несколько процентов, а это десяток лишних выборок. Только взглянув на сгенерированный код можно сказать что-то более определенное...
На счет лесенок. Соединяя две точки А(0,0) и В(1,64) прорисовывается линия АХ(0,0 0,31) и линия ХВ(1,32 1,64). Отсюда ступенька.
Не соединяя точки видно только горизонтальные полоски по координате У0 и У64.
Уверяю что с частотой все было в порядке, до сих пор настройка тактирования переходит из проекта в проект.
Пробовал подавать сигнал с собственного таймера F030. Тогда картинка вобще стоит ровно, не колышется. От внешнего генератора есть определенные искажения, их видно.
[uquote="Sergi",url="/forum/viewtopic.php?p=3567119#p3567119"]На счет лесенок. Соединяя две точки А(0,0) и В(1,64) прорисовывается линия АХ(0,0 0,31) и линия ХВ(1,32 1,64). Отсюда ступенька.[/uquote]
Ступенька потому что вместо вертикальной прямой зачем-то рисуется наклонная... Посмотри в на любым скринах ЛА, там есть ступеньки?
Уверяю что с частотой все было в порядке, до сих пор настройка тактирования переходит из проекта в проект.
Тот товарищ меня убеждал, что дело точно в кварце, потому что сейчас у него частота делится на 4 на одной серии STM32, несколько лет назад такое было на другой и в добавок на STM8 та же картина Очевидно, настройки тактирования там тоже переходят из проекта в проект
Пробовал подавать сигнал с собственного таймера F030. Тогда картинка вобще стоит ровно, не колышется. От внешнего генератора есть определенные искажения, их видно.
Ладно, наверно я сильно многого хочу, в конце концов не каждый готов выделить 5 мин своего времени чтобы замерять время выполнения тестового примера, тем более если он это делал раньше и уверен, что все работало как положено
2 Reflector
Вы совершенно правы, виноват я. По старой памяти ошибался.Заставили таки меня поэкспериментировать. Спасибо.
Действительно каждые 32 отсчета перезаписывается указатель. Итого 9 раз. Как вы и писали. Из-за этого в конце появляется смещение в 2 отсчета. Это еще зависит от типа.
Сейчас использую версию armcc 5.06. Интересно можно ли так написать, чтобы явно указать ячейку памяти куда сохранять IDR? Тогда бы не было дополнительных команд.
Еще раз благодарю за потраченное на меня время.
При сохранении через указатель каждые 32 отсчета к LDR и STRH добавляется ADDS
[uquote="Sergi",url="/forum/viewtopic.php?p=3568241#p3568241"]Интересно можно ли так написать, чтобы явно указать ячейку памяти куда сохранять IDR? Тогда бы не было дополнительных команд.[/uquote]
Писать нужно на инлайн ассме, иначе в любой момент компилятор может перестроить все по-своему. Для F3 я делал так:
Спойлер
На F0 части команд нет, лучшее что я вижу - это дополнительно сохранять SP и индексироваться относительно него с 8-ми битным смещением, но для 320 выборок где-то в середине придется один ADDS добавить. Если буфер большой, как было у меня, тогда запускаем DMA и сразу вызываем __WFI(), будет ровно 5 тактов.
Понятно. Но пока особо критичных секций у меня не предвидится.
Кстати чисто случайно сегодня заглянул внутрь SEGAmegadrive2. Там стоит 2 штуки 8ми битных SRAM по 32к в параллель. В пяти приставках стоят разные микросхемы и скорости у всех разные - от 10нсек до 25нсек. Китайцы ставили все подряд.
Можно замутить буфер хоть для дисплея, хоть для осциллографа. Халява так сказать.
Очень вряд ли. Разве что следующая команда считывается при выполнении предыдущей (это похоже на правду. Во всяком случае, в отличии от большинства команд переходы занимают 2 такта, а команды записи в регистр срабатывают на следующем такте). Во всяком случае, там абсолютно предсказуемые длительности выполнений и задержки.
[uquote="VladislavS",url="/forum/viewtopic.php?p=3565739#p3565739"]Что за АЦП? Наверняка можно какую-нибудь шину аппаратную к нему организовать. Ногодрыг - последнее дело.[/uquote]
Почему? Дешево и сердито.
Добавлено after 4 minutes 29 seconds:
[uquote]В разгоне F030 с Flash latency =0 работал до 40-42МГц, с =1 до 75-80МГц.
Так и есть, только не все знают, что латентность для F0 можно хоть 7 выставить, а 2 реально может пригодиться, если разгонять до 80+ MHz.[/uquote]
А есть смысл в разгоне, если пропорционально латентность увеличивается? Или я чего-то не понимаю?
В STM32, как и в других МК, есть конвейер. Длина его разная. И теоретически при более длинном конвейере обращаться к FLASH можно реже при более широкой шине данных. С учетом переходов производитель приводит число DMIPS на МГц. Ну для F0 это имеет смысл с 1WS. Гарантировано заявленная частота работы не является абсолютной в узком применении или особых условиях окружающей среды. Вот мы и разгоняем на свой страх и риск.
В современных дешевых телефонах очень часто стоит связка QUAD SPI FLASH и CPU, где оператива и загрузчик в ядре, а программа снаружи. SPI FLASH уже довольно шустрые.
[uquote="protoder",url="/forum/viewtopic.php?p=3579365#p3579365"]А есть смысл в разгоне, если пропорционально латентность увеличивается? Или я чего-то не понимаю?[/uquote]
Циклы ожидания же не к каждой инструкции добавляются, а только когда нужно перезагружать конвеер, например, при переходах. И только если нет кеша инструкций, из дешевых мк небольшой кеш есть даже у новых G0.
[uquote="Reflector",url="/forum/viewtopic.php?p=3566214#p3566214"]латентность для F0 можно хоть 7 выставить[/uquote]Смысл если выше 96 МГц стабильно не работает?
protoder писал(а):А есть смысл в разгоне, если пропорционально латентность увеличивается?
Разгоняют иногда для увеличения частоты тактирования периферии. Например нужен 16-ти битный ШИМ и чтобы повысить его частоту, нужно разогнать МК.
Sergi писал(а):В современных дешевых телефонах очень часто стоит связка QUAD SPI FLASH и CPU
64 ГБ QUAD SPI FLASH? Подскажите модель микросхемы.
Даже если так, программа вероятнее всего копируется из флешки в ОЗУ и оттуда выполняется. Не зря же телефон так долго загружается.
[uquote="Мурик",url="/forum/viewtopic.php?p=3580121#p3580121"]Смысл если выше 96 МГц стабильно не работает?[/uquote]
Смысл в том, что можно выставить 2WS, без которых вряд ли будет стабильно работать на 96MHz, а многие думают, что максимум - это указанные в документации 1WS.
Подскажите модель микросхемы.