AVR vs PIC - Page 11

Do you have a question? Post it now! No Registration Necessary

Threaded View
AVR vs PIC
Wed, 14 Jul 2004 04:08:55 +0000 (UTC) Oleksandr Redchuk wrote to "Harry Zhurov"

[...]

HZ>> (для данных и для адресов возвратов), которые юзает ИАР. GCC использует
HZ>> один стек, но это, имхо, еще хуже (по эффективности кода).
OR>  Как хотя бы слабую моральную компенсацию этого (4) могли бы
OR> хотя бы автоматом запрещать прерывания на 1 такт после команды
OR> out в SPH, тогда на мелких кристаллах без SPH вообще ничего
OR> не поменялось бы, а на более толстых gcc вместо
OR>    in __temp_reg__,sreg
OR>    cli
OR>    out SPH,r29
OR>    out sreg,__temp_reg__
OR>    out SOL,r28

OR> спокойно мог бы делать

OR>    out SPH,r29
OR>    out SPL,r28

    Да, ты уже про это как-то говорил.

OR> Ну а нормальный стек на одной из регистровых пар и никаких идиотских
OR> SPH/SPL это было бы просто счастьем :-)

    О том и речь. :(

HZ>>     [5] Неполноценный указатель X (r26:r27). Отсутствие у него режимов
HZ>> адресации со смещением порождает порой геморройный код. Особенно это
HZ>> заметно на
HZ>> ИАР 2.27(2.28). В 3.хх сделали уже лучше, но все равно кривизны это не
HZ>> убавляет.


HZ>>     [6] Несбалансированный регистровый файл. ИМХО, вместо 32 регистров
HZ>> лучше бы
HZ>> было их 16, но чтобы они при этом были полностью симметричными
HZ>> (позволяющими работу с любыми командами) и чтобы любая регистровая пара
HZ>> могла быть указателем, а не только старшие три. И, как уже говорилось,
HZ>> чтобы одна из регистровых пар была указателем стека.
OR>  Эти два пункта взаимосвязаны. 32 регистра сожрали 10 бит в КОП-ах
OR> 2-адресных команд и 5 бит в кодах одноадресных команд, из-за чего
OR> стало тесно и не хватает кодов ни для нормального X, ни для большего
OR> количества регисторвых пар.
OR> Кстати, вполне возможно, что и для 16 регистров не хватило бы кодов для
OR> того, чтобы они все могли быть парами. Но вот старшие 8 из них чтобы
OR> были парами, одинаковыми по методам адресации, да чтобы самые старшие были
OR> указателем стека -- это точно хватило бы.
OR> Я не уверен, что 7 указателей (кроме SP) прямо так нужны. Полная симметрия
OR> это "красиво", но вот экономично ли? А вот SP с адресацией
OR> смещением и к этому ещё три "нормальных" пары - это IMHO было
OR> бы достаточно. Это было бы в два раза лучше, чем сейчас (у IAR - один
OR> SP на Y и ещё Z, X практически не в счёт). А освободившиеся коды
OR> лучше отправить на загрузку/выгрузку по указателю регистровых
OR> пар и т.п.

    Я полностью согласен с тобой, что если нет возможности сделать все
симметричным, то и не надо - надо чтобы было достаточное количество
_полноценных_ указателей. 4 пары - это достаточно: указатель стека и три под
данные (два операнда источника и один назначения; или еще когда под this один
указатель юзается). Если при этом еще и есть команды
пересылки/сложения/вычитания пар, то это вообще рулез... :-\

[...]

OR> А то, что малость работа с портами удлиннилась бы и частота
OR> лапкоймахания упала бы -- так это по большому счёту фигня :-)
OR> Зато уж про битовые флаги претензии пропали бы
OR> (сейчас где-то раздаётся восторжённое АГГААА!!! :-)

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

--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: AVR vs PIC
Hello, Oleksandr!
04:08:55 +0000 (UTC):

 HZ>>     [4] Убогий указатель стека. Гораздо лучше было бы, если бы
 HZ>> указатель стека был бы регистровой парой. Тогда не было бы
 HZ>> необходимости в раздельных стеках (для данных и для адресов
 HZ>> возвратов), которые юзает ИАР. GCC использует один стек, но это,
 HZ>> имхо, еще хуже (по эффективности кода).
 OR>  Как хотя бы слабую моральную компенсацию этого (4) могли бы хотя бы
 OR> автоматом запрещать прерывания на 1 такт после команды out в SPH,
 OR> тогда на мелких кристаллах без SPH вообще ничего не поменялось бы, а
 OR> на более толстых gcc вместо    in __temp_reg__,sreg    cli    out
 OR> SPH,r29    out sreg,__temp_reg__
 OR>    out SOL,r28

 OR> спокойно мог бы делать

 OR>    out SPH,r29    out SPL,r28

 OR> Ну а нормальный стек на одной из регистровых пар и никаких идиотских
 OR> SPH/SPL это было бы просто счастьем :-)

    А часто ли приходится переставлять указатель стека? Даже если играться в
какие-то многозадачки, то смена контекста будет происходить при запрещённых
прерываниях и там ещё много игр будет. Если речь идёт о восстановлении
стекового фрейма, то, скорее, нужна ret <n>; addw sp, <n>; или mov sp, bp
:-)).

[...]
 OR> На эту же тему [8]
 OR> Аназачем они сделали это идиотское пространство ввода-вывода?
 OR> in/out им захотелось? Как я уже говорил, "если ядро AVR
 OR> разрабатывали и программисты, то программисты на визуалбейсике, а не
 OR> на С".
 OR> Целых 6 бит в КОП-ах под номер порта! И всё равно портов не хватило,
 OR> ещё во время появления меги 103 было ясно, что SFR скоро не влезут в
 OR> 64 байта.
 OR> Итого у меги128 вместо того, чтобы иметь два одинаковых UART и
 OR> иметь возможность работать с ними обеими одним кодом через указатель
 OR> на начало их регистров - имеем какую-то такое...
 OR> Вместо этого надо было бы сделать (не инкремент памяти, нет, это не
 OR> надо)
 OR> возможность только с одним методом адресации, а именно (ptr+disp)
 OR> установить/сбросить/проверить бит. Это то, что сейчас можно сделать
 OR> с SFR кроме in/out, заменяемых на ld/st.
 OR>   in r0,port10   =>  ld    r0,Y+10   out port11,r1  =>  st
 OR> Y+11,r1   sbi port12,3   =>  bset  Y+12,3   cbi port13,4   =>  bclr
 OR> Y+13,4   sbis port14,5  =>  skpbs  Y+14,5   sbic port15,6  =>  skpbc
 OR> Y+15,6 хм... ещё две комбинации просятся :-)
 OR> ну тогда btg и  skpbsc (пропуск при установелнном со сбросом :-)
 OR> Перед началом работы с SFR можно было бы прсто загрузить в какую-то
 OR> пару адрес начала нужной области SFR. У мелких типа tiny и младших
 OR> classic хватило бы загрузки только младшего регистра из пары. На них
 OR> при даже всего 4-х парах можно было бы в самом начале программы
 OR> загрузить, скажем, в XL начало области SFR (всех, у мелких их мало)
 OR> и в течении всей программы спокойно работать "в нынешнем стиле" (в
 OR> мелких кристаллах часто вся работа состоит в махании ножками).
 OR>  А в программах с работой с IO в небольшом кол-ве подпрограмм
 OR> загружать указатель адресом зоны SFR только где надо а в остальное
 OR> время использовать его для работы с областью ОЗУ. При этом на
 OR> толстых кристаллах с SFR больше 64 байт особых проблем не возникло
 OR> бы, одновремённо со всеми всё равно работа не идёт.
 OR> А то, что малость работа с портами удлиннилась бы и частота
 OR> лапкоймахания упала бы -- так это по большому счёту фигня :-)
 OR> Зато уж про битовые флаги претензии пропали бы (сейчас где-то
 OR> раздаётся восторжённое АГГААА!!! :-)

    Если ты про меня, то почти угадал :-). Но тут просматривается больше чем
