Перейти к содержанию

    

jcxz

Свой
  • Публикаций

    5 628
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о jcxz

  • Звание
    Гуру
  • День рождения 01.12.1974

Контакты

  • ICQ
    311337544

Информация

  • Город
    Омск

Посетители профиля

13 730 просмотров профиля
  1. Отсюда вывод: мой код лучше чем у компилятора. Компилятор, когда компилит, тоже её может менять. И что с того?
  2. Так приведите си-исходник, который будет компилироваться в такой код (который будет 64-битными словами и т.п.). Я привёл не 2 совершенно разные программы, а взял результат компиляции одной программы и его оптимизировал на асме. Я вообще-то говорю не об неэффективности компилятора, а показываю что он неидеален, и что код ТС-а скорей всего также возможно вручную оптимизировать лучше компилятора.
  3. Сказать что и как? LDM IAR например никогда не использует, даже для u32 *.
  4. В чём именно "не по теме"? Сколько готовы заплатить?
  5. "Весьма неплохо" - это на взгляд тех, кто не хочет напрягать свой мозг и изучать ассемблер. Когда освоите ассемблер в достаточной степени, увидите сколько там возможностей для улучшений. Потому что всё-таки люди обычно умнее компиляторов, иначе не люди писали бы компиляторы, а компиляторы - программировали голову. Ну это конечно касается только тех, кто эту самую голову использует по назначению. Конечно и ковыряние и оптимизация на уровне алгоритма - тоже необходима, нужно действовать в комплексе. Вот, для примера как-то у меня была задача - написал я функцию: Скомпилилась она (максимальная оптимизация по скорости или балансная) в: Скажете - "весьма неплохо"? А по мне - как-то не очень. И я, зная что (cnt == 0 || cnt > 4) и что входные данные (*src) - 14-битные (0...0x3FFF) и выровнены на 32бита, оптимизировал её так: Как видно - разница очень даже заметная.
  6. Cosmic IdeaSTM8 и тип INT

    for (uint8_t i = 0; i < 10; i++) {...} 10 - по дефолту тип int, i - uint8_t (меньшего размера). Соответственно один операнд (меньшего размера) будет приведён к типу другого (большего размера и другой разрядности). См. описание языка си, раздел правил приведения типов операндов внутри выражений. Значит - данный компилятор в данном конкретном случае (с данными ключами) данный конкретный пример уже оптимизирует, приводя сразу типы операндов. Вот что сказал IAR_7.80.4 for ARM (оптимизация - LOW): Команда UXTB - это как раз и есть команда беззнакового расширения. Без которой можно обойтись, применив uint i. Как справедливо заметил VladislavS приведения типа чаще можно увидеть при передаче аргументов функций не основной разрядности (разрядность != разрядности регистров CPU). Возьмите любой код, насыщенный всякими uint8_t/uint16_t в аргументах и локальных переменных функций, скомпилируйте его на 32-битной архитектуре, и увидите кучу UXTB/UXTH/SXTB/SXTH. Например этим сильно грешат исходники uCOS-II - всяких INT8U/INT16U в аргументах там полно. То же самое касается и других архитектур (STM8 - в том числе), когда передаются аргументы в функцию или используются как локальные, переменные не основной разрядности. В STM8 предпочтительно использовать 8бит, если не лезет - 16бит, и только потом уже - 32бита.
  7. Cosmic IdeaSTM8 и тип INT

    Дополнительными командами приведения типа.
  8. Tracealyzer для FreeRTOS

    гуглите "браузер tor"
  9. Странный HARDFAULT

    Не только по стекам процессов, но и стек прерываний следует проверить. Как видно из содержимого регистров - Вы используете раздельные стеки для MSP и PSP. Его кстати ОС думаю не контролирует. PS: В инфу, выдаваемую Вашим обработчиком HF, советую добавить инфу о состоянии PSP и MSP и содержимое верхушки активного стека. PPS: В первую очередь я бы также советовал добиться стабильного проявления бага, а не раз в час. Для этого можно попробовать: включить оптимизацию по максимуму, или поменять ещё установки; поменять частоту CPU (при возможности); добавить дополнительные задачи, со случайной вычислительной загрузкой, ... Когда добьётесь стабильного проявления бага, это состояние стоит зафиксировать и в нём будет уже легче искать баг.
  10. Странный HARDFAULT

    Всё-таки я бы протрассировал внутрь, чтобы убедиться что там именно те самые команды.
  11. Tracealyzer для FreeRTOS

    tor + анонимайзеры в РФ больше не работают?
  12. Странный HARDFAULT

    А всё-таки - ответьте на последний вопрос из https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=149961&do=findComment&comment=1598511 Ведь Ваш fault имеет PC=0x080D6626, а там portSET_INTERRUPT_MASK_FROM_ISR() Или просто протрассируйте внутрь по шагам, по ассемблерному коду.
  13. Странный HARDFAULT

    При переполнении стека может быть что угодно, в том числе и ваша ситуация. Программный контроль стека помогает не всегда.
  14. На чем писать

    Ага, ещё и ногодрыгом. Вообще веселуха!
  15. Странный HARDFAULT

    Понятно. Сам так не делаю, так как у меня WFE только в одном месте - в отдельной Idle-задаче. Которая кроме выполнения в цикле WFE больше собственно ничего не делает. А переход в эту задачу - через переключатель контекста. Такую Idle-задачу использую во всех проектах, в том числе и на STM32. Проблем нигде нет. Тоже - не делаю так. Т.е. - не строю код так, чтобы была зависимость от задержек входа в ISR. PS: Проблемы ТС думаю не из-за этого. Так как в первом случае - у него были бы проблемы с работой периферии, а не HF; а во втором - с входами в ISR, а не HF. PPS: В исходном посте мне не понятна последняя строка: portCLEAR_INTERRUPT_MASK() - что это? и зачем? А также: как задана и чему равна portSET_INTERRUPT_MASK_FROM_ISR() ? Случайно не: #ifndef portSET_INTERRUPT_MASK_FROM_ISR #define portSET_INTERRUPT_MASK_FROM_ISR() 0 #endif