Ребята

Я экспериментировал с камерой OV7670, используя код из GitHub, но код требует, чтобы оптимизация была изменена с -os на -O2

Изменение флага, казалось, оказало значительное влияние на скорость (я не смотрел на размер кода)

Я знаю, что это большие потрясения и могут сломать код, но мне интересно, является ли использование -os лучшим вариантом.

Действительно, размер обычно не является проблемой, так как на самом деле все F103 имеют не менее 128 тыс. Флэш

Глядя на документы GCC
-ОС

Оптимизируйте по размеру. -ОС включает все оптимизации -O2, которые обычно не увеличивают размер кода. Он также выполняет дополнительную оптимизацию, предназначенную для уменьшения размера кода.

-ОС отключает следующие флаги оптимизации:

-Функциональные функции -фалигновые переводы
-Falign-Labels -freorder-Blocks -freorder-Blocks-Algorithm = STC
-Флодер-блоки и частя--fprefetch-ray-arrays
Я проверил Arduino Sam (Due), и они используют -ос, поэтому я думаю, что мы должны, но мне интересно, сколько производительности мы теряем из -за этого, по сравнению с тем, каким бы дополнительным размером были бы эскизы, и является ли увеличение размера эскиза действительно будет проблемой.


эн.глин. Пример OV7670, скомпилированный с -O2, составил 24360 байтов
и с -os был 22732 байта

Лично я не беспокоюсь о 2K

В любом случае. Вероятно, сейчас слишком поздно для Libmaple, но, возможно, стоит рассмотреть для @danielef

Еще одна вещь, которую вы можете проверить: GNU ARM встроено 6-2017-Q1
Это может дать вам повышение скорости без перехода на -O2

[Даниэфф - Солнце 25 июня 2017 г. 6:25] - Еще одна вещь, которую вы можете проверить: GNU ARM встроено 6-2017-Q1
Это может дать вам повышение скорости без перехода на -O2

Спасибо.
Это интересно.

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

OTOH, достигнутая скорость также зависит от индивидуального стиля кодирования, поэтому должно быть возможно достичь высокой скорости даже с -OS, когда вы помните о желаемой скорости. Поэтому держу пари, что LIB OV7670 (без взгляда на это) может быть оптимизирована скоростью, только путем пересмотра стиля кодирования.
Типичный пример: // wait for serial monitor to be connected. while (!(Serial.isConnected() && (Serial.getDTR() || Serial.getRTS()))) { digitalWrite(33,!digitalRead(33));// Turn the LED from off to on, or on to off delay(100); // fast blink }

Я бы жил с -ос (маленькими) оптимизациями на кленовых мини -/ синих таблетках, оптимизации -O2, кажется, помогают в частности на F4
Тем не менее -ос (маленький) по -прежнему предпочтительнее для F4 в качестве режима по умолчанию
Я думаю, что основные причины -O2 быстрее на F4 связаны с «неизбирательной» оптимизацией GCC/G ++ (известно, что компилятор *удаляет коды *)
и что F4 имеет ускоритель памяти арт (ускорение доступа к флэш -памяти к 0 условным ожиданию), что, возможно, заставляет коды запускать * гораздо быстрее
http: // www.STM32duino.com/viewtopic.PHP ... &начало = 160
Среди некоторых из этих -о2 оптимизации -O3 -это *развернуть петли *, это не сработает, если коды работают непосредственно от Flash, это было бы просто узким местом и занимает больше вспышки/памяти. Следовательно, -os (маленький), вероятно, лучше для STM32 F103
всего 2 цента

ХОРОШО

Я оставлю это как -os, но мне нужно выяснить, почему код камеры работает медленно и не буду работать в оптимизации

СДЕЛАТЬ СКОРОСТЬ - 100 МГц может решить ваши проблемы

* Единственная точность* Плавающая точка на F4* очень быстро* частично из -за аппаратного FPU X2 (там 2 FPU) + Ускоритель памяти арт
http: // www.STM32duino.com/viewtopic.PHP?F = 39&T = 2001
Следовательно, если есть много * единственной точности * плавающей запятой Calcs F4 может быть «правой платформой» для ее запуска
Это, вероятно, выиграет от оптимизаций -O2 и -O3
С критериями Whetstone 500 мл
http: // www.STM32duino.com/viewtopic.PHP ... &начало = 160
Я думаю, что F4 может буквально сможет «сжать на лету» с плавающей точкой jpeg и т. Д

[Пито - Солнце 25 июня 2017 г. 14:29] - СДЕЛАТЬ СКОРОСТЬ - 100 МГц может решить ваши проблемы

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

Кроме того, если я смогу подтолкнуть SPI ILI9341 быстрее, это поможет.

Я думаю, что QVGA должна быть возможна при 7 кадров в секунду на 72 МГц, но потребуется двойная буферизация данных пикселей с камеры.

Я не уверен, что будет работать Max Speed ​​Spi для ILI934-.

40 МГц+

Роджер, у вас также есть все эти нопы в вашем коде?
Кажется, что они служат точным временем.
Что я не понимаю, на какой частоте работают эпиксельные часы? Это должно быть pllclk/2.
CPU Runnung с два раза от этого? Если это так, я не понимаю этих нопс, кроме недостаточной дискретизации.

Есть все еще NOPS, когда он выбирает пиксели с камеры, но не при отправке на дисплей.

Afik, часы к камере обычно составляют 8 МГц (спецификация говорит, что минимум составляет 10 МГц, но я думаю, что каждый использует 8 МГц, как это проще)

Я не уверен, что часы с камеры изменяются в зависимости от частоты кадров. Но код выборки, по -видимому, имеет разные числа, а не зависит от частоты кадров, что, по -видимому, предполагает выходные часы пикселей с камеры могут измениться в зависимости от частоты кадров

Я предполагаю NOPS в коде, который пробует пиксели, есть ли время, когда GPIO читает (от PB8 до PB15), когда данные действительны.

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

Я подумал, что DMA может быть так с использованием внешнего триггера, используя аппаратный таймер, и это было бы лучшим решением и обеспечить большую пропускную способность, а также, вероятно, не нуждается в отключении прерываний все время.

Невозможно изменить оптимизацию в меню инструментов?

[Zoomx - Пн 26 июня 2017 г. 6:29] - Невозможно изменить оптимизацию в меню инструментов?

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

Разве мы не можем просто по умолчанию в -ос ? Как и сейчас, позвольте пользователю затем изменить его, если.
SRP

[ZMEMW16 - Пн 26 июня 2017 г. 10:29] - Разве мы не можем просто по умолчанию в -ос ? Как и сейчас, позвольте пользователю затем изменить его, если.
SRP

Да.

Это можно сделать