одна проблема. С одной стороны, наличие двух методов доступа к SFR в двух
адресных пространствах с разными возможностями, причём наиболее эффективный
(по возможностям и скорости) метод доступа ограничен размером адресуемой
зоны. С другой стороны - распределение регистров по адресам и битов внутри
регистров ээ... скажем так, не отличается регулярностью. В принципе, можно
было-бы:
    а) унифицировать распределение бит в регистрах для однотипной периферии;
потребовать формального наличия регистров старшего байта у T0 и т.д. (7-ой
бит - готовность, 6-ой - разрешение прерывания... не, ну это уже в перебор
:-))) );
    б) перераспределить регистры по адресам, выделив бит-манипулируемые в
отдельное пространство;
    в) расширить адресацию in/out для охвата, ну, скажем, 512 байт;
    г) в косвенно-адресуемом пространстве (РОН+SFR+ОЗУ) перераспределить
регистры для достижения  регулярности, сгруппировав их не по принципу
бит-доступности, а по принадлежности к тому или иному блоку.

Alexander,Derazhne@adic,kiev,ua (replace commas with dots)
Alexander Derazhne



Re: AVR vs PIC
14-Jul-04 10:26 Alexander Derazhne wrote to Oleksandr Redchuk:

AD>     Если ты про меня, то почти угадал :-). Но тут просматривается больше
AD> чем
AD> одна проблема. С одной стороны, наличие двух методов доступа к SFR в
 Никаких двух методов!
 64-байтовое пространство SFR убрать начисто вместе с командами
in, out, sbi, cbi, sbis, sbic!
 Даёшь *((volatile unsigned short*)0177700) = 0; !

AD>  В принципе, можно было-бы:
AD>     а) унифицировать распределение бит в регистрах для однотипной
AD> периферии;
 О чём и речь.

AD> потребовать формального наличия регистров старшего байта у T0 и т.д.
AD> (7-ой
AD> бит - готовность, 6-ой - разрешение прерывания... не, ну это уже в
AD> перебор
AD> :-))) );
AD>     б) перераспределить регистры по адресам, выделив бит-манипулируемые
AD> в отдельное пространство;
 Не нужно. У мелких и так всё влезет в одну зону на Y, у толстых
всё равно не будет кусков программы, где надо сразу со всей периферией
работать.

AD>     г) в косвенно-адресуемом пространстве (РОН+SFR+ОЗУ) перераспределить
AD> регистры для достижения  регулярности, сгруппировав их не по принципу
AD> бит-доступности, а по принадлежности к тому или иному блоку.
 SFR как отдельное пространство давить. Команды работы с ними зря жрут
пространство кодов.
А группировка вполне нужна, и если бит разрешения прерывания от
любого периферийного узла (пусть TIMER0) и бит флага его прерывания будут не
невесть где рядом с флагами других таймеров, а в его регистрах, то тогда
вся работа с ним гарантированно влезет в одно окно на указателе.
Что-то типа horisontal windowing в 196-ых, только сделанное
через что-то типа их vertical windowing :-)

wbr,
p.s. кстати, насколько я помню, arm gcc в пределах функции несколько
последовательных обращений к регистрам периферии вполне собирает в кучки,
доступные в пределах одного окна, один раз загружает какой-то регистр
адресом начала этого окна и спокойно адресуется смещениями. То же было бы и
тут, просто окно поуже :-)

