AVR vs PIC

Добрый день.

[skip]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

8-) Я по полу катался от смеха - объясни мне, Георгий, зачем ловить каждый бит таймера, чтобы затем отобразить 8-значный результат в виде "4-ех значащих цифр". На такое, похоже, только у тебя ума может хватить. 8-) У тебя получается не просто "дешевый" во всех отношениях частотомер, а вообще детский, для детей до 3-ех лет. 8-)

На AVR, даже на 8-ми битном таймере никаких потерь нет и быть не может. Любые задержки (на вход в прерывание и выполнение команд) вычисляются после пуска таймера/счетчика внешних событий путем выполнения некоторого кол-ва команд с нужным кол-вом тактов и чтения таймера. Получаешь фактически отношение измеряемой частоты к тактовой. В самом прерывании по переполнению таймера всего две команды - инкримент старшей половины и возврат из прерывания. После остановки таймера вычисленная задержка вычитается из

16-битного числа. Все! У меня по этому принципу 8-ми битный таймер вычисляет скорость манчестера-II и корректирует "ход часов" на своей стороне с точностью до двух тактов тактовой частоты, т.е. частота передатчика может плавать в пределах +-40-50% от номинала без всяких проблем с приемом такого сигнала. И это работает, причем на дохлом по периферии AT90S1200 с одним единственным 8-ми разрядным таймером, расширенным программно до 16-ти разрядов.

В твоем случае "с 4-мя значащими цифрами" они не будут мельтешить даже при потере 4 младших бит результата. 8-)

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

Никакой ошибки не появится - это все твое больное воображение и неумение думать головой при написании программы на конкретном контроллере.

Весь вопрос - зачем вообще останавливать таймер? Закончилось одно измерение, скорректировали результат, обнулили таймер и его старшую часть в РОН и готовим вывод на экран, закончилось очередное измерение и все сначала.

Правильный вопрос, только ты его себе задай сначала.

AVR на 8МГц за период измерения 1 мс успевает сделать 4-8 тыс. команд что с запасом хватает для всех расчетов и вывода вычисленного значения на экран в режиме динамической индикации.

Остановка таймера - не кривое решение. Нет. Оно - больное. 8-)

Не надо проблемы PIC приписывать метро. 8-) В AVR не требуется остановка таймера и в этом его плюс - распараллеливание работы за счет более высокой скорости, хотя и в ущерб потреблению. Однако лично меня потребление почти не интересует - батарейки AAA и AA стоят практически одинаково.

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

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

[skip]

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

А тебе не приходило в голову, что любой интервал считается элементарно по тактам и при работе любой программы на любом контроллере нет ни одного неизвестного, которое может дать значимую ошибку? Кол-во переполнений таймера известно? Известно - оно в tmr0h. Время входа в прерывание, работы в нем и выхода из него известно? Безусловно. Так откуда берется надуманная тобой ошибка? [skip]

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

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

Почему верхняя граница в 20 МГц, а не в 50? Или не в 100? Я просто не могу себе представить, для чего может понадобиться частотомер с таким диапазоном, да еще с "4-мя занчащими цифрами". Разве что ребенку в качестве игрушки.

8-)

Серъезный прибор должен уметь мерять не только частоту/период, но и скважность, отношение двух частот, "дрожание" частоты, ее амплитуду и иметь диапазон измерения от герц до гигагерца. Для этих целей практически одинаково подходят и PIC и AVR и оба будут обвязаны не одним десятком деталей.

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

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

8-) Это с "4-мя значащими цифрами"? Ну насмешил! 8-)

Потому что он тебе не нужен. 8-) Его родило твое больное воображение в процессе спора, как аргумент "за PIC". Ну или ты никогда не занимался "выездным" ремонтом/настройкой - выбирай по вкусу. 8-)

Я не вижу особых преимуществ ни в архитектуре PIC, ни в архитектуре AVR. Спор породили и поддерживают люди, которые знают одну из архитектур лучше и имеют опыт ее использования. Сразу скажу - я пишу под AVR. Выбрал именно его, потому что в большинстве задач мне нужна была его _вычислительная_ скорость, а она выше, чем у PIC при одинаковой частоте тактирования всего контроллера. PIC-и изучал неглубоко, но AVR понравились больше как архитектурой, так и периферией. Ты, Георгий, возможно знаешь PIC лучше меня, но AVR - явно хуже. Ну а если не знаешь, то зачем споришь?

Добрый день.

А реальные задачи могут быть решены на разных контроллерах и куча из них, возможно, будет решена на PIC, но другая куча - на AVR. Причем есть ситуации, когда конкретное решение на PIC не может быть заменено на аналогичное на AVR и _наоборот_! Так о чем спор? Что ты хорошо знаешь PIC? С этим никто не спорит. Что ты плохо знаешь AVR? Это тоже, поверь мне, ты уже всем доказал. [skip]

У меня они через одну - приходится передавать закрытую информацию по открытым каналам, причем с сеансовым ключем.

Мне наплевать, что там прижилось, а что нет - функции шифрации/дешифрации работают с битовым индексированным массивом и в моем случае прекрасно обрабатываются AVR-ом.

Проблемы у тебя могли быть только с головой - думать ей ты явно не умеешь.

Эти задачи лично я делал еще в "детском саде" - когда только-только начинал работать с AVR. Попробуй ты "построить" самосинхронизирующийся протокол типа манчестера-II с произвольным +-50% плавным отклонением "хода часов" передатчика в процессе передачи и "теневой" передачей состояния хэша сеасового пароля вместе с данными, которые шифруются/расшифровываются предидущим сеасовым паролем. Это реальная задача и она решена мной на AVR.

