Форум РадиоКот

Установленая галка - запрограммированный (уст.0) бит. В хелпе к нему написано.

Насчет регистров: слева в окошке с деревом проекта можно посмотреть, какие переменные в каких регистрах или иных ячейках памяти "лежат" и исходить из этого.

Aheir писал(а):Насчет регистров: слева в окошке с деревом проекта можно посмотреть, какие переменные в каких регистрах или иных ячейках памяти "лежат" и исходить из этого.

Я так понял, что под "в окошке слева" вы имели ввиду окно в отладчике AVR Studio I/O View, да я смогу посмотреть где находятся переменные, но мне надо знать вот что, во время выполнения основной программы, я начинаю выполнять код написанный на ассемблере, который использует 10 регистров (R13-R22), во время его исполнения произошло прерывание, в теле прерывания происходят вычисления на С (умноженя,деления ...) и возникает вопрос , а не будут ли эти вычисления задействовать мои регистры (R13-R22) ? Смотреть ход выполнения всех функцый, задача не реальная. Меня интересует какие из регистров компилятор использует в своих вычислениях, а какие не трогает, и можно ли как нибуть повлиять на это.

Нет, я про CVAVR говорил. А если заранее объявить необходимое количество переменных как static так, чтобы они легли в определенные регисты? Тогда вроде как их значения (т.е. регистры) меняться не будут, и Вы сможете творить с ними на АСМе, что требуется.

Aheir писал(а):Нет, я про CVAVR говорил. А если заранее объявить необходимое количество переменных как static так, чтобы они легли в определенные регисты? Тогда вроде как их значения (т.е. регистры) меняться не будут, и Вы сможете творить с ними на АСМе, что требуется.

дело в том что , я использовал CVAVR 1.25.8 а там распредаления переменных по регистрам не видно, сейчас поставил V2.03.3 и стало видно. По листингу в отладчике видно, что при вызове прерываний сохраняются регистры R0,R1,R15.R22-R27,R30,R31

;// Timer 0 overflow interrupt service routine
;interrupt [TIM0_OVF] void timer0_ovf_isr(void)
; 0000 004F {
_timer0_ovf_isr:
ST -Y,R0
ST -Y,R1
ST -Y,R15
ST -Y,R22
ST -Y,R23
ST -Y,R24
ST -Y,R25
ST -Y,R26
ST -Y,R27
ST -Y,R30
ST -Y,R31
IN R30,SREG
ST -Y,R30
соответственно получается, что можно использовать только эти регистры, т.е. в прерывниях их можно использовать сразу, а в теле основной программы только при их предварительным сохранением, и то под вопросом. Дело в том что я начал и зучать См только в мае и многие вопросы мне не всегда понятны. И сейчас я понимаю так, что выполнение кода в прерывании начнется через 30 тактов, после его возникновкния + 30 тактов на выходе из прерывания, в ассемблере задержка составляет всего 4 такта и 4 на выходе, такие задержки как в Си (30+30) не всегда допустимы, возникает вопрос есть ли у компилятора настройки чтобы устранить возникающие такие большие задержки, или это все на что способен Си?

У меня вот нефига не получаеться написать даже елементарщину, шобы оно работало. Вот например простйший пример :
есть конопка S1, подключенная к одному из выводов PD0 , когда кнопка закорачиваеться , то в регистре SERG устанавливаеться соответсвующий бит , и включает прерывание. Прерывание должно установить высокий лог уровень на другом выводе PC0, который включит диод. Не могу написать ету програму , чтобы потом на VMLAB посмотреть на нее. Может кто-нибудь напишет етот мелаеький код Уже вся шерсть повылетала
Я предсавляю что для етого нужно зделать :
напистаь обработку функции прерывания
назначить входом ножку куда будет посупать сигнал с кнопки
выодом назначить ножку которая будет дид включать
но почемуто не получаеться

ищите наиболее простое решение задачи...

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

итак, что надо, чтобы включить светик?
а) опросить порт, к которому подключена кнопка. дождаться, пока кнопку нажмут
б) включить другой порт, к которому подключен светик.
в) снова проверять порт кнопки, ожидая, что кнопку отпустят.
г) погасить светик и перейти к пункту а.