--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: AVR vs PIC
Hello, Oleksandr!
2004 20:13:57 +0000 (UTC):

 AD>>     Если ты про меня, то почти угадал :-). Но тут просматривается
 AD>> больше чем одна проблема. С одной стороны, наличие двух методов
 AD>> доступа к SFR в
 OR>  Никаких двух методов!
 OR>  64-байтовое пространство SFR убрать начисто вместе с командами in,
 OR> out, sbi, cbi, sbis, sbic!
 OR>  Даёшь *((volatile unsigned short*)0177700) = 0; !

    Искуситель!!!

 AD>> потребовать формального наличия регистров старшего байта у T0 и
 AD>> т.д.
 AD>> (7-ой бит - готовность, 6-ой - разрешение прерывания... не, ну это
 AD>> уже в перебор :-))) );
 AD>>     б) перераспределить регистры по адресам, выделив
 AD>> бит-манипулируемые в отдельное пространство;
 OR>  Не нужно. У мелких и так всё влезет в одну зону на Y, у толстых всё
 OR> равно не будет кусков программы, где надо сразу со всей периферией
 OR> работать.

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

 AD>>     г) в косвенно-адресуемом пространстве (РОН+SFR+ОЗУ)
 AD>> перераспределить регистры для достижения  регулярности,
 AD>> сгруппировав их не по принципу бит-доступности, а по принадлежности
 AD>> к тому или иному блоку.
 OR>  SFR как отдельное пространство давить. Команды работы с ними зря
 OR> жрут пространство кодов.

    Не соглашусь. Придётся всё время играть базовым регистром, хочешь ты
этого или нет. Да и Y'ка жа-алко :-). Если быстродействия хватает, то можно
и так. Можно вообще исключить смещение из команды - а чего, программа сама
не вычислит? in al, dx; и хватит. Но это ведь не те задачи. Полагаю, что
прямой доступ с нужно сохранить. Вертиться тут мыслишка о нескольких (4?)
окнах со своими SFR с очень коротким положительным смещением в пределах окна
и номере окна в адресной части команды. Даже не со смещением, а с младшей
частью адреса, т.е. никаких вычислений адреса. Одно из "окон"
неперемещаемое, некоторые регистры доступны всегда. Можно даже задать
"магическую" базу окна, при которой мапится не просто окно, а самостоятельно
сформированное фюзами. Во!
    Но это не то, о чём я писал в п.г). Там речь идёт как раз о SFR'ах
отмапленных на память.

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

    Да ладно с этими окнами! Зато можно будет написать class Timer и
передавать ему this ! :-)))

Alexander,Derazhne@adic,kiev,ua (replace commas with dots)
Alexander Derazhne



Re: AVR vs PIC
15-Jul-04 10:51 Alexander Derazhne wrote to Oleksandr Redchuk:

OR>>  Даёшь *((volatile unsigned short*)0177700) = 0; !

AD>     Искуситель!!!
 :-)

 OR>> равно не будет кусков программы, где надо сразу со всей периферией
 OR>> работать.

AD>     Дык не хочется отдавать Y под это. И медленней будет - с косвенной-то
AD> адресацией.
 Взамен я полагаю - выйдет сделать *четыре* регистровых пары.
Т.е. заняв одну из них намертво - получим то, что сейчас.

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

AD>     Да ладно с этими окнами! Зато можно будет написать class Timer и
AD> передавать ему this ! :-)))
 И это в том числе. Если таймеры ещё сделать "однотипно"
(ну я там говорил про размещение битов флагов и разрешений прерываний -
вот у всех таймеров то, что у них одинаково -- должно быть на одинаоквых
смещениях от базы и в одинаковых битах!) -- так это будет одно
удовольствие. Сосбтвенно, биты IE и IF *всех* периферийных
устройств должны в их CSR стоять на одинаковых местах :-)

wbr,


--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: AVR vs PIC
Hello, Oleksandr!
2004 22:13:47 +0000 (UTC):

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

    Опять таки не соглашусь. Это микроконтроллер или где? Ещё немного, и ему
потребуется отдельный сопроцессор ввода-вывода! :-))) Хочется сохранить
быстрый в/в с явным указанием порта в коде _однословной_ команды, быстрый
доступ к _нужным_ битам, но к этому _добавить_ возможность косвенной
адресации _регулярным_ способом - как раз то, о чём ты пишешь ниже.
Косвенный доступ, кстати, и так есть (кроме битового).

 AD>>     Да ладно с этими окнами! Зато можно будет написать class Timer
 AD>> и передавать ему this ! :-)))
 OR>  И это в том числе. Если таймеры ещё сделать "однотипно"
 OR> (ну я там говорил про размещение битов флагов и разрешений
 OR> прерываний -
 OR> вот у всех таймеров то, что у них одинаково -- должно быть на
 OR> одинаоквых смещениях от базы и в одинаковых битах!) -- так это будет
 OR> одно удовольствие.

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

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

    :-)))))

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

Alexander,Derazhne@adic,kiev,ua (replace commas with dots)
Alexander Derazhne



Re: AVR vs PIC
Hello, Alexander!
You wrote to Oleksandr Redchuk on Fri, 16 Jul 2004 10:37:14 +0000 (UTC):

Вот, кстати, ещё один грешок. Сел, почитал более внимательно про AVR'овский
АЦП - в дифф.режиме длительность преобразования 13 тире 14 тактов. Что,
вобщем-то, сводит к нулю полезность автозапуска в таком режиме...

With best regards,
Alexander Derazhne



Re: AVR vs PIC
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,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: AVR vs PIC
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,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: AVR vs PIC
Hello, Oleksandr!
2004 04:28:59 +0000 (UTC):

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

    Ещё может потребоваться переинициализировать регистр. При обработке
прерывания - обязательно, плюс сохранить/восстановить. При вызове функции...
ну, это уже как компилятор выкрутится.

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

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

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

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

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

    Великим Предкам, говорят, 8 (6+2) хватало :-))).

With best regards,
Alexander Derazhne



Re: AVR vs PIC
12-Jul-04 22:26 Alexander Derazhne wrote to Oleksandr Redchuk:

 OR>> Раз.

 OR>> Это я считаю *реальные* недостакти AVR, упомянутые в этом треде :-)
 OR>> Отсутствие приоритетной системы прерываний.
 OR>> Даже у классического MCS51 это сделано лучше.

AD>     Нет совместимости младших и старших моделей по крайней мере в
AD> области
AD> векторов прерываний. Если замена на более старший кристалл идёт по
AD> причине
AD> большей периферии и/или программной памяти, то перекомпиляция неизбежна,
 Это 0.5 недостатка, так как по причине "большей периферии"
перекомпилировать всё равно надо, при переходах
<=8KB flash - 8..64KB - >64KB перекомпилировать всё равно надо.


AD> а
AD> совместимость не требуется. Если же необходим больший объём ОЗУ (в моём
AD> случае мега16 возможно будет заменена на мегу32 именно по этой причине),
AD> то...
 Всё равно надо передвинуть инициализацию стека или переразместить
переменные, чтобы это увеличение учесть - перекомпиляция.

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

AD>     Пойдёт в качестве "два, три"?
 0.5+1.5 = 2, пойдёт :-)

wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: AVR vs PIC
Hello, Oleksandr!
17:32:03 +0000 (UTC):


 AD>>     Нет совместимости младших и старших моделей по крайней мере в
 AD>> области векторов прерываний. Если замена на более старший кристалл
 AD>> идёт по причине большей периферии и/или программной памяти, то
 AD>> перекомпиляция неизбежна,
 OR>  Это 0.5 недостатка, так как по причине "большей периферии"
 OR> перекомпилировать всё равно надо, при переходах <=8KB flash -
 OR> 8..64KB - >64KB перекомпилировать всё равно надо.

 AD>> а совместимость не требуется. Если же необходим больший объём ОЗУ
 AD>> (в моём случае мега16 возможно будет заменена на мегу32 именно по
 AD>> этой причине), то...
 OR>  Всё равно надо передвинуть инициализацию стека или переразместить
 OR> переменные, чтобы это увеличение учесть - перекомпиляция.

    Не обязательно. Строго говоря я не проверял, но _вероятно_ можно
прогнать тест памяти и выяснить объём. Хотя может и не получится - кто
знает, как чип отнесётся к обращению за пределы имеющихся адресов. Я пытался
разместить стек в РОНах (гы!), процессор просто улетает в неизвестном
направлении при попытке сделать call.
    Стек, кстати, можно разместить и внизу, хотя это и не так традиционно.
    Ещё возможна ситуация, когда у тебя есть в наличии мега32 и ты скрипя
