Добрый вечер всем участникам, возник такой вопрос: при включении контроллера, происходит сброс ram "железно" во всех регистрах в 00 или у вас бывали случаи, что в ram висит мусор? Просто есть подозрения, что есть мусор в ram при включении...
Буду рад Вас услышать.
Пардон, а зачем тов. Klassik понадобилось искать чего в RAM после включения МК?
Ведь (из знаний того, что есть в МК и что для чего предназначено) явно следует как использовать RAM.
Правда, если вместо осмысления даташита искать: а что там за пределами адресного пространства, чего в ячейке, в которую я ничего не клал или будет ли работать МК без подачи питания и т. д., то "исследования" можно продолжать.
[uquote="Klassik",url="/forum/viewtopic.php?p=3218481#p3218481"]происходит сброс ram "железно" во всех регистрах в 00 или у вас бывали случаи, что в ram висит мусор?[/uquote]
Предположим, что вы работаете с PIC18F14K50 и имеете ввиду его набортный SRAM - тогда заглянув в даташит http://ww1.microchip.com/downloads/en/D ... 01350F.pdf и дочитав до раздела "3.3 Data Memory Organization" можно заметить, что область эта называется GPR и как написано в разделе
3.3.4 GENERAL PURPOSE REGISTER FILE
PIC18 devices may have banked memory in the GPR
area. This is data RAM, which is available for use by all
instructions. GPRs start at the bottom of Bank 0
(address 000h) and grow upwards towards the bottom of
the SFR area. GPRs are not initialized by a Power-on
Reset and are unchanged on all other Resets.
Но если вы пишете на С то до момента вызова вашей реализации main() все глобальные инициализированные переменные уже будут иметь заданные в исходном коде значения, а неинициализированные глобальные переменные - будут занулены. Пространство стека, впрочем, остаётся непроинициализированным - т.е. локальные переменные всё-же будут иметь неопределённые значения - но у них судьба такая. Если-же наш сферический С-ишник додумается организовать кучу и будет выкалывать из неё кусочки malloc-ом - в них тоже будет мусор. Ну а для ассемблерщика, как уже ответили, всё проще - 100% мусора исключая область занятую SFR. А правила инициализации SFR-ов нужно глядеть в их [регистров] личных делах.
Одновременным нажатием LIGHT и POWER, РП Sangean ATS-909X (ver 1.29) превращается в ATS-909XR!
Просто у меня в программе используются битовые флаги и через некоторое время программа зависает, пишу на ассемблере и не полный нуб в программировании. Регистры в ram используются как 8 битовые флаги. И если значение в ram будет фиг знает что, значит программа улетит не туда куда надо. Наверное самое оптимальное будет при запуске мк чистить ram через косвенную адресацию, это так, мысли вслух....
Лично я, давным-давно взял за правило, при старте программы, полностью очищать "оперативку".
И самому спокойнее и, один фиг, всё равно время девать некуда, поскольку приходится ещё ждать до начала инициализации разной периферии, подключенной к контроллеру.
А, образно говоря, включите вы светодиод через 1µS или 1mS после подачи питания - никто не заметит...
[uquote="Klassik",url="/forum/viewtopic.php?p=3218670#p3218670"]Наверное самое оптимальное будет при запуске мк чистить ram через косвенную адресацию, это так, мысли вслух....[/uquote]
Это правило программирования: объявил переменную - инициализируй!
[uquote="Albert_V",url="/forum/viewtopic.php?p=3218776#p3218776"]... всё равно время девать некуда, поскольку приходится ещё ждать до начала инициализации разной периферии, подключенной к контроллеру...[/uquote]
Я так понял, что пока там что-то "инициализируется" идёт чистка ram. Но если идёт эта чистка, то ничего собственно происходить больше и не может. Так что же подразумевается под словами "приходится ждать"?
Кстати, я как-то проводил эксперимент. Не очищая оперативу, сразу выводил текущие значения нескольких байтов поразрядно в зуммер. В итоге всегда показывало FF.
Я о том что, к примеру, если у вас в системе индикатор на HD44780, SI4xxx, CMX7xxx и т.д., вы не имеете право делать их INIT сразу (мгновенно) после подачи питания.
Для каждого из них (в pdf) указано минимальное время между подачей питания и начала работы с ними.
Как правило, это время более 100mS и только по истечении этого времени можно приступать к их инициализации.
До истечении этого времени можно делать что угодно, но изделие не будет полностью рабочим.
За это время можно очистить память, настроить внутреннюю периферию контроллера и т.д..
В программе я делаю отдельным битом (в битовом регистре) указание на то, что вся периферия проинициализирована и разрешается выполнение основного алгоритма работы программы.
В настройках ассемблера есть опция инициализации корректно объявленных переменных нулем. При ее активации ассемблер сдвигает код пользователя и вставляет оную инициализацию. Не знаю есть ли эта опция у MPASM, а у ASM30/ASM16 имеется. Причем в MPLAB X она по дефолту включена.
[uquote="Klassik",url="/forum/viewtopic.php?p=3218670#p3218670"]Просто у меня в программе используются битовые флаги и через некоторое время программа зависает, пишу на ассемблере и не полный нуб в программировании. Регистры в ram используются как 8 битовые флаги. И если значение в ram будет фиг знает что, значит программа улетит не туда куда надо. Наверное самое оптимальное будет при запуске мк чистить ram через косвенную адресацию, это так, мысли вслух....[/uquote]
Для ассемблера стандартна процедура предварительной очистки/загрузки критичных значений для ОЗУ.
Одновременно должна быть предусмотрена корректная переинициализация системы при условии возникновения аварийных сбоев (не обязательно при соответствующем сигнале аппаратного сброса).
