AVR vs PIC

Добрый день.

Так это и замечательно! 8-)

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

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

Здравствуйте.

GS>>> Понимаешь, я-ж не виноват, что ты тормоз... AK>> Понимаешь, я привык аргументированно отвечать за свои слова. GS> Ты флейм считаешь аргументированным ответом? Талант! ;)

Отсылка к документации не является аргументом ?

AK>> Ты же видимо не обучен. GS> "Hачни с себя!" (c)

GS>>>>> MOVLW 01b GS>>>>> MOVWF PORTx ; инициализация порта "противофазными" битами GS>>>>> MOVLW 11b ; модифицируемые биты GS>>>>> loop1: GS>>>>> XORWF PORTx,1 ; модификация с прямым доступом к порту GS>>>>> ; 1 цикл GS>>>>> GOTO loop1 ; 2 цикла AK>>>> А теперь давай по существу. GS>>> Даже не попытаешься сделать это-же на AVR? Такой ведь хороший GS>>> процессор, а не может сделать простенькую задачку... AK>> Понятия не имею, что ты хочешь получить и зачем это нужно.

GS> "Чукча не читатель"? AK>> Причем здесь "противофазные биты" ? GS> Хороший пример тривиальной задачки, которая из-за извратной GS> архитектуры AVR GS> на ней по-людски _не_ делается.

Твои задачи только и ограничиваются дерганьем ножек и позволяют держать все необходимые данные в регистрах ? Счастливый.

AK>> Я всего лишь задал вопрос: почему область SRAM напрямую AK>> недоступна ? GS> А самому подумать и понять - никак не получается? Потому что в GS> системе GS> команд AVR арифметические и логические команды имеют в качестве GS> аргументов GS> только жалкие 32 РОH. Для выполнения арифметических и логических GS> команд GS> над данными в SRAM приходится "жонглировать" данными при помощи GS> команд GS> LD и ST. Хоть на этот раз дошло, или снова повторять придётся?

Это не повод назвать архитектуру "уродской".

[бред и оскорбления поскипаны]

Привет!

Mon Jul 19 2004 08:08, Andrew V. Miheev wrote to Alexander Golov:

...

AVM> Так это и замечательно! 8-)

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

Что такое "счётчик тактов в основной программе"? Если основной программе настолько нечем заняться, что она может точно считать свои такты, то куда проще просто обойтись без прерываний.

...

AVM> Пусти второй аппаратный таймер с прескалером 1:1 - он тебе и посчитает AVM> такты...

Это всё прозрачно, но как бы к возможности скомпенсировать задержки в прерываниях имеет мало отношения, а это может иметь самостоятельный интерес, а не только в контексте частотомера.

16-Jul-04 18:37 Alexey V Bugrov wrote to Alexey Boyko:

AB>> Бинарной совместимости - в общем случае нет, она редко нужна. Есть AB>> набор периферии, в разных кристаллах разное подмножество этого набора. AB>> Какая совместимость тебе нужна?

AB> К слову. Атмел блюдет традиции. Тут в ньюсах свалилась инфа, что они AB> снимают AB> AT89C51 и AT89C52 с производства...

Они уже года с два как сказали, что вместо них будут AT89S51 и AT89S52.

wbr,

16-Jul-04 10:37 Alexander Derazhne wrote to Oleksandr Redchuk:

AD>>> хочешь ты этого или нет. Да и Y'ка жа-алко :-). Если быстродействия AD>>> хватает, то OR>> В мелких программах (когда рабта почти столько с портами) - не OR>> жалко отдать указатель на постоянку. В мелких контроллерах -- всё OR>> влезет в одно окно. Потерать немножко быстродействия в работе с IO я OR>> не считаю страшным. Быстро ножками махать должна аппаратура.

AD> Опять таки не соглашусь. Это микроконтроллер или где? Ещё немного, и AD> ему AD> потребуется отдельный сопроцессор ввода-вывода! :-))) Хочется сохранить AD> быстрый в/в с явным указанием порта в коде _однословной_ команды, Адресация со смещением к указательному регистру и так однословная. Вот однотактовая она может и не выйти, надо ведь ещё сложение произвести. Но тем не менее "опять таки не соглашусь". Это ногамимахалка или микроконтроллер? Да просто оно не к IO будет обращаться медленно - аж за 2 такта, как ко внутреннему ОЗУ, а операции в АЛУ быстро делать - всего за 1 такт :-) Это нужно полистать реальный код и посмотреть насколько повлияет

2-тактовость команд IO с учётом окружающего - входа/выхода в прерывания, выборки/занесения данных в ОЗУ, ... Что-то мне кажется, что изменение времени работы обработчика прерывания UART с занесением байта в кольцевой буфер будет ну совершенно незначительным. Даже выдача меандра на ножку :-) вместо 6 тактов станет 8, т.е. удлиннится на треть при удвоении времени работы команд работы с IO.

AD> Но только в косвенно-адресуемом пространстве общей памяти. В командах AD> непосредственной адресации в/в расположение, да и формат регистров AD> должны упаковываться для наиболее эффективного использования алресов. Вот эта упаковка из-за ограниченности адресного пространства и привела к тому, что нет никакой регулярности. Но всё равно не влезло всё для всех AVR и полезли SFR за пределы IO адресов, что привело к ещё большей нерегулярности. И, кстати, установить/сбросить бит на тех регистрах -- это вообще танцы с приседаниями. в 2 такта точно не укладывается. Выигрыш от отдельного IO, IMHO, сомнителен, проигрыш очевиден.

AD> P.S. А что, может действительно, разработать коллективно "идеальную" AD> модель микроконтроллера, да выкатить Атмелу? AD> :-)))) Э, это так вот говорить несложно :-) А подробно проработать - нужно время. И таки 16 регистров или 32? С чего-то же они взяли, что надо 32, и часть проблем - от этого.

wbr,

16-Jul-04 10:37 Alexander Derazhne wrote to Oleksandr Redchuk:

AD> Но только в косвенно-адресуемом пространстве общей памяти. В командах AD> непосредственной адресации в/в расположение, да и формат регистров AD> должны AD> упаковываться для наиболее эффективного использования алресов.

OR>> Сосбтвенно, биты IE и IF *всех* периферийных устройств должны в их CSR OR>> стоять на одинаковых местах :-)

AD> :-))))) Кстати, глянь внимательно на новые меги :-)))))) Включая мега48. Довольно много SFR запихано в только LD/ST доступное пространство, где доступ к ним ну никак не быстрее, чем я предлагаю (собственно, мысль выкинуть IO, добавить 1 указатель возникла при обсуждении с кем-то недостатков AVR году в 98-м :-), а биты управления таймерами "регуляризованы", только вот TIMSK* все сидят в LD/ST, а не в IN/OUT. И с группировкой вопрос - они погруппировали "все маски таймеров", "все флаги таймеров", остальные вообще в других местах. Мне кажется, что надо всё, относящееся к одному таймеру, держать кучно.

AD> P.S. А что, может действительно, разработать коллективно "идеальную" AD> модель микроконтроллера, да выкатить Атмелу? AD> :-)))) Да и поздно уже. AVR уже не исправить, потеряется совместимость, новое выводить на рынок они сами не захотят.

wbr,