зубами пытаешься поставить её вместо отсутствующей в данный момент 16-ой.
    Снятие 16-ой с производства с рекомендацией переходить на 32-ю тоже
исключить нельзя.

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

 OR>  0.5+1.5 = 2, пойдёт :-)

    Ну, тогда вот ещё, но уже на правах "пожелания". Команда "сравнить с
маской и пропустить, если что" :-). В команде должно быть три операнда -
регистр в/в, маска выделяемых бит, маска сравнения. Назначение - отлов
нужной комбинации (маска сравнения) нужных бит(маска выделения).
    Но это я уже наглею :-)).

With best regards,
Alexander Derazhne



Re: AVR vs PIC
GS>  Таймеры заняты _другой_ полезной работой. И может потребоваться
выдавать
GS> несколько частот (для микроАТС, к примеру, типичны 25 и 425 Гц, в
моей
GS> последней разработке для телефонии ещё 4 кГц выдавалось, плюс ШИМ
GS> от аппаратного таймера - скажи, у тебя есть 3 свободных таймера,

Уж не DTMF ли ШИМом генерил? У меня на 2х ножках и 2х таймерах
получилось.

Я что-то подобное твоей задаче вначале сделал на 877м. Потом перешел на
18е - и вздохнул с облегчением. Попробуй - понравится ;-)

 --
Rifkat < Team /Grave\ >
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Re: AVR vs PIC

   Artem, ты ещё здесь сидишь?


Пятница Июль 09 2004 11:18, Artem Kamburov wrote to George Shepelev:


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

 И какие данные ты с него получишь? Отфонарные? ;)

 AK> А за весь период таймера 5 команд выполнить как-то успею.

 По дороге потеряв перенос в старший байт? Успеешь ;)


 >> И в любом случае аппаратный таймер в PIC работает на гораздо
 >> больших частотах, чем может отрабатывать AVR...
 AK> Hе таймер, а асинхронный предделитель.

 Что ты говоришь? Открываешь доку, к примеру, на PIC12F629 и _внимательно_
изучаешь структуру модуля Timer1. В режиме, когда 16-ти битный таймер
подключен через прескалер с коэффициентом деления 1.

 AK> В Tiny26-й таймер штатно работает на 70МГц...

 Hе знаю насчёт 70МГц, где-то в середине доки от Atmel смутно упоминается
64 МГц. В любом случае таймер в Tiny 8-ми битный, так что тебе предстоит
интересное занятие по корректному учёту переносов в старший байт программно
эмулируемой части таймера...


 >>  AK>>> Еще раз для непонятливых - Idle режима у 630-го просто нет. И
 >>  AK>>> нечего сравнивать Idle у ATtiny26 с Power-down (он же SLEEP)
 >>  AK>>> у 630!
 >>  GS>> Hа рекламный слоган ведёшься? Ламерствуешь? Снова нужно в
 >>  GS>> документацию носом тыкать? Что такое Idle в ATtiny? CPU
 >>  GS>> выключается и ждёт прерывания.
 AK> Еще раз - в Idle работает все кроме ЦПУ, в т.ч. и основной генератор.

 У PIC тоже работает всё, кроме ядра. Тебя смущает, что генератор имеет
номер 1, а не 0? ;-)

 >>  AB> Точно. CPU выключается, но тактовый генератор и вся периферия
 >>  AB> продолжает работать.
 >> И кто не даёт гонять в таком режиме PIC?
 AK> Ты :).

 С какой стати? Hормальный режим, в котором при желании можно запустить
PIC-контроллер...

 >> Hежелание документацию
 >> поглядеть?
 AK> У PIC16 прерывание от таймера работающего не от отдельного кварца
 AK> выведет чип из SLEEP-а? ТЫ в этом уверен? 8)

 Абсолютно уверен. Этот таймер зовётся WDT. Отправляйся читать доку
