Добрый вечер всем участникам, возник такой вопрос: при включении контроллера, происходит сброс ram "железно" во всех регистрах в 00 или у вас бывали случаи, что в ram висит мусор? Просто есть подозрения, что есть мусор в ram при включении...
Буду рад Вас услышать.

мусор

Пардон, а зачем тов. Klassik понадобилось искать чего в RAM после включения МК?
Ведь (из знаний того, что есть в МК и что для чего предназначено) явно следует как использовать RAM.
Правда, если вместо осмысления даташита искать: а что там за пределами адресного пространства, чего в ячейке, в которую я ничего не клал или будет ли работать МК без подачи питания и т. д., то "исследования" можно продолжать.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Предположим, что вы работаете с 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-ов нужно глядеть в их [регистров] личных делах.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Просто у меня в программе используются битовые флаги и через некоторое время программа зависает, пишу на ассемблере и не полный нуб в программировании. Регистры в ram используются как 8 битовые флаги. И если значение в ram будет фиг знает что, значит программа улетит не туда куда надо. Наверное самое оптимальное будет при запуске мк чистить ram через косвенную адресацию, это так, мысли вслух....

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Ну если ты туда пишешь что-то перед прочтением, то какая разница что там было ДО?

Лично я, давным-давно взял за правило, при старте программы, полностью очищать "оперативку".
И самому спокойнее и, один фиг, всё равно время девать некуда, поскольку приходится ещё ждать до начала инициализации разной периферии, подключенной к контроллеру.
А, образно говоря, включите вы светодиод через 1µS или 1mS после подачи питания - никто не заметит...

Это правило программирования: объявил переменную - инициализируй!

Я так понял, что пока там что-то "инициализируется" идёт чистка ram. Но если идёт эта чистка, то ничего собственно происходить больше и не может. Так что же подразумевается под словами "приходится ждать"?

Кстати, я как-то проводил эксперимент. Не очищая оперативу, сразу выводил текущие значения нескольких байтов поразрядно в зуммер. В итоге всегда показывало FF.

Я о том что, к примеру, если у вас в системе индикатор на HD44780, SI4xxx, CMX7xxx и т.д., вы не имеете право делать их INIT сразу (мгновенно) после подачи питания.
Для каждого из них (в pdf) указано минимальное время между подачей питания и начала работы с ними.
Как правило, это время более 100mS и только по истечении этого времени можно приступать к их инициализации.
До истечении этого времени можно делать что угодно, но изделие не будет полностью рабочим.
За это время можно очистить память, настроить внутреннюю периферию контроллера и т.д..
В программе я делаю отдельным битом (в битовом регистре) указание на то, что вся периферия проинициализирована и разрешается выполнение основного алгоритма работы программы.

В настройках ассемблера есть опция инициализации корректно объявленных переменных нулем. При ее активации ассемблер сдвигает код пользователя и вставляет оную инициализацию. Не знаю есть ли эта опция у MPASM, а у ASM30/ASM16 имеется. Причем в MPLAB X она по дефолту включена.

Для ассемблера стандартна процедура предварительной очистки/загрузки критичных значений для ОЗУ.
Одновременно должна быть предусмотрена корректная переинициализация системы при условии возникновения аварийных сбоев (не обязательно при соответствующем сигнале аппаратного сброса).