Jump to content

    

jcxz

Свой
  • Content Count

    7704
  • Joined

  • Last visited

Everything posted by jcxz


  1. А не пробовали сравнить -o1 и -o3? При -o1 уже есть минимальная оптимизация. В том фрагменте .lst что я приводил, в разделе "stack usage" указаны размеры стека занимаемого только самой функцией, а не всем деревом её вызова. Всё дерево я не знаю - умеет ли IAR считать. Поэтому там легко сравнить функции в разных вариантах компиляции. IAR вам поставить нельзя?
  2. Питается от отладочного. Если судить по схеме - от micro-USB питаться не должен.
  3. Готовой прошивки? Как через ST-Link - не знаю, знаю как J-Link-ом готовую залить.
  4. Создаёте проект в IAR. Указываете в нём какой МК и указываете ST-Link. И всё - по идее должно прошиваться.
  5. Там с одной стороны есть USB-разъём с отдельным маленьким МК (вроде STM32F1xx). Вот в него втыкаетесь. Появится ST-Link. Также рядом там надо правильно установить джамперы (подписаны ST-Link), вроде замкнуть там надо два из них попарно (но лучше проверить по мануалу - я им не пользуюсь - использую внешний J-Link). И можете прошивать и отлаживать. Можно этот ST-Link перешить в J-Link. Ну нифига себе у Вас силища!! Хрупкой девушки... Да, там сенсорный экран. Работает нормально. Только он - резистивный. Но мой работает давно и не трескается. Поцарапался только весь. Мож он с дефектом был? Я думаю - на али можно подобрать подобный и заменить. Нужен 320x240 на ILI9341. Я ставил IAR_7.80.4. не помню уж - предлагал он мне обновиться или нет. Куба не пользую. А потом я вообще его перешил в J-Link.
  6. И какая разница что там другие вызовы? У вас и в release и в debug - есть вызовы. И вы думаете что в случае release у вас будут вызываться одни функции, а в случае debug - другие? И что будет чёткая зависимость - в случае debug всегда будут вызываться функции с бОльшим стеком? Только в этом случае суммарное использование стека получится больше. Или всё-таки вызов любой функции (из тех что могут вызываться косвенно) равновероятен что в debug что в release? Причём тут "статическое дерево вызовов"? Вы это сами придумали, приписали это мне, и теперь пытаетесь со мной спорить. Я не говорил ни о каком "статическом дереве". Бодаетесь пока что Вы сами с собой. С приписанными мне утверждениями.
  7. Каким образом? Каким образом у Вас в runtime могут меняться команды, из которых состоит функция??? Какая разница где находится указатель на функцию? Если она всё равно вызывается. Вызывается и в debug и в release. А расход стека разве состоит не из расхода отдельно взятых функций? Т.е. - не максимального расхода по самой глубокой ветке? Эти замеры (реального времени) - не объективны. Потому что если есть какие-то ветвления, и по разным путям этих ветвлений вызываются разные функции, то будет разница в использовании стека. И чтобы получить максимальный раход - нужно заставить пройтись по всем путям. В ваших измерениях нет никакой достоверной гарантии что это выполнено. PS: Хотя конечно если у Вас даже количество PUSH-ей в функциях меняется в зависимости от того как они вызываются , тогда да - нет больше вопросов.
  8. В листинге показан максимальный размер стека используемый функцией. Какая разница как она будет вызываться - косвенно или нет? Количество регистров в PUSH от этого не изменится. И какая разница эта функция - делегат или что-то ещё? Для компилятора это обычная функция, на входе в которую стек занимается на выходе - освобождается. Так что сравнивать 2 одинаковые функции скомпилённые с разными ключами - это и есть правильно. А в реалтайм вы смотрите какую-то среднюю температуру по больнице: сейчас она столько, а если временнЫе параметры каких-то событий обрабатываемых ПО чуть сдвинутся - будет уже другая. Вы думаете от этого изменится количество регистров в PUSH/POP? Но если почему-то больше доверяете реал-тайм измерениям, вот мои: debug: release: Во втором синем столбце использовано/свободно стека (32-битных слов) в разных задачах РТОС. Как нетрудно заметить - в среднем release требует больше стека. "exceptions" - стек исключений, тоже под release больше запачкан.
  9. Вы смотрите не там где надо. Смотреть нужно листинги. Взял один из своих проектов, debug -o1: release -o3: Конечно я выбрал участки с наибольшими различиями, но всё же....
  10. А куб для NXP - Вы поможете портировать?
  11. То что с оптимизацией стека должно требоваться больше. По логике.
  12. Ну как, вот например - есть статические переменные i1, i2 (в ОЗУ); работаем с i1: LDR R0, =i1 ;грузим адрес i1 в R0 LDR R1, [R0] ;грузим i1 в R1 ;здесь используем загруженное значение i1 ;далее - работаем с i2: LDR R0, =i2 ;грузим адрес i2 в R0 LDR R1, [R0] ;грузим i2 в R1 ;далее - опять нужно работать с i1 Так вот - код без оптимизации опять загрузит её адрес (так как не сохранил адрес от предыдущего использования): LDR R0, =i1 ;грузим адрес i1 в R0 а код с оптимизацией может сохранить адрес от предыдущей загрузки. Но тогда в общем случае - будет нужно больше регистров. а значит - больше регистров необходимо сохранить на входе в функцию. Также например - если у вас есть выражение скажем: ((i1 & 127)*7+122) где-то в начале функции, и в конце. И между ними i1 не меняется. Без оптимизации компилятор дважды его вычислит, а с оптимизацией - вычислит раз, сохранит во временной переменной и в конце функции использует снова (оптимизация по скорости или балансная). На это опять нужен доп.регистр или стек. А значит опять - с оптимизацией стека потребуется больше. PS: А насчёт ваших примеров - попробуйте максимальную оптимизацию - под IAR увеличение расхода стека происходит при переходе с -o1 на -o2 или -o3.
  13. Напрасно. Периферия тактируется не от ядра, а от одной из шин: AHB/APB1/APB2. Код программирования частотозадающего узла он все эти частоты выставляет. Они все должны быть в допустимых для них пределах. А тогда никаких недопустимых частот на узлах периферии не будет. А дальше - если какие-то частоты нужны внутри этой периферии, то они порождаются её делителями (которые рассчитываются на основе частоты соответствующей шины). У меня всё это делается. SDRAM сидит на AHB. И для неё допустимы только два делителя 2 и 3. Для того чипа, который стоит на плате, можно использовать любой из них, ибо даже на максимуме: 180/2=90МГц - вполне допустима. Это индусов нужно спрашивать почему там 72МГц. У меня всё работает стабильно на 160МГц уже очень долго. Больше просто не нужно.
  14. В этом проекте использую только одну - STM32F429I-DISCO.
  15. Вы про что? Про USB? На этой плате кварц стоит == 8МГц, а не 6.
  16. Так я все их использовал. Всю таблицу. Я отлаживал свою процедуру инита PLL и для отладки ставил разные значения желаемой частоты. И проверял работу. Так и получилась эта таблица. Ничего не удалял из неё. И потом позже я иногда переключал свой код то на одну, то на другую из этих частот. Я уже несколько раз сказал (и Viko тоже) что использовал все эти частоты. Они все рабочие с этой платой. Можете брать любую, какая нравится. Единственное что не использовал на этой плате - USB. Так что вычисления касающиеся USB - только аналитические, без проверки.
  17. Считаем: 180*2/48=7.5 - число нецелое, значит невозможно.
  18. Так опять будет на границе! Только на другой Можно конечно было поделить на 6, а потом N=252, но неохота было тянуть нецелые значения. Да и - какая разница? В диапазоне же!
  19. И как получить в середине из 8 МГц? Да и - ЗАЧЕМ? Оно же внутри диапазона, а не вне.
  20. ну и что что на краю? А какую другую частоту Вы там предложите?
  21. Длина имени указателя IAR AVR

    Гадать на кофейной гуще можно сколько угодно. Приведите конкретный пример кода.
  22. Если найдёте в диапазоне VCO: PLL_VCO_CLK >= 100000000 && PLL_VCO_CLK <= 432000000 такую частоту, из которой можно получить и 180МГц и 48МГц с помощью целых делителей - тогда можно. Но если посмотреть на мою таблицу из https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=155095&page=4&tab=comments#comment-1669656 то можно предположить, что такой частоты нет. Ну я и не говорил, что там все допустимые варианты. Там только те, которые я пробовал когда тестил свой код инита PLL. Ну и которые после добавлял. Надо будет - добавлю ещё, но думаю не понадобится ибо там и так значения идут с достаточно мелким шагом.
  23. Извините меня конечно, но видимо Вы - робот. Ибо - "людям свойственно ошибаться". Самым глупым образом. Но вы - не ошибаетесь ведь...
  24. Теперь откройте наконец и прочитайте моё сообщение: https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=155095&page=4&tab=comments#comment-1669656 и увидите в строчке #define PLLKIT_8000000_168M все эти значения. Опять же - RTFM. Это не частота ядра, а частота VCO. И она вполне себе "в пределах", так как для этого МК должна быть: PLL_VCO_CLK >= 100000000 && PLL_VCO_CLK <= 432000000 Если бы Вы читали данные Вам ответы, Вы бы уже давно увидели это решение.