caxapa.ru :: "запись в буфер сама затирает важные данные в ОЗУ" - с этого момента поподробнее. Что эта фраза означает? Потому что противоречие: запись в буфер, но не в буфер, а в "важные данные в ОЗУ".

SciFi (17.01.2020 19:36, просмотров: 180) ответил Nikolay_Po на [РЕШЕНО] GNU Tools for STM32 7-2018-q2-update (и вообще любой arm-none-eabi). Не могу добиться появления глобальных массивов в *.map

"запись в буфер сама затирает важные данные в ОЗУ" - с этого момента поподробнее. Что эта фраза означает? Потому что противоречие: запись в буфер, но не в буфер, а в "важные данные в ОЗУ".

ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้

Ответить

- Код файла custom_adc.c, из прерывания записывает в буфер новые данные. С точки зрения работы функции прерывания АЦП - всё нормально. Nikolay_Po(1597 знак., 17.01.2020 19:48)
  - Ерунда какая-то. Танец с бубном. "по логике, оказывался в стеке" - странные фантазии. Короче, хз, что происходит, в вводных данных никакого криминала не видно. - SciFi(17.01.2020 19:56)
    - Хорошо, перефразирую: Обращение к массиву из кода Си приводит к работе к области, где размещается стек, разрушая полезное содержимое стека. Nikolay_Po(436 знак., 17.01.2020 20:04)
      - Откуда сведения, что ОЗУ достаточно? Может быть, стек налазит на bss в любом случае. Например, засунули массив в именованную секцию, она оказалась в более младших адресах, и стек наезжает на другие переменные, которые завалят программу чуть позже. - SciFi(17.01.2020 20:11)
        
        Блин, могу ли я рассчитывать на ошибку от линкера в таком случае? У меня ни малейших сомнений, что XC16 Микрочипа такое отловил и не дал бы выстрелить в ногу. Nikolay_Po(216 знак., 17.01.2020 20:15)
        
        Стек надо проверять самостоятельно. Например, заполнить его какой-нибудь ерундой типа 0xDEADBEEF на старте, а через некоторое время проверять хотя бы просмотром памяти в отладчике. - SciFi(17.01.2020 20:18)
        
        Ерунда какая-то. Похоже, меня Microchip XC16 избаловал. Не могу поверить просто, что программисту Си: "Стек надо проверять самостоятельно". Nikolay_Po(227 знак., 17.01.2020 20:23)
        
        Пока найден баг в программе. Вернее, найден факт его наличия. Вроде бы gcc что-то умеет в части вычисления использования стека. Но в типичной программе много непредсказуемого. Те же обработчики прерываний - их хвалёный мелкочип учитывает? Им же SciFi(17 знак., 17.01.2020 20:35)
        
        Конечно Microchip XC16 учитывает, в том числе и обработчики прерываний. Предположение, что GCC не учитывает глубину стека для прерываний, по мне, такая же дикость. Nikolay_Po(644 знак., 17.01.2020 20:51)
        
        Я не в курсе, XC16 - это пики же? Там, наверное, в процессоре есть регистр, который отлавливает переполнение стека? Ну так в кортексе этого нет, и звените. И почему вы решили, что "глобальная волатильная переменная размещается? GCC в стеке? (не в SciFi(253 знак., 17.01.2020 21:02)
        
        Да, пики. Есть. Но он не срабатывает! Компилятор до этого не доводит. Не думал, что всё ТАК запущено у GCC-водов. Nikolay_Po(63 знак., 17.01.2020 21:14)
        
        Ушло куда-то в сторону. Не факт, что у вас стек переполняется. Это было предположение, в итоге получилось бурление не совсем в тему :-) - SciFi(17.01.2020 21:26)
        
        Не, ну с индексами, с указателями можно было с XC16 накосячить. Nikolay_Po(127 знак., 17.01.2020 22:54)
        
        что характерно, контроллировать единственный байт нельзя, ибо он может попасть на не используемую в этой ветке кода переменную - lloyd(17.01.2020 20:20)

ARM, RISC-V контроллеры