Добрый вечер всем участникам, возник такой вопрос: при включении контроллера, происходит сброс ram "железно" во всех регистрах в 00 или у вас бывали случаи, что в ram висит мусор? Просто есть подозрения, что есть мусор в ram при включении... Буду рад Вас услышать.
Пардон, а зачем тов. Klassik понадобилось искать чего в RAM после включения МК? Ведь (из знаний того, что есть в МК и что для чего предназначено) явно следует как использовать RAM. Правда, если вместо осмысления даташита искать: а что там за пределами адресного пространства, чего в ячейке, в которую я ничего не клал или будет ли работать МК без подачи питания и т. д., то "исследования" можно продолжать.
происходит сброс ram "железно" во всех регистрах в 00 или у вас бывали случаи, что в ram висит мусор?
Предположим, что вы работаете с 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!
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Просто у меня в программе используются битовые флаги и через некоторое время программа зависает, пишу на ассемблере и не полный нуб в программировании. Регистры в ram используются как 8 битовые флаги. И если значение в ram будет фиг знает что, значит программа улетит не туда куда надо. Наверное самое оптимальное будет при запуске мк чистить ram через косвенную адресацию, это так, мысли вслух....
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Лично я, давным-давно взял за правило, при старте программы, полностью очищать "оперативку". И самому спокойнее и, один фиг, всё равно время девать некуда, поскольку приходится ещё ждать до начала инициализации разной периферии, подключенной к контроллеру. А, образно говоря, включите вы светодиод через 1µS или 1mS после подачи питания - никто не заметит...
... всё равно время девать некуда, поскольку приходится ещё ждать до начала инициализации разной периферии, подключенной к контроллеру...
Я так понял, что пока там что-то "инициализируется" идёт чистка ram. Но если идёт эта чистка, то ничего собственно происходить больше и не может. Так что же подразумевается под словами "приходится ждать"?
Кстати, я как-то проводил эксперимент. Не очищая оперативу, сразу выводил текущие значения нескольких байтов поразрядно в зуммер. В итоге всегда показывало FF.
Я о том что, к примеру, если у вас в системе индикатор на HD44780, SI4xxx, CMX7xxx и т.д., вы не имеете право делать их INIT сразу (мгновенно) после подачи питания. Для каждого из них (в pdf) указано минимальное время между подачей питания и начала работы с ними. Как правило, это время более 100mS и только по истечении этого времени можно приступать к их инициализации. До истечении этого времени можно делать что угодно, но изделие не будет полностью рабочим. За это время можно очистить память, настроить внутреннюю периферию контроллера и т.д.. В программе я делаю отдельным битом (в битовом регистре) указание на то, что вся периферия проинициализирована и разрешается выполнение основного алгоритма работы программы.
В настройках ассемблера есть опция инициализации корректно объявленных переменных нулем. При ее активации ассемблер сдвигает код пользователя и вставляет оную инициализацию. Не знаю есть ли эта опция у MPASM, а у ASM30/ASM16 имеется. Причем в MPLAB X она по дефолту включена.
Просто у меня в программе используются битовые флаги и через некоторое время программа зависает, пишу на ассемблере и не полный нуб в программировании. Регистры в ram используются как 8 битовые флаги. И если значение в ram будет фиг знает что, значит программа улетит не туда куда надо. Наверное самое оптимальное будет при запуске мк чистить ram через косвенную адресацию, это так, мысли вслух....
Для ассемблера стандартна процедура предварительной очистки/загрузки критичных значений для ОЗУ. Одновременно должна быть предусмотрена корректная переинициализация системы при условии возникновения аварийных сбоев (не обязательно при соответствующем сигнале аппаратного сброса).
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 18
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения