AVR для "чайников"

Матроскин · 02.11.2006 21:09:44

Liv пишет:

Это плохое предложение. Очень длинный обработчик прерывания получится. Я так делал на 8051, потому что они сами имели низкую производительность, там это не так заметно. Для AVR очень глупо сидеть в прерывании и ждать, пока придет следующий бит. Бесполезно тратится процессорное время. Прерывания должны быть как можно более короткими. Естественно, что в таком случае понадобится одно или два внешних прерывания на каждый принятый бит и, возможно, одно таймерное прерывание. Всё зависит от конкртной реализации декодера. Довольно хороший декодер RC-5 есть по ссылке (правда, на Си): markh.de/software/rc5dec.c

Не надо ругаться, уже почитал. Прерывание инициируется падающим фронтом. (по крайнией мере INT0..3, у старших мег вроде можно переключать по фронту по спаду и т.д.)

Liv пишет:

В состоянии покоя (когда нет ИК сигнала) на выходе приемника что? Ноль или единица?
А осциллографом или тестером посмотреть слабо? Или datasheet почитать? В состоянии покоя там единица, интегральный фотоприемник SFH-506 и подобные инвертирует сигнал.

Liv пишет:

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

Я не жаловался, что меня не берут инженером. Берут еще как. Тока работать почти бесплатно надо. Я на это жаловался.

Вот Вы говорите, что надо использовать 2 прерывания для декодирования RC5. Одно по переполнению ТС0, другое по сигналу от ИК-приемника. Но у меня в документации от КТЦ-МК (там про старые меги603 и 103) написано, что внешние прерывания имеют самый высокий приоритет (после Reset). Т.е. если будет вызвано внешнее прерывание, прерывание по переполнению ТС0 уже вызвать не удастя,
так что ли?? Как же мы тогда сможем пользоваться таймером-счетчиком?? Или можно как-то сделать?? А то без таймера-счетчика неудобно время измерять. Вот этого я в даташитах не нашел.

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

Liv · 02.11.2006 21:36:54

Dmitry пишет:

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

В таком случае к чему весь этот алгоритм? После наличия первого спада запускаем таймер с периодаом 3/4 такта, задвигаем сэмплы в регистр и имеем на выходе готовый код.

Матроскин пишет:

Не надо ругаться

Это ж я не со зла, а для повышения эффективности Вашей деятельности smile

Матроскин пишет:

у старших мег вроде можно переключать по фронту по спаду и т.д.

Не у старших мег, а у всех AVR.

Матроскин пишет:

в документации от КТЦ-МК (там про старые меги603 и 103) написано, что внешние прерывания имеют самый высокий приоритет (после Reset). Т.е. если будет вызвано внешнее прерывание, прерывание по переполнению ТС0 уже вызвать не удастя,
так что ли??

О приоритетах прерываний AVR здесь уже спорили, повторяться не буду. AVR не имеет полноценного контроллера прерываний с поддержкой приоритетов. То, что в datasheet называют приоритетами, на самом деле есть лишь последовательность обслуживания прерываний при ОДНОВРЕМЕННОМ поступлении запросов. В любом случае, вложенные прерывания возможны, но реализовывать их надо ручками. Если в начале обработчика какого-то прерывания Вы напишите команду sei, то этим самым Вы сделаете приоритет этого прерывания низким, т.е. разрешите прерывание обработчика другим обработчиком прерывания.

В случае же декодера RC-5 прерывания намного короче интервалов, через которые они возникают. Пришел перепад - возникло прерывание. Обработчик завершился. Через некоторое время возникает прерывание таймера. И так далее. Одновременных запросов при нормальной работе быть не может.

Матроскин пишет:

И еще. Я задаю "глупые" вопросы не потому, что мне лень взять осцил или посмотреть даташит. Я элементарно могу не иметь возможности это сделать.

Как Вы могли заметить, Ваши вопросы на форуме не остаются без ответа. Но если у Вас нет даже даташита на используемый микроконтролер, тогда уж извините - Ваши вопросы не более как издевательство над участниками форума smile

Pyku_He_oTTyda · 02.11.2006 21:37:52

Могу выслать пару книг

VladI+ · 03.11.2006 02:00:56

Матроскин ,
Вы интересовались BASCOM AVR?

Тестер для проверки пультов дистационного управления RC5.

