turnon 1 2 августа, 2017 Опубликовано 2 августа, 2017 · Жалоба Представленный код инкрементит переменную между ресетами, но есь вопросы по надежности, а именно - не затрется ли переменная. Размещение переменой по заданному адресу означает что под нее будет выделено место в памяти, заданное адресом? Или это просто будет ссылка на заданный адрес - а что там - неизвестно? STM32F2, IAR #include "stm32f2xx.h" static __no_init __root uint32_t flag @0x20000000; int main(void) { flag++; NVIC_SystemReset(); } Вот разница в .map файлах. Слева - с переменной flag, справа - без: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 141 2 августа, 2017 Опубликовано 2 августа, 2017 · Жалоба а именно - не затрется ли переменная. __no_init "У нас принято джентльменам верить на слово" ("Чокнутые"). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 2 августа, 2017 Опубликовано 2 августа, 2017 · Жалоба "У нас принято джентльменам верить на слово" ("Чокнутые"). Джентльменам может и да, а вот компоновщику нужно указывать явно - что и куда грузить и инитить или нет. А у автора - как повезёт прописано в .icf-файле: если на данный адрес не смаппирована ни одна инициализируемая секция - повезло, а иначе - ну тут уж видно не судьба Вобщем - лучше не пользоваться такими конструкциями, а написать: static __no_init __root uint32_t flag @ ".моя_секция"; а уж в .icf прописать куда эту ".моя_секция" компоновать. И там-же - указать, что её не нужно инитить. А то ведь можно даже и переменные __no_init лёгким мановением .icf-файла сделать инициализируемыми PS: И кто сказал что IAR - джентльмен? B) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 2 августа, 2017 Опубликовано 2 августа, 2017 · Жалоба А нам вообще кто-нибудь гарантирует аппаратно, что в RAM точно будут нули после power on??? Тут же всё держится на том, что при сбросе RAM сохранит данные, а при выключении питания - сотрется. А через сколько после выключения питания она вся точно стирается? А не может исчезнуть питание "совсем не на долго", так чтобы в оперативке образовался мусор? ИМХО, ТС встал на скользкую дорожку с этим счётчиком перезапусков.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 2 августа, 2017 Опубликовано 2 августа, 2017 · Жалоба А нам вообще кто-нибудь гарантирует аппаратно, что в RAM точно будут нули после power on??? Естественно после POR там будет мусор. Ну так ведь есть соответствующие регистры в МК, указывающие причину сброса: если там POR - обнуляем переменную и всё. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 3 августа, 2017 Опубликовано 3 августа, 2017 · Жалоба если там POR - обнуляем переменную и всё. Ну, просто в приведенном коде этого нет..... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardEgor 83 3 августа, 2017 Опубликовано 3 августа, 2017 · Жалоба Представленный код инкрементит переменную между ресетами, но есь вопросы по надежности, а именно - не затрется ли переменная. Размещение переменой по заданному адресу означает что под нее будет выделено место в памяти, заданное адресом? Или это просто будет ссылка на заданный адрес - а что там - неизвестно? STM32F2, IAR Я так не экспериментирую, а для таких целей использую регистры Backup RTC_BKP_DR0 и т.д. Если нет батарейки, то делаю питание BKP от конденсатора с диодной развязкой - надолго хватает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 3 августа, 2017 Опубликовано 3 августа, 2017 · Жалоба А у автора - как повезёт прописано в .icf-файле: если на данный адрес не смаппирована ни одна инициализируемая секция - повезло, а иначе - ну тут уж видно не судьба Это где-нибудь в документации написано? Потому что я видел только объяснения "хотите разместить что-нибудь по фиксированному адресу - используйте секции или синтаксис @адрес ". И, с моей точки зрения, второй способ удобнее - всё в одном месте, не размазано по исходнику и скрипту линкера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 3 августа, 2017 Опубликовано 3 августа, 2017 · Жалоба Всё описано в документации к линкеру. Не думаю, что хардкодить адреса используя @адрес - это хорошая идея! Используйте секции, они размещаются линкером в указанном порядке, линкер может экспортировать символы с адресами начала и конце секций если это где-нибудь нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 3 августа, 2017 Опубликовано 3 августа, 2017 · Жалоба Это где-нибудь в документации написано? Что именно описано? У автора в коде написано, что он помещает переменную по адресу 0x20000000. А что находится по этому адресу - известно только .icf файлу. Там может быть что-то, а может и не быть. Вот именно удобно когда всё размещение в памяти описано в одном месте. У IAR это место - .icf-файл. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gerber 8 3 августа, 2017 Опубликовано 3 августа, 2017 · Жалоба Что именно описано? У автора в коде написано, что он помещает переменную по адресу 0x20000000. А что находится по этому адресу - известно только .icf файлу. Там может быть что-то, а может и не быть. Нет. Если есть прямая директива разместить переменную по фиксированному адресу, то линкер её там и разместит, все остальные переменные лягут по другим адресам, никакого "затирания" не произойдет. В противном случае смысл в этой директиве напрочь отпадает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 3 августа, 2017 Опубликовано 3 августа, 2017 · Жалоба Отлично. Берём другого автора. https://www.iar.com/support/tech-notes/comp...ecific-address/ Они делают то же самое, и не говорят, что между двумя способами указания адреса есть какая-то разница. А что находится по этому адресу - известно только .icf файлу. Там может быть что-то, а может и не быть. А вот это неправда. Что находится по этому адресу, известно линкеру. Один из способов сообщить это линкеру - icf-скрипт. Другой - прагмы и IAR'овские расширения языка си непосредственно в исходнике. Более того, достаточно прочитать первое сообщение темы - там отчётливо видно, как этот флажок расположен именно в том месте, какое и подразумевалось при объявлении. И что стек автоматически смещается, тоже видно. Т.е. линкер эту область видит. Ставим галочку. Что будет, если линкер не сможет растолкать bss (zero-init), data (non-zero-init), стек и эти секции в области памяти - надо проверять. Но в то, что без каких-то ошибок они перекроют друг друга, я не верю. И аргументов от Вас никаких не услышал. Вот именно удобно когда всё размещение в памяти описано в одном месте. У IAR это место - .icf-файл. Чувства верующих я, пожалуй, обсуждать не буду. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 4 августа, 2017 Опубликовано 4 августа, 2017 · Жалоба Нет. Если есть прямая директива разместить переменную по фиксированному адресу, то линкер её там и разместит, все остальные переменные лягут по другим адресам, никакого "затирания" не произойдет. В противном случае смысл в этой директиве напрочь отпадает. Ну хорошо, коли так :rolleyes: IAR может и проверяет, но вот другие компиляторы? В теме у автора из раздела форума "ARM" как раз подобное и приключилось - перекрылись две секции памяти, видимо описанные в разных местах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
turnon 1 5 августа, 2017 Опубликовано 5 августа, 2017 · Жалоба Если нет батарейки, то делаю питание BKP от конденсатора с диодной развязкой - надолго хватает. Потребление RTC - 5 uA. Если питание пропадет на сутки, чтобы RTC не сбросился (снижение напряжение с 3.3 до 2.3В) понадобится конденсатор 432000 uF (!). Конденсатор мелкие тоже ставлю, но исключительно чтобы не было сброса при заменен батарейки или при дребезге контактов в держателе батарейки. А вот это неправда. Что находится по этому адресу, известно линкеру. Один из способов сообщить это линкеру - icf-скрипт. Другой - прагмы и IAR'овские расширения языка си непосредственно в исходнике. Более того, достаточно прочитать первое сообщение темы - там отчётливо видно, как этот флажок расположен именно в том месте, какое и подразумевалось при объявлении. И что стек автоматически смещается, тоже видно. Т.е. линкер эту область видит. Ставим галочку. Значит таки выделяется место под переменную и не надо ничего прописывать в .icf файле. Это обнадеживает. Что будет, если линкер не сможет растолкать bss (zero-init), data (non-zero-init), стек и эти секции в области памяти - надо проверять. Вот тут не понял, расшифруйте пожалуйста для чайника. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 5 августа, 2017 Опубликовано 5 августа, 2017 · Жалоба Потребление RTC - 5 uA. Если питание пропадет на сутки, чтобы RTC не сбросился (снижение напряжение с 3.3 до 2.3В) понадобится конденсатор 432000 uF (!). Конденсатор мелкие тоже ставлю, но исключительно чтобы не было сброса при заменен батарейки или при дребезге контактов в держателе батарейки. А зачем нужно это инкрементирование переменной? Возможно есть решения получше, которые Вы не замечаете. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться