Attiny13. Ассемблер.
Вопрос такого характера. Возможно ли после подачи низкого уровня на ногу Reset начинать программу не с начала, а с другого места?
Суть в том, что не хватает ноги, а бит RSTDISBL ставить не хочется.
что то мне подсказывает, что просто сбросится и начнет программу сначала...
Только если в самой программе где-то сохранять в ПЗУ какую-нибудь переменную типа флага. А при инициализации после сброса ее проверять. И если она стоит, то переходить на другое место программы. Только как это отслеживать... не знаю...
А строка прерывания .org0 rjmp reset?
И метку Reset поставить там, где нужно, а не вначале кода? Игнорируется ли эта строка при простой подаче питания на МК?
P.S. Я бы поэкспериментировал, но пока нет возможности
Viper115 писал(а):Игнорируется ли эта строка при простой подаче питания
Нет не игнорируется. Все будет последовательно.
Все равно при включении МК происходит сброс по резет. Там даже фьюзы есть подобные, которые его на земле держат, пока питание не выравняется. И плюс к ним еще более медленная цепь сброса из резистора на плюс и конденсатора на минус...( а в особо ответственных случаях, даже микросхемы применяют, которые питание замеряют очень быстро и резет жмут)... Специально, чтобы стабильнее запускался, без помех и т.д. Т.е. по сути резет, как первое прерывание. ))) Поэтому и говорю, что тока обработка флага из ПЗУ при инициализации... Но в ПЗУ медленно записывает, да и как угадаешь, что именно в этот момент можно нажимать на резет?
Может проще рассмотреть вариант с каким-либо дешифратором???? У которого много кнопок и пара выходов на МК? Тогда можно много кнопок нацеплять. Или матричная клавиатура?
Последний раз редактировалось СКАЗОЧНИК Пн окт 27, 2014 18:07:21, всего редактировалось 2 раза.
Если питание не пропадает, то даже по нажатию ресета содержимое регистров общего назначения и ОЗУ сохраняется. Так что можете держать флаг в одном из регистров. Или в оперативке.
Поверьте, достаточно надежно. ) ОЗУ сохраняет свои значения до нескольких секунд после пропажи питания. Не зря СИшные компиляторы принудительно зануляют объявленные переменные в стартовом коде. )
Ну, а если все-таки боитесь - команды SPM и LPM Вам помогут.
Pink-Pank писал(а):ОЗУ сохраняет свои значения до нескольких секунд после пропажи питания. Не зря СИшные компиляторы принудительно зануляют объявленные переменные в стартовом коде.
cbiyst компиляторы делают это вовсе не из-за того, что ОЗУ долго сохраняет данные (что по большому счету неверно), а для обеспечения всегда одного и того же предсказуемого состояния программы при старте.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Прям так и чешется язык поспорить. )))
А Вы не задумывались о том, почему компиляторы принудительно инициализируют ОЗУ, но не делают этого с периферийными регистрами? ) (Брать во внимание генератор кода так не любимого Вами CodeVision во внимание не будем. ) Наверное, есть на то веская причина... А точно! Компилятор умеет предсказывать состояние периферии при старте! )
Viper115 писал(а):Attiny13. Ассемблер.
Вопрос такого характера. Возможно ли после подачи низкого уровня на ногу Reset начинать программу не с начала, а с другого места?
СКАЗОЧНИК писал(а):сохранять в ПЗУ какую-нибудь переменную типа флага. А при инициализации после сброса ее проверять.
Это и вправду будет велосипед... Причем с квадратными колесами
IN R16,MCUCR ;читаем регистр состояния
SBRS R16,EXTRF ;проверяем бит внешнего сброса
RJMP NO_EXT_RES ;если не было внешнего сброса, переход
;
;делаем что-то, если внешний сброс был
;
RJMP EXIT
NO_EXT_RES:
;
;делаем что-то, если не было внешнего сброса
;
EXIT:
Неправильно собранная из неисправных деталей схема нуждается в отладке и сразу не работает... (С)
Pink-Pank писал(а):Прям так и чешется язык поспорить. )))
А Вы не задумывались о том, почему компиляторы принудительно инициализируют ОЗУ, но не делают этого с периферийными регистрами?... Наверное, есть на то веская причина... А точно! Компилятор умеет предсказывать состояние периферии при старте! )
чешется чаще всего от нечистоплотности - помойте язык мылом.
периферия при сбросе (начале работы) инициализируется АППАРАТНО, поэтому нет никакой нужды инициализировать ее принудительно.
кроме того, язык Си придуман не для микроконтроллеров и не обязан предпринимать какие-то меры по работе с какой-то там ПЕРИФЕРИЕЙ.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
чешется чаще всего от нечистоплотности - помойте язык мылом.
5 баллов! ))
Так и в PC-шке память - по сути набор конденсаторов, который хранит свое последнее значение после прекращения питания еще какое-то время. ) Поэтому и инициализируют принудительно - чтобы неожиданностей не было. ) Если бы память, как и периферия автоматом сбрасывалась - никто бы не усложнял так жизнь. Согласитесь! )
К тому же, есть стартовый код, который с самим языком СИ вообще никак не связан. А завязан как раз на особенности конкретной платформы.
мда, не получается у вас понять смысл сказанного... попробую по полочкам разложить:
1. программа в своей работе должна опираться на некую однозначную, т.е. не зависящую от разных внешних условий, опору. иначе говоря, состояние статических переменных должно быть каким-то однозначно определенным, чтобы программист мог на это опираться в своей работе.
2. по стандарту языка все статические переменные обнуляются. main по стандарту - самая первая функция - как же обнулить переменные еще до обращения к первой функции? стандарт об этом умалчивает - просто обнуляются и все. в случае с PC все просто - сегменты данных со всем начальным содержимым могут быть размещены прямо в ЕХЕ-файле и оттуда попадут в оперативку, это обеспечивает загрузчик ОС. а в случае с МК загрузчик отсутствует, поэтому придумали некий startup-код, который выполняет эти операции до того, как начнет работать main.
3. все эти проблемы возникли именно из-за того, что состояние ОЗУ после подачи питания непредсказуемо. об этом я писал сразу же.
ARV писал(а):компиляторы делают это вовсе не из-за того, что ОЗУ долго сохраняет данные (что по большому счету неверно), а для обеспечения всегда одного и того же предсказуемого состояния программы при старте.
из вышесказанного можно сделать только один вывод: обнуление статических переменных делается только потому, что того требует стандарт языка Си. что я и пытаюсь вам объяснить. если стандарт не требует обнулять локальные переменные - они по умолчанию и не обнуляются.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Да, нашел эти пункты в стандарте. Вынужден согласиться. )
Но вот по поводу 3-го пункта хочу уточнить. )
все эти проблемы возникли именно из-за того, что состояние ОЗУ после подачи питания непредсказуемо.
Непредсказуемо потому, что явно не инициализируется аппаратно. Но ведь всем известно, на каких физических принципах строится оперативка. И что с ней бывает по пропаже питания. А у нас здесь даже не пропажа питания. А просто системный сброс. Поэтому вся ОЗУ и РОНы будут хранить свои последние значения, которые были до сброса, до тех пор, пока не будут изменены на другие. Вот именно это я и предлагал использовать.
что то мне подсказывает, что просто сбросится и начнет программу сначала... 
Не зря СИшные компиляторы принудительно зануляют объявленные переменные в стартовом коде. )
А точно! Компилятор умеет предсказывать состояние периферии при старте! ) 