'---------------------------------------------------------------------------
'на экран LCD выводится информация - адрес и номер команды стандарта RC5
'Основную задачу-декодирование принятой команды выполняет подпрограмма Getrc5.
'В основу подпрограммы положен алгоритм,описанный в AVR410.
'Bascom AVR compiler:Version 1.11.8.3
'----------------------------------------------------------------------------
$regfile = "attiny2313.dat"
'контроллер ATtiny2313
$crystal = 12000000
'частота кварца, гц
Config Lcd = 16 * 2
'настраиваем тип дисплея
Config Lcdpin = Pin , Db4 = Portb.4 , Db5 = Portb.5 , Db6 = Portb.6,Db7 = Portb.7 , E = Portb.3 , Rs = Portb.2
'настраиваем режим работы , управляющие сигналы LCD
Config Rc5 = Pind.2
'вход RC5
Dim Address As Byte , Command As Byte
'объявляем переменные
Enable Interrupts
'Разрешить прерывания
Do
Определение начало простого цикла
Getrc5(address , Command)
'Считатать данные из ПДУ
Command = Command And &B01111111
Cls
'очистка экрана LCD
Lcd "Adress: " ; Address
'выводим значение адреса
Lowerline
'курсор на вторую линию LCD
Lcd "Command:" ; Command
'выводим значение команды
Waitms 100
задержка 100 ms
Loop
End

Liv · 03.11.2006 08:52:32

VladI+

А где, собственно, текст декодера (функции Getrc5)?

Матроскин · 03.11.2006 09:38:39

Liv пишет:

Это ж я не со зла, а для повышения эффективности Вашей деятельности

Ну, хоть это хорошо.

Liv пишет:

О приоритетах прерываний AVR здесь уже спорили, повторяться не буду. AVR не имеет полноценного контроллера прерываний с поддержкой приоритетов. То, что в datasheet называют приоритетами, на самом деле есть лишь последовательность обслуживания прерываний при ОДНОВРЕМЕННОМ поступлении запросов.

Ясно! Вот эти даташитовские "приоритеты" и сбили меня с панталыку.
Теперь давайте вернемся к нашим баранам, вернее к RC5. Идея обработки всей посылки в одном прерывании Вам не нравиться
Вы говорите она забирает слишком много процессорного времени. Тут мне так кажется, с какой стороны смотреть. 14мс в масштабах
управления например предусилителем или телевизором - на мой взгляд это мелочь. Там просто нет больше задач, требующих срочного и безотлагательного решения. Если если у нас в течении 14мс не будут переключаться входы или настраиваиться тюнер, юзер этого на глаз и не заметит. Кроме того, именно для этих целей мы как правило и жмем кнопки на пульте. До тех пор,пока команда не принята, мы один фиг ничего не сделаем, хоть у нас одно длинное прерываниие, хоть 14 коротких. Так что 14-мс задержка в выполнении команды (время приема самой команды) будет все равно, это неизбежное зло. Конечо, я не спорю, в других случаях (на станке для лазерной резки, как у Вас в статье) это может и актуально, но в бытовой аппаратуре - нет. Просто там все вещи, которыми управляет МК, как правило в десятки тысяч раз медленнее самого МК. И самое медленное звено, как Вы когда-то говорили - юзер.

Но все-таки, интересно, Что предлагаете Вы?? Я не совсем понимаю. Инициировать прерывание изменением уровня ны выходе фотоприемника и в прерывании считать те самые Ref1 и Ref2... Ой, нет так не выйдет. На половие периода ведь опять будет изменение... Да и не понятно, в каком собственно, месте текущего бита мы находимся..

Или может так: Ожидаем прерывание падающим фронтом. В прерывании "включаем секундомер", а заодно переключаем
биты ISC так чтобы теперь прерывание вызвалось нарастающим фронтом (если у нас сейчас ноль, то на второй половине периода 1 должна быть).
Если такое прерывание не вызвалось в течении 5/4 периода (можно примерно, мерить не обязательно) значит ошибка. Вызвалось - делаем выборку и записываем 1. Для приема последовательности единиц метод хорош. Но если за единицей 0 стоит? Тогда в конце битападающего фронта не будет,а будет он в середине следующего бита... бред получается. Вот оно, тонкое место. Если за единицей стоит ноль, то от начала бита уже не синхронизируешься. А как прерыванием синхронизироваться от середины бита, мне не совсем ясно. Вернее не ясно, как потом определить в какое место бита мы попадаем. Но я видимо опять чего-то не понимаю. Если не трудно, объясните немного подробнее, что Вы имели ввиду. Только не нужно сразу программ, если можно, опишите алгоритм. На тем как это реализовать, уже сам думать буду.