Привет!

Thu Jul 15 2004 11:15, Andrew V. Miheev wrote to George Shepelev:

...

AVM> Hа AVR, даже на 8-ми битном таймере никаких потерь нет и быть не может. AVM> Любые задержки (на вход в прерывание и выполнение команд) вычисляются AVM> после пуска таймера/счетчика внешних событий путем выполнения некоторого AVM> кол-ва команд с нужным кол-вом тактов и чтения таймера.

Каким образом можно вычислить задержку на вход прерывание, когда прерываться могут 1...4 тактовые команды?

14-Jul-04 14:43 George Shepelev wrote to Oleksandr Redchuk:

OR>> Определись сначала, что ты хочешь. _____^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

OR>> (чего никто не заставляет делать даже не останавливая таймер), то ты OR>> готов потерять такты на входе таймера за то время, пока он будет OR>> остановлен.

GS> Повторяю, нужен частотомер. Hафиг мне нужны "такты", которые я всё Изначально было сказано "прочесть значение таймера, не потеряв перенос из младшего байта в старший". Задача решается, причём для таймера решается "честно" с точки зрения таймера как устройства для отсечения временных интервалов. Если бы стояла задача "отработать *один* раз временной интервал, а дальше всё начнётся заново" то я бы просто загрузил в таймер такое число, что в конце нужного мне интервала взвёлся бы его флаг переноса и проверял бы только этот флаг, что проще.

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

OR>> 2) Если таймер остановить, то и при чтении его+софтового расширения OR>> тоже никаких потерь переносов из младшего в старший не будет

GS> Зато появится ошибка отработки длительности временного интервала. Откуда? Только не делай умный вид "сам разберёшься, если не дурак". Объясни, дурак я, дурак. Не понимаю, почему если остановить аппаратный 16-битный таймер, то ошибка не возникнет, а если остановить аппаратный 8-битный таймер с расширением в прерываниях, то ошибка возникнет.

OR>> Hу покажи мне, неучу, да всем остальным страждущим сокровенных OR>> знаний, пример чтения 16-битного таймера и 8-битного с софтовым OR>> расширением.

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

Для *измерения_частоты* счётчик и я буду останавливать.

Для отработки *одиночного_временного_интервала* таймер я буду предзагружать нужным числом.

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

OR>>>> GetTimer: GS>>> Это что, попытка считать "полное" значение таймера в момент GS>>> завершения временного интервала? Очень хорошо, смотрим: OR>> Это чтение текущего состояния таймера без нарушения его хода.

GS> "Сами создаём себе трудности, чтобы затем их мужественно преодолевать" GS> (c) Нет. Отвечаем на поставленный вопрос "считать показания таймера без потери переноса из младшего байта в старший". А если у ставившего вопрос букашки в глове и он на самом деле хотел спросить "дать счётчику посчитать заданное время" - то это его детские трудности.

GS>>> PIC позволяет включить и выключить таймер одной командой, что GS>>> обеспечивает _точное_ формирование временного интервала даже при GS>>> низкой тактовой частоте ядра. AVR тоже даёт возможность включать и выключать таймер одной командой. В равных условиях, т.е. в аккуратно написанной ассемблерной программе. В C-шной - двумя.

GS> Частота есть количество входных импульсов, делённое на интервал времени, GS> за которое _велось_ наблюдение за сигналом. При неточной отработке этого GS> интервала - точность измерений снижается. Что происходило в то время, GS> когда наблюдения не велись, всё равно не показывается. Я понятно излагаю? Теперь да. С третьего раза у тебя вышло полностью изменить постановку вопроса и изложить её уже без разночтений.

OR>> Потому что именно в нём у пиков преимущество?

GS> Потому что это _реальная_ задача. Достаточно типичная. Во-во. "а все остальные назовём нетипичными".

GS> То, что описанный прибор окажется _значительно_ точнее твоего GS> "супермультиметра" - тоже серьёзный аргумент. Особенно после GS> сравнения габаритов и цены ;) Какого "моего супермультиметра"? Цена увеличится на цену epm3064. Габариты практически не увеличатся (определяются больше иникатором и входной частью с предделителем с ГГц). В EPM3064 я размещу два 20-битных аппаратных счётчика с аппаратными же цепями разрешения счёта одного выходным сигналом другого и прочие необходимые вещи типа доступа к этому всему по SPI. А если считать, что "основной" счётчик может находиться в однокристалке, в альтеринке для неё только 4-битный предделитель (тогда диапазон до 80MHz уже и AVR потянет) и 20-битный "опорный" счётчик, то это всё должно вообще в EPM3032 влезть. Увеличится только потребление. Если давит, я в ту же плату впаяю немного более дорогой CoolRunner, у них с EPM3K цоколёвка совпадает. А по точности и по возможностям решения на голом пике точно отдыхают (а не на голом, повторяю, у пика нет преимуществ).

При удорожании комплектовки на уровне $3.

Я за интернет за выкачку писем по этому треду наверное уже больше заплатил.

OR>> Моё "меня интересует диапазон выше ZZZ + возможность мерять отношение OR>> частот" -- это неубедительно.

GS> Твой "супермультиметр" это умеет? Hет? Тогда почему это должен уметь GS> прибор, который нужен мне? Какой такой "мой супермультеметр"? Ты точно выспался? Или ты меня с Бойко путаешь? Внимательность, достойная суперпрограммиста, оттренированного на ручном размещении переменных по банкам. Вполне коррелирует с твоей неспособностью с первого раза объяснить, чего же хочешь.