или плати денежку за чтение документации вслух ;)


 >>  AB> Для нормально написанной программы под AVR - Idle - основной
 >>  AB> режим работы.
 >> Это зависит от конкретной работы. Попробуй в таком режиме DTMF
 >> формировать ;)
 AK> А сложнее задачу предложить не мог ;-?

 У меня это сейчас _типичная_ задача. Телефония.

 AK> Готовишь данные для первой точки, запускаешь ШИМ и засыпаешь. По
 AK> прерыванию компара готовишь данные для следующей точки (таймер в это
 AK> время продолжает работать) и засыпаешь. И так до конца формирования...
 AK> Даже дергать ногой не надо.

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


                                                   Георгий


Re: AVR vs PIC
10-Jul-04 14:57 George Shepelev wrote to Artem Kamburov:

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

GS>  И какие данные ты с него получишь? Отфонарные? ;)
 ТОЧНО такие же, как на любом 8-битном процессоре от 16-битного таймера
без защёлки для "неразрывного чтения". Да, в AVR эта защёлка "отродясь"
есть, в MCS51 её нет, в pic16 раньше не было, сейчас не знаю есть ли.
Так что чтение 16-битного таймера в два приёма и чтение 8-битного
таймера + байта программного расширения не отличаются ничем,

AK>> А за весь период таймера 5 команд выполнить как-то успею.
GS>  По дороге потеряв перенос в старший байт? Успеешь ;)
 5 команд надо как раз для того, чтобы НЕ потерять:

MCS51, 16-битный аппаратный таймер (напоминаю, с точки зрения
чтения без остановки ничем не отличается от чтения аппаратного 8-битного
таймера и 8-битного программного расширения).

GetPulseCounter:           ;;;;;;;;;;;
; u16 GetPulseCounter(void);
L?L:
      mov   a, T1H
      mov   R7,T1L
    cjne a,T1H,L?L
    mov  R6,a
  ret

AVR, 8-битный таймер и байт программного расширения
GetTimer:
     lds  r0,t0high
     in   r24,TCNT0
     lds  r25,t0high
     cpse r0,r25
      in  r24,TCNT0
  ret


Quoted text here. Click to load it
AK>> Hе таймер, а асинхронный предделитель.

GS>  Что ты говоришь? Открываешь доку, к примеру, на PIC12F629 и _внимательно_
GS> изучаешь структуру модуля Timer1. В режиме, когда 16-ти битный таймер
GS> подключен через прескалер с коэффициентом деления 1.
В синхронном режиме без прескалера период минимум Tcy+40нс = 4Tosc+40нс.
У AVR это будет 2Tosc+что-то-там, но у AVR частоты кварца ниже "в среднем",
так что приблизительно одинаково.
В асинхронном режиме без прескалера период минимум 60нс (с прескалером -
20нс). 60нс это под 17MHz, таймеры в AVR работают только в синхронном
(а асинхронные - вход заточен под кварц 32кГц, импульсы подавать
не выйдет), так что тут проигрыш.

Касательно частотомеров. Если ограничить отсутстивем внешних делителей,
то грубо на AVR @16MHz можно сделать частотомер до эдак 7MHz, на PIC16 -
до 50-70. С одной стороны - громадный выигрыш. С другой - диапазон
7..70МГц это узкая ниша даже с точки зрения 0..200Мгц.
Тем, кто занимается звуком или источниками питания - за глаза хватит и
AVR-овского диапазона. Тем, кто копается в цифре - может понадобиться и 200,
ну уж 50-70 точно мало. Кто занимается связью - так там всякое может быть.

Мне так вообще за последние несколько лет частотомер крепко понадобился
(осциллографа не хватило :-) только один раз и там надо было померять
отношение частот. При периоде меньшей частоты в окрестности пары
десятков микросекунд, заполнение - 90, 100MHz. Можно, конечно, кроме
внешнего доделивателя ещё схемку на триггере/логике перед пиком
прислонить, а смысл?
Итог - пик без внешнего предделителя хорош только в КВ диапазоне.
А внешний - уж лучше мелкую PLD-ку (а то и FPGA-ку) взять
и сделать все основные режимы приличного частотомера (а то и генератор
многоканальный туда же запихать). А перед при необходимости ставить
го