при опросе кнопок надо подавлять дребезг, т.к. в момент замыкания кнопки контакт устанавливается не мгновенно, а в течение примерно 10 мс меняется туда-сюда. т.е. надо обнаружить изменение уровня порта, подождать 10 мс, после чего снова проверить уровнь на порту - если он не изменился - значит, кнопка действительно нажата, и можно ее обрабатывать. если уровень оказался другим - это дребезг, ничего делать не надо, надо продолжать ждать.

что касается конкретного примера, то:
1) по вышеприведенному алгоритму можно составить программу самостоятельно
2) на форуме кнопкам, дребезгу и программам для включения светодиодов посвящено много тем - ищите, и обрящете!

удачи!

ARV писал(а):... использование прерываний для обработки клавиатуры действительно необходимо очень-очень редко...

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

Старый анекдот писал(а):Обещали - когда научимся нырять, нам в бассейн воду нальют...

Yellow Tiger писал(а):Действительно - только в тех случаях, когда процессору и без клавиатуры есть чем заняться, а в учебных задачах это редкость.

скажу даже больше: когда процессор должен что-то делать "непрерывно", например, динамическую индикацию, АЦП - вот тут прерывания актуальны. Гораздо логичнее прервать функцию сканирования клавиатуры (которой в принципе все равно - 10 мс будет задержка или 11, или даже 20) обработкой АЦП, чем наоборот . Лично мне пока реальная необходимость в прерываниях от клавиатуры требовалась лишь для пробуждения из спящего режима, т.е. в случае "с точностью до наоборот" - микроконтроллеру ну совсем нечего было делать без клавиатуры

Асинхронные события нужно обрабатывать асинхронными методами. Все остальное - от лукавого. Если архитектура программы не соответствует строению процесса, который эта программа моделирует - это грабли. Спорить о частностях не хочу; в конкретных случаях, на конкретных компиляторах или кристаллах эти грабли могут оказаться бьющими не очень больно, но саму привычку расставлять грабли на всех углах я не принимаю. Обычно она исчезает по мере накопления опыта, то есть - информации об ошибках, своих или чужих (как в поговорке).

Yellow Tiger, вы производите впечатление знающего человека... и потому ваши загадочные фразы могут быть неверно истолкованы начинающими, которые сюда заглядывают очень-очень часто...
мне не хотелось бы превращать эту тему в дискуссию о граблях в программировании (которых и на ровном месте разложено не мало, не то что в дебрях), однако, чтобы все могли верно понять ваши мысли, просил бы вас подробнее рассказать о том, что более "от лукавого": прерывать на обработку клавиатуры (напомню - подавление дребезга - это равносильно 10 мс задержке) процедуру динамической индикации, или наоборот.

скажем, не в порядке спора (я уж сумею разобраться, когда что лучше делать), а в порядке "науки новичкам"

ARV писал(а):что более "от лукавого": прерывать на обработку клавиатуры (напомню - подавление дребезга - это равносильно 10 мс задержке) процедуру динамической индикации, или наоборот.

А что это у Вас список альтернатив так короток?!
Правильный ответ - и то, и другое - от лукавого, . Процедуры обработки прерываний д.б. как можно короче и должны заниматься только обработкой вызвавшего их события (так-что, никаких лишних задержек - ни на 10мс, ни на 50, ни на одну!), а антидребезг - это уже агрегирующая функция.
Как говаривали древние - "Разделяй и властвуй". (А ещё говорят - структурное программирование... - натурфилософия! Чистой воды! )

то есть по-вашему выходит, что надо и динамическую индикацию делать без прерываний, и опрос клавы, и собственно, основную вычислительную задачу программы - все в основном цикле... имхо, именно так предлагалось в обучалке... мда...

список альтернатив так короток потому, чтобы проще было выявить истину

чувствую, мне пора самоустраниться и из этой темы...

ARV писал(а):то есть по-вашему выходит, что надо и динамическую индикацию делать без прерываний, и опрос клавы,

Читайте, пожалуйста, внимательнее, а-то, в вашем изложении, всё получается строго наоборот: я сказал, что асинхронные события следует и обрабатывать асинхронно, а вы утверждаете, будто я за то, чтобы оба асинхронных события обрабатывать синхронно - разве же можно так путать?!
Когда я сказал, что "ни тот, ни другой" варианты не годятся, я говорил о непригодности вариантов, упомянутых вами, а не о тех, которые удовлетворяют требованиям, намеченным в том же посте:

