Находим адрес любой инструкции в цикле функции main средствами IDE и активируем точку останова:
FP->FP_COMP[0] = 0x080017CC | 1; // адрес середины бесконечного цикла = 0x080017CC
И так при каждой компиляции программы узнавать через отладку адреса всех нужных точек остановки? Не проще ли breakpoint поставить? Ну или можно как-то «автоматизировать» выдергивание адресов нужных инструкций?
P.S. DebugMon на самом деле идеально не для инструкций использовать, а для переменных, чьи адреса всегда известны. Жду продолжения.
Регистров USART_DR физически 2. Доступ к одному из них осуществляется исключительно чтением по адресу USAR_DR, доступ к другому исключительно записью. В вашей же цитате из даташита:
The Data register performs a double function (read and write) since it is composed of two registers, one for transmission (TDR) and one for reception (RDR)
Это же не статья с названием «Причины внедрить в процесс разработки статический анализатор кода?». Названа как «Причины внедрить в процесс разработки статический анализатор кода PVS-Studio?»
Так где же сравниние с другими статическими анализаторами?
при попытке компиляции «Hello World» проекта под Cygwin. В чем может быть причина?
P.S. Windows 10 x64, Build 1903. Cygwin установлен как из статьи, STM32CubeIDE 1.0.2. Переменные среды окружения PATH и classpath настроены как указано в статье.
это тип данных указатель на контантное число типа int (а значит не известо, ссылается ли указаль все на тот же участок памяти, особенно в embedded такое критично):
const int * x
это указатель, который низачто не изменит адрес, на который ссылается, но вот данные могут меняться:
int * const x
ну и как написали выше, это уже указатель, который гарантированно не изменит свой адрес и ссылается на НЕизменяемые данные:
Нк раз такой велосипед изобрелся, то спрошу: не проще ли будет использовать 2+ SPI на максимальной скорости (один для первой половины, второй для второй половины данных)? Пинов отнимите в идеале 6 и еще прием организовать сможете.
Не надо привязываться в компании из статьи. Причин может быть много: побаловаться, заглушить линк (конкуренция, ограбление..). Ответ на «Зачем?» зависит от того, кем используются такие модемы.
Вход и выход из прерывания занимает 12+12 тиков минимум. STMDB и LDMIA из предыдущей статьи минимум (зависит дальше от прерываний) займут 9+9 тиков. Итого уже 42 тактка съедено… Я сильно сомневаюсь что остальной код выполнится за 8 тактов…
Что имеет смысл дампить, зависит от причины, которую (еще раз повторюсь) можно определить. Я перечислял возможности, а не указал последовательный список действий.
К чему этот комментарий? Я знаю о существовании MPU, в статье же указаны микроконтроллеры без него, и даже без него есть варианты того, что можно сделать.
И так при каждой компиляции программы узнавать через отладку адреса всех нужных точек остановки? Не проще ли breakpoint поставить? Ну или можно как-то «автоматизировать» выдергивание адресов нужных инструкций?
P.S. DebugMon на самом деле идеально не для инструкций использовать, а для переменных, чьи адреса всегда известны. Жду продолжения.
Так где же сравниние с другими статическими анализаторами?
1) В шелле Cygwin'a скомпилировал main.c командой gcc -o hello_world main.c и содержанием:
2) Удалил и заново создал обычный «Hello World» по инструкции из статьи
3) И оно скомпилировалось…
P.S. Windows 10 x64, Build 1903. Cygwin установлен как из статьи, STM32CubeIDE 1.0.2. Переменные среды окружения PATH и classpath настроены как указано в статье.
это указатель, который низачто не изменит адрес, на который ссылается, но вот данные могут меняться:
ну и как написали выше, это уже указатель, который гарантированно не изменит свой адрес и ссылается на НЕизменяемые данные:
И что, кроме незнания, мешает написать так
?