ЗЫ А даташитъ по SFH-506 у меня есть. ТОка он на немецком, сволочь!! smile

Vasil · 03.11.2006 09:51:22

ссылка будет действительна в течении 2х часов, качайте если успеете (179кВ)
www.chipinfo.ru/docs/61bc75754f121ea290 … 0_SMNS.pdf
8.50 по Киеву

Отредактировано Vasil (03.11.2006 09:52:04)

Dmitry · 03.11.2006 10:21:36

Vasil пишет:

ссылка будет действительна в течении 2х часов...

Года полтора уже лежит и пока что никуда деваться не собирается:
www.pology.zp.ua/har/Files/PDF/sfh506_36.pdf
Кстати, даташит этот на ДВУХ языках одновременнно - немецком и англиском. Матроскин, может у Вас такой же?

Матроскин · 03.11.2006 10:38:28

Dmitry пишет:

Года полтора уже лежит и пока что никуда деваться не собирается:
www.pology.zp.ua/har/Files/PDF/sfh506_36.pdf
Кстати, даташит этот на ДВУХ языках одновременнно - немецком и англиском. Матроскин, может у Вас такой же?

Нет, у меня был чисто немецкий. Скачал, спасибо.

Liv · 03.11.2006 14:06:32

Vasil пишет:

ссылка будет действительна в течении 2х часов...

Прикольно, когда это преподносится как некая ценность smile Достаточно в Google набрать "SFH-506 datasheet", и первая же ссылка - то что нужно. Можно еще посмотреть даташиты на аналоги (они лучшего качества), например, TSOP1736.

Матроскин пишет:

14мс в масштабах управления например предусилителем или телевизором - на мой взгляд это мелочь.

В принципе - да. У меня вся самодельная аудио-аппаратура работает на 51-х процессорах, так как радиолюбительство я забросил и ничего нового не делаю. А декодер там работает именно так, как Вы описываете. И ничего, все живы. Хотя в одном месте он всё-же мешает: в кассетной деке TK-140 www.spetspribor.com/nsm/images/tk140.jpg в режиме перемотки команды ДУ приводят к пропускам в работе счетчика ленты.

Матроскин пишет:

Но все-таки, интересно, Что предлагаете Вы?? Я не совсем понимаю.

Приходит прерывание по спаду. Загружаем в таймер задержку 3/4 периода. Приходит прерывание таймера. Считываем состояние выхода фотоприемника, задвигаем в регистр. Если был ноль, перестраиваем прерывание по фронту, иначе - по спаду. После того, как все биты приняты, переписываем код команды и ситемы в соответствующие переменные. Всё, если не считать обработки тайм-аута. И еще. Временной интервал одного бита для RC-5 жестко определен стандартом, поэтому измерять длительность старт-бита не только не нужно, но и вредно (фотоприемник может искажать длительность импульсов). Поэтому длительность периода можно рассматривать как заранее известную константу.

Матроскин пишет:

Если за единицей стоит ноль, то от начала бита уже не синхронизируешься.

Нет там никаких проблем. Посмотрите картинку, которую я постил недавно. Там цветными точками отмечены моменты прерываний. Всё очень прозрачно.

Radiohobby Forum

Объявление

#221 02.11.2006 21:09:44

Re: AVR для "чайников"

#222 02.11.2006 21:36:54

Re: AVR для "чайников"

#223 02.11.2006 21:37:52

Re: AVR для "чайников"

#224 03.11.2006 02:00:56

Re: AVR для "чайников"

#225 03.11.2006 08:52:32

Re: AVR для "чайников"

#226 03.11.2006 09:38:39

Re: AVR для "чайников"

#227 03.11.2006 09:51:22

Re: AVR для "чайников"

#228 03.11.2006 10:21:36

Re: AVR для "чайников"

#229 03.11.2006 10:38:28

Re: AVR для "чайников"

#230 03.11.2006 14:06:32

Re: AVR для "чайников"

Подвал форума