Yellow Tiger писал(а):Процедуры обработки прерываний д.б. как можно короче и должны заниматься только обработкой вызвавшего их события

Если бы вы были чуточку внимательнее, вы заметили бы, что именно вызвало у меня возражения. Вы помните, как вы описали работу процедуры прерывания от клавиатуры? Цитирую:

ARV писал(а):...прерывать на обработку клавиатуры (напомню - подавление дребезга - это равносильно 10 мс задержке)...

То есть, вы почему-то считаете, что эта "10мс задержка" обязательно д.б. внутри процедуры обработки прерывания!
Вот я и говорю - ни в коем случае не так! Никаких задержек внутри процедуры обработки прерывания от клавиатуры! Только обработка самого события! Не понимаю, как вы умудрились не заметить этих слов, ведь вот же они в моем предыдущем высказывании:

Yellow Tiger писал(а):и должны заниматься только обработкой вызвавшего их события (так-что, никаких лишних задержек - ни на 10мс, ни на 50, ни на одну!)

Так-что, асинхронные ввод и вывод я рекомендую делать на прерываниях (когда это возможно), но только ввод и вывод(!), а не процедуры обработки введенных данных и подготовки данных для вывода! Скажем, готовить битовую маску для засвечивания правильных сегментов нужно не в процедуре вывода, а до неё, процедура же вывода должна только взять уже готовые данные и вывести - и больше ничего! Потому я и обращал внимание на необходимость выделять из процедур ввода/вывода ту часть кода, которая лишь обрабатывает/подготавливает данные, что это позволяет сделать процедуры обработки прерываний возможно более короткими.
И заметьте - к этому же решению можно придти и другим путём: процедуры обработки данных - синхронны (в отличие от процедур ввода с клавиатуры/вывода с мультиплексированием) и потому должны исполняться синхронным кодом, опять-таки - в отличие от процедур ввода/вывода, которые в упомянутом примере асинхронны.

ARV писал(а):список альтернатив так короток потому, чтобы проще было выявить истину

Если из нескольких вариантов выбрасывать правильные и оставлять к рассмотрению пару неправильных, то не только не станет проще выяснять истину - её вообще нельзя будет найти. Задачу об Ахиллесе и черепахе помните?

ARV писал(а):чувствую, мне пора самоустраниться и из этой темы...

я был прав

Yellow Tiger, вы хотя бы представляете себе, что из вашего сообщения следует? следует, что человек, не умеющий обработать кнопку никак вообще, должен разделить процесс ее опроса на асинхронную составляющую (нажатие или отпускание) и синхронную (выдержка времени для подавления дребезга), написать программу, которая бы все это реализовывала... думаю, ясно, что эта затея обречена на провал - рискну предположить, что у некоторой части желающих такое положение вещей вообще отобьет желание писать программы...

я ведь предупреждал - я разберусь в проблеме и теме, мне объяснять не надо, вы объясните другим так, чтобы они смогли последовать вашему совету... имхо, дело, конечно, не мое - говорите, что хотите... а я лучше умолкну, чтобы не поощрять словоблудие, споры, переходы на личности и т.п.

извините, ктому не понравилось, что я говорил.

P.S. ИМХО, правильный вариант решения программистской задачи, это тот, который позволяет получить правильный результат, в наикратчайшее время, с минимумом усилий при имеющихся ограничениях в ресурсах. отсюда, я считаю, в большинстве случаев можно считать процесс работы с кнопкой процессом не асинхронным, т.е. обнаруживаемым по факту возникновения "извне" , но синхронным (видимо, я искажаю толкование терминов, но так проще), т.е. обнаруживаемым в момент соответствующего запроса "изнутри". Тот факт, что на несколько миллисекунд раньше или позже мы обнаружим нажатие кнопки, никак не повлияет на общее поведение нашей системы (какой бы она ни была - время реакции самого тренированного человека не меньше 120 мс). И стремление мгновенно отреагировать на замыкание контактов кнопки - совершенно бессмысленная трата сил программиста (имхо). Решение же задачи несравненно проще для всех без исключения выполнить именно по алгоритму "опрос-задержка-опрос-результат", нежели иными способами, какими бы умозрительно верными или логичными они не выглядели.

ARV писал(а):человек, не умеющий обработать кнопку никак вообще,

Я прошу вас вернуться немного вверх и проверить - на какую именно вашу фразу я отозвался. И если вы это сделаете, то обнаружите, что речь идет вовсе не о том, как вы рекомендовали поступать в некоем конкретном случае, а о том, что вы человеку, который примет ваши слова за чистую монету, сказали буквально следующее:

ARV писал(а):вообще, использование прерываний для обработки клавиатуры действительно необходимо очень-очень редко...

Вы даже акцент сделали на словах "действительно необходимо". И вот, чтобы он не "всосал" это утверждение вместе с тем, что выполняет для него сейчас роль молока матери, я и привел точку зрения, которую считаю верной.
Представляю ли себе? А вы думаете - я шел другой дорогой? Очень хорошо представляю, и убежден, что только настойчиво разбираясь в том, что вы в другой ветке назвали дебрями, можно достичь стоящих результатов.

ARV писал(а):объясните другим так, чтобы они смогли последовать вашему совету...

Я объяснил:

Yellow Tiger писал(а):ввод и вывод я рекомендую делать на прерываниях (когда это возможно), но только ввод и вывод(!), а не процедуры обработки введенных данных и подготовки данных для вывода ... Скажем, готовить битовую маску для засвечивания правильных сегментов нужно не в процедуре вывода, а до неё, процедура же вывода должна только взять уже готовые данные и вывести...

Дополнено:
Рассуждения, которыми вы дополнили свой предыдущий пост, это распространенная ошибка. Сейчас я уже не располагаю временем для детальных пояснений, поэтому постараюсь передать только суть.
Дело в том, что наикратчайшее время и минимум усилий это не то, что вы описали, когда программист ищет способ как можно скорее поставить последнюю закрывающую фигурную скобку, а верный результат - это не одни только правильные результаты на выходе программы.
Если программист очень быстро напишет функцию ввода, которую он больше ни в одном своем проекте использовать не сможет, то он будет вынужден в новом проекте писать её заново, а если это не случайность, а результат определенной технической культуры, то он будет в каждом проекте писать функции ввода заново, с нуля - это уже не экономия ресурсов, а их растрата.
То же самое и с определением правильности программы: если заботиться только о правильности полученного результата и не уделять внимание правильности структуры программы (например, о разделении её на модули, выполняющие разные по содержанию функции), то твердо рассчитывать на повторное использование кода будет нельзя, а это та же растрата времени, только в больших масштабах.
На самых ранних этапах (т.е., новичкам) эти истины еще не разглядеть, но переучиваться всегда гораздо сложнее, чем учиться, и поэтому так важно знать о том, о чем я говорил еще в самом начале пути.

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

P.S.Предположение, что применение асинхонной обработки к асинхронным событиям продиктовано "стремлением мгновенно отреагировать на замыкание контактов кнопки" - ошибочно. Это проявление структурного подхода, модульности программ - необходимое условие повторного использования кода, которое, в свою очередь, является одним из значительных источников экономии времени и других ресурсов при разработке ПО.

Народ, слёзно прошу и на коленях умоляю - выложите Cvavr со всем необходимым на ifolder.ru или ещё куданить где есть докачка. Я со своим диалапом уже пятый раз пытаюсь с рапиды качать. Желательно с лекарством.

Pippeytz писал(а):У меня вот нефига не получаеться написать даже елементарщину, ...

Попробуйте вот это.

Cпачибо, уже разобарался но ваше пример тоже посмотрел. Вот еще небольшой вопрос : при настройке портов запись
DDRC= 0b1111111
Значит , что все билты в проту С будут выходами?


з.ы извиняюсь за ети тупые вопросы, я бы нашол на них ответы самостоятельно. только у меня сейчас времени мало - решил летом подзаработать на радиодетали И я в начале лета пообещал зедлать одному человеку девайс , когда он приедет, а еще не зделано нихрена изза проклятой работы

Pippeytz писал(а):Cпачибо, уже разобарался но ваше пример тоже посмотрел. Вот еще небольшой вопрос : при настройке портов запись
DDRC= 0b1111111
Значит , что все билты в проту С будут выходами?

Если ЖДАГ не помешает. Подробней на стр. 2 курса "устройство AVR"