Или я чего-то не понимаю, или что-то делаю не так.... В общем суть проблемы: В прерывании каждую секунду выполняется такой кусок кода
В цикле есть такой кусочек:
И проблема в том, что "Save_Preset" никак не хочет выполняться, а по отпусканию кнопки всегда выполняется "Load_Next_Preset"  Что я делаю не так?Добавлено: Wed Feb 12, 2014 4:52 pm |
Каждую секунду в R16 оказывается 255. Затем оно же попадает в HoldCount и тут же делится на два. С чего ж ему стать равным нулю? Надо бы mov повыпилить из верхнего куска. Добавлено: Wed Feb 12, 2014 5:15 pm |
Каждую секунду в R16 вообще много чего оказывается, регистр временный. И тем более по входу в прерывание он сохраняется в стеке. SBRS FLAG,PushedKey - при установленном флаге PushedKey в HoldCount уже ничего не попадает, регистр просто сдвигается. Флаг ставится по нажатию кнопки. По отпусканию сбрасывается. Метод тыка не прокатит. Добавлено: Wed Feb 12, 2014 5:21 pm |
Попробуй после SBRS FLAG,PushedKey написать две команды RJMP, одну из которых он будет пропускать в случае выполнения условия SBRS. По одному джампу будет выполнятся условие MOV HoldCount,R16 и LSR HoldCount по другому просто выход. SBRS ведь пропускает только одну следующую за ней команду, вот и получается что то у тебя в случае выполнения условия SBRS он делит на 2 а влучае не выполнения присваевает 255 и делит на 2 в итоге нуля мы не достигаем. Или может я чего не допонял? UPD Как вариант попробуй в студии, в режиме отладки, симитировать нажатие и через WATCH посмотреть что реально лежит в регистрах на момент сравнения, где-то тут косяк закрался) Добавлено: Wed Feb 12, 2014 5:30 pm |
Дело в том, что эта часть, которая в прерывании, используется и в другом месте - макросе регулируемой задержки. И этот макрос работает! Я, правда, не совсем уверен, что значение HoldCount доходит до нуля... Сильно много перекраивать, чтоб симуль запустить, дисплей и термодатчик по всему коду вырезать придётся...BenG писал(а): вот и получается что то у тебя в случае выполнения условия SBRS он делит на 2Дык так и есть! При зажатой кнопке условие будет выполняться всё время. В итоге должны получить ноль, но что-то не получается он... Буду кроить прогу под симуль, ничего не поделаешь.... Если кому-то непонятно по прерыванию: при отпущенной кнопке в регистр HoldCount загружается таким образом число 127. Добавлено: Wed Feb 12, 2014 5:43 pm |
Ты точно уверен, что SBR FLAG,1<<PushedKey; SBRS FLAG, PushedKey; MOV R16, 255 Приведет к попаданию 255 в R16 ? Добавлено: Wed Feb 12, 2014 10:20 pm |
Не туда роете, товарищ  Приведённый кусочек работает без нареканий. А теперь и в целом всё неплохо работает. Могу весь проект бросить, покуришь. Местами он неплохо комментирован. Проблема была найдена благодаря симмулятору, HoldCount портился в одном месте кода (не все старые остатки затёр). Как всегда - виновата невнимательность... 
И да, такой интересный вопрос: у кого-нибудь МК умирал от того, что его слишком много раз перепрошили? Добавлено: Wed Feb 12, 2014 10:57 pm |
Хм. Даже при 10К циклах это означает почти 30 раз в день в течение года... Добавлено: Wed Feb 12, 2014 11:08 pm |
Разработка нового устройства в руках не совсем ещё опытного человека - можно и 100 раз за день перешить
Просто интересны симптомы такой смерти, ошибки при верификации кода? Добавлено: Wed Feb 12, 2014 11:30 pm |
У мну есть один дохляк. Помер на н-ной перепрошивке, видимо, от кривой разводки платы в куче с нарузками на линиях программатора, леньки мне было поставить пару резюков)) Симптомы - последняя залитая прошивка работает, но с программатором общатся не хочет. ХЗ что с ним, забросил на полку. А если все нормально, то можно хоть целыми днями шить - производитель обещает 10 тыр. циклов перезаписи  Добавлено: Thu Feb 13, 2014 12:03 am |
Seriyvolk писал(а): Проблема была найдена благодаря симмулятору, HoldCount портился в одном месте кода Seriyvolk писал(а): Не туда роете, товарищ Так нечестно! Ошибку спрятал и спрашивает, где "тут" беда 
Вот этим ассемблер и плох - как только делаешь что-то сложнее включения трех лампочек по четырем условиям, код становится необозримым  Добавлено: Thu Feb 13, 2014 10:00 am |
Не ругайте ассемблер. На нем прекрасно пишутся и работают многозадачные системки управления с десятком прерываний, парой сотен переменных и флагов, десятками таймеров, подзадач, с протоколами обмена, планировщиками и расписаниями, математикой, защитами, адаптивностью и автотестами, и т.д. На тех же AVRочках (начиная с м644, м128). Добавлено: Thu Feb 13, 2014 8:15 pm |
Полностью согласен с предыдущим оратором  Добавлено: Thu Feb 13, 2014 8:16 pm |
Ага, только спустя пару лет даже в своем изделии хрен разбересси. Шестиимпульсный датчик скорости на восьмиимпульсный поменять не могу Добавлено: Thu Feb 13, 2014 8:49 pm |
Такого плана вещи должны закладываться в код ещё на этапе планировки устройства. Добавлено: Thu Feb 13, 2014 10:01 pm |
Если писать код по-человечески, с жестким разбиением на модули, подзадачи, подпрограммы (лучше - малюсенькие, экран-два длиной), со стандартными методами передачи параметров и сообщений, инициализации, обращения и выполнения, описывать для каждой подпрограммы и задачи входные и выходные данные, переменные и флаги, ограничения и особенности, все данные задачи хранить в отведенной ей области памяти, обращаться к переменным через функции и т.д., - то всё прекрасненько вспоминается и через год, и через пять лет. Более того: обычно вспоминать заново приходится уже через неделю-две. Потому что за это время успеваешь полностью перезагрузить мозг совершенно иными проблемами. Иногда даже в течение дня забываешь, что там было написано в 7 утра, и как оно работает. Вечером открываешь тексты, и вспоминаешь свой же код за пару минут. Фактически, приходится работать так же, как и этот процессор: обращаешься к задаче, загружаешь данные, делаешь что нужно, сохраняешь, прошиваешь, проверяешь, выбрасываешь из мозга и выходишь. Можно дальше заниматься совершенно другими делами. Шить, готовить еду, идти в магазин за продуктами, программировать ПЛИСку, страдать и плакать, рисовать схему, смотреть фильм, красить ногти. Или еще чего-нибудь. Если же писать всё "в кучу", как часто делают, - тогда да, точно ничего не поймешь. Поэтому, мигание лампочками - лучше написать примерно так: выделяем для светодиодика отдельную задачу. У нее есть функция целевого процесса, и функция инициализации, локальный обработчик таймера со своими счетчиками и флагами, обращение к функции ввода-вывода на светодиод (она находится в модуле ввода-вывода), функция получения данных о параметрах индикации (сами данные находятся в процессе верхнего уровня) или функция приема сообщения. Обращение к функции процесса размещаем в рабочем цикле процессора (или в цикле какого-нибудь планировщика более низкого уровня). Функция инициализации - соответственно, - вызывается либо в начальном процессе инициализации системы, либо в инициализации планировщика нижнего уровня. Функция инициализации приводит процесс в исходное состояние, устанавливает исходные значения флагов, счетчиков, выключает светодиодик. В самой функции процесса для светодиодика делаем следующее. Сперва запрашиваем функцию получения параметров индикации (или сообщения). Она возвращает нам указание, что нам делать с диодиком. Мигать, светить непрерывно или погасить совсем. Запоминаем значение. Если нужно светить или погасить - сразу обращаемся к функции ввода-вывода на светодиод. Далее вызываем функцию проверки события от таймера. Если событие есть - вызываем локальный обработчик таймера, если он досчитал заданный в настройках интервал мигания, и если нужно мигать (ранее мы запомнили, что нужно нам делать) - изменяем состояние диода на противоположное (через функцию ввода-вывода), далее обращаемся снова к локальному таймеру с целью его запуска на новый цикл, обращаемся к глобальному таймеру с сообщением о том, что его флаг получен и отработан, и возращаем управление вышестоящему коду (выходим из модуля). Если писать примерно так, и для каждого усстройства и процесса, - для каждой кнопки, релюшки, диода, индикатора, АЦП, порта, протокола обмена данными, пакетного драйвера, планировщика, матобработчика, да чего угодно - делать отдельные модули, которые общаются между собою через функции, буфера, сообщения и флаги, - то всё становится вполне понятно и гибко. Можно добавлять и убирать достаточно тяжелый функционал почти "на ходу". Конечно, это нужно сначала выработать в себе терпение, аккуратность, внимательность, способность к планированию и поэтапной подготовке и работе над проектом. Нельзя здесь ничего делать "с наскоку". (Да и не только в программировании это верно...). Не ради понта я пишу это. Я тоже еще только лишь учусь, и очень-очень мало что умею. Просто понемножечку разбираюсь, и понемножечку получается. Добавлено: Fri Feb 14, 2014 7:13 am |
Прекрасно сказано Еще весьма полезно в начале модуля в комментах делать его краткое описание: что делает, какие регистры использует, сколько по времени занимает выполнение и т.п. вещи.
Не удержался: http://bash.im/quote/415825 Добавлено: Fri Feb 14, 2014 8:42 am |
Таки да, но при таком писании (прежде всего - с подзадачами) заметно утрачиватся знаменитая ассемблерная компактность и скорость. Оттого лично я предпочитаю другой подход: алгоритмическую часть всю делать на ЯВУ, нисходящим методом, с документацией; а мелкие вставки для работы с железом (вывод в видеобуфер, например) выполнять на ассемблере. Антон совсем уже переделалась... "шить, ногти красить..." Молодец!Добавлено: Fri Feb 14, 2014 10:02 am |
С чего это она утрачивается, если бОльшую часть времени ядро, по сути, простаивает? Ждет флаги, условия, еще что-то... А грамотно написанный шедулер -- вещь очень и очень полезная. Добавлено: Fri Feb 14, 2014 11:14 am |
С того утрачивается, что появляются "лишние" переменные, условные переходы и т.п. Результат получается ближе к оптимизированному сишному коду. Добавлено: Fri Feb 14, 2014 11:42 am |
Никуда я не переделалась. Интерес к шитью был даже в детстве. Кстати, шитье - это вовсе не женское занятие в традиционном, историческом смысле. А ногти я крашу со школьного возраста. Ведь это красиво, и просто нравится. Кстати, это одна из причин, почему я перестала заниматься с железяками и всяким маслом, - ведь от этого очень портятся ногти и кожа. Хотя, комплексы из-за брутальности этих железок - тоже имеются. Спорить о языках смысла не вижу. Кому что удобнее... Я тут собираюсь изучить еще и Си, - пригодится. Ассемблеры просто приятнее и привычнее, но это не значит, что иные средства плохи. Добавлено: Fri Feb 14, 2014 12:07 pm |
perezx писал(а): Результат получается ближе к оптимизированному сишному коду. Ну, это уже вопрос, скорее, компромисса: хочешь читаемый и портабельный код -- пиши максимально универсально. Хочешь максимум компактности и быстродействия -- пиши под данный конкретный случай, но не жалуйся, что потом что-либо изменить удастся только "костыльным методом" Добавлено: Fri Feb 14, 2014 12:13 pm |
Об что и речь... Учитывая небывалый прогресс в железе, лучше написать на ЯВУ. Я, наоборот, за железки переживаю - портются и пачкаются от контакта с органикой Миллиметр-в-миллиметр сделаешь, покрытие нанесешь, выверишь - красота! Потом бах, болгарку рукой зацепишь - весь узел в дерьме и кровище Добавлено: Fri Feb 14, 2014 12:16 pm |
Ну блин, опять холивар на эту тему устроили 
Я лично поддерживаю автора этих слов: Anton писал(а): Если писать код по-человечески... То на любом языке все будет хорошо работать, понятно читатся и отлично повторятся, а на чем писать пускай каждый для себя сам определяется. Добавлено: Fri Feb 14, 2014 7:06 pm |
Ни вком случае не пишите для железок на Яве!! На Яве можно писать разово выполняемые, не критичные к скорости и не работающие с железом модули. Добавлено: Fri Feb 14, 2014 7:53 pm |
|
Лицензионное соглашение (c)Flyback.org.ru Российское общество любителей высоких напряжений. Использование материалов с данного сайта и форума возможно только с разрешения администрации. |
