AVR vs PIC

9-Jul-04 19:56 Alexander Torres wrote to Yuriy K:

YK>> Hу раз уж ты настаиваешь... YK>>

YK>> loop; YK>> eor r17, r16 ;1 YK>> out port, r17 ;1 YK>> rjmp loop ;2 YK>>

YK>> 2МГц @ 8МГц, 4МГц @ 16МГц. Уже "согласовано", что в два раза ниже.

AT> Что-то сомневаюсь, по тактам получается ьбольше чем в моем примере с AT> ПИКом, а частота вдруг выше, откуда бы это?

AT> напомню что мой пример содержал 3 такта: AT> L1: xorwf PORTA,f ; 1 AT> goto L1 ; 2

AT> при 4мгц тактовой, т.е. при 1мгц процессорной, период 6 тактов - т.е. AT> 166кгц, 180кгц было при тактовой чуть выше чем 4.

О! Как сравнивать пики с классическим mcs51, так "у того 12, а у этого 4", а как тут, так "т.е. при 1MHz процессорной" :-)

При 4МГц тактовой у AVR будет 4/8 = 500кГц. У MSP430 -- 4/12 = 333кГц.

При 1МГц тактовой у AVR - да, 125кГц, < 166кГц, А у msp430 вообще 83.3кГц.

Однако вопрос был не "а с какой частотой сможет махать ногой при 1МГц тактирования ядра".

А теперь возьмём, и сформируем два сдвинутых меандра на двух ножках.

; pic16 loop: mowlv mask1 ; 1 xorwf PORTA,f ; 1 ; goto $+1 ;; 2 mowlv mask2 ; 1 xorwf PORTA,f ; 1 goto loop ; 2

12 или 16 циклов (48 или 64 такта) в зависимости от необходимости центровки, 83,3 или 62.5 кГц при 4МГц осцилляторе, при 1 МГц ядра.

; AVR loop: eor r16,r17 ; 1 out port,r16 ; 1 ; rjmp $+2 ;; 2 eor r16,r18 ; 1 out port,r16 ; 1 rjmp loop ; 2

12 или 16 циклов, 83,3 или 62.5 кГц при 1 МГц osc, 333 или 250 кГц при 4МГц osc.

; MSP430 loop: xor.b R4, port ; 4 ; jmp $+2 ; 2 xor.b R5, port ; 4 jmp loop ; 2

20 или 24 цикла, 50 или 41.6 кГц при 1 МГц osc, 200 или 166 кГц при 4МГц osc.

Т.е. при том же *осцилляторе* AVR и MSP430 далеко впереди, при той же частоте ядра MSP проигрывает, а AVR строго вровень.

Ну а при сравнении частоты ядра хит сезона - классический или 6-тактовый MCS51 :-) loop: cpl P2.3 ; 1 ; sjmp $+2 ;; 2 cpl P2.4 ; 1 sjmp loop ; 2

8 или 12 циклов, 125 или 83.3 кГц при 1 МГц ядра, меньше циклов, чем у пика :-) А на loop: cpl P2.3 ; 1 sjmp loop ; 2 строго вровень с пиком.

p.s. Кстати, была у меня задачка, где 16-мегагерцовый i87c51FA уделывал бы 20-мегагерцовый pic16, хоть у того частота циклов была бы 3.75 раза больше. Всего ничего - прочитать из буфера (страница 32КБ в xram) изображение, сжать в 2 раза (несколько сложений-вычитаний таблицы в ПЗУ, нелинейное переквантование разностей яркостей соседних

8-битных пикселов в 4-битные отсчёты) и опять записать наружу. Потом наоборот. Что эмулировать внешнюю шину (там всё равно была альтерина EPF8282, я уже и на использование PSP смотрел :-) - всё равно долго), что по таблицам шарить... Считал такты, считал... И поставил pic16с64 i2c слейвом на i87c51FA -- контроллером дежурного (микропотребляющего) режима и на всякие служебные функции при работе. Там ему было самое место. Так кого и на каких задачах будем сравнивать?

Привет!

Fri Jul 09 2004 11:18, Artem Kamburov wrote to Alexander Golov:

...

AK> Э... Это то PIC18F2331, который на сайте Микрочип указан в цене 5,2$ ? AK> Если да, то "дешевле, быстрее, компактнее" слегка не понял...

Ты прочитай ещё раз то что было написано раньше: PIC18F2331 сделал ненужным внешний АЦП от AD, который стоил столько же сколько 2331 (вот и "дешевле", хотя мне эта дешевизна по барабану в устройстве с себестоимостью в пару тыс. долл.), исчезла необходимость считывания с этого АЦП данных по SPI, а встроенный АЦП имеет FIFO (вот и быстрее, а с учётом повышения частоты выборок до 200 кГц и снижения частоты прерываний до 50 кГц ещё и с меньшей нагрузкой на ядро), ненужность внешнего АЦП и встроенная логика мультиплексирования каналов позволили удалить из устройства одну плату (вот и компактнее).

AK> М-да... Когда все изделие обязано вместиться в себестоимость 10-20$ и AK> функционально превосходить большинство (или все) изделий данного класса AK> цена точно имеет значение.

А когда всё устройство должно вместиться в 20 см3 и работать при ускорениях в

20 тыс. "же", то возникают другие требования, не правда ли? Так что сначала определяем требования, а потом под них реализацию. При требовании к предельной экономии на PIC18 смотреть не нужно (для этого есть PIC16) на ATmega48 можно.

10-Jul-04 14:57 George Shepelev wrote to Artem Kamburov:

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

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-ку) взять и сделать все основные режимы приличного частотомера (а то и генератор многоканальный туда же запихать). А перед при необходимости ставить головку на каком-нибудь гигагерцовом прескалере. И тогда пофигу какой процессор.

10-Jul-04 14:59 George Shepelev wrote to Alexey Boyko:

AB>> Однако, именно при косвнной адресации линейность памяти востребована AB>> больше всего. Посмотри карту памяти AVR-а.

GS> Давно смотрел. Регистры X, Y, Z состоят из пары 8-ми битных регистров, GS> поэтому если модификация адреса идёт не "подряд" - с линейностью начинаются GS> конкретные проблемы... А, ну да. При малом шаге надо знать про команду adiw r28,const а при большом/переменном вообще тихий ужас add r28, r16 adc r29, r17 просто одуревающие проблемы с линейностью, особенно по сравнению с пиком movfw step addwf FSR,f movlw $20 skpnc addwf FSR,f После чего вспомнить, что выше двухкомандный пример для AVR допускает шаг больше, чем 255, а эти 5 команд для pic и шаг <=255, и IRP не обслуживется, т.е. переход только между банками 0,1 или 2,3, переход между 1,2 или вообще неизвестно пока какой -- будет ещё длиннее. Кто там и что по поводу дутых мипсов говорил? На всякий случай напоминаю - про проблемы при модификации не подряд начал говорить ты.

AB>> А у АВР - бывает и больше. Можно 64К внешнего ОЗУ подключить. AB>> Код не изменится.

GS> Ты с x51 не путаешь? ;-) Нет, конечно. У меня спокойно на 90s8515 висело 32KB SRAM в адресах

0x8000-0xFFFF и ещё под этим окно для доступа к внутренностям альтеры.

GS> Там это было можно, вот только для доступа GS> к внешней памяти использовались _особые_ команды... А у AVR - не нужно. Во внешнюю память даже стек можно затолкать, если скорость не волнует (доступ к внешнему ОЗУ на такт дольше).

AB>> Разве один из операндов не должен быть регистр W? 2Алексей W - это не аккумулятор! Это временный рабочий регистр АЛУ, к которому есть доступ на уровне команд. У пиков просто несколько другая архитектура, попытка рассматривать W как аккумулятор, особенно после i8080/i51 - сильно мешает :-)

AB>> Это же какое "жонглирование" получается через единственной регистр! Тут ты не прав. Некоторое жонглирование начинается при многобайтной арифметике, особенно из-за отсутствия у пик16 сложения/вычитания с переносом, а все одноадресные команды: GS> _Все_ битовые команды работают не используя регистр W. Сдвиги и обмен GS> нибблами, инверсия - тоже (хотя можно результат помещать в W, это вообще GS> уникальная особенность PIC'овской системы команд). Инеременты/декременты, GS> включая те, что с условным выполнением - тоже не используют регистр W.

GS> При использовании AVR все эти действия почти наверняка будут сопряжены GS> с "жонглированием". А при использовании pic16 начинается бег с препятствиями, когда нужен доступ попеременно к port/tris, к находящимся в разных банках SFR, при обращении к коду в другой странице, при чтении таблиц, при работе с двумя массивами. У pic18 много поправили.

AB>> А если наоборот? ;)

GS> Смысл? Программировать AVR на ассемблере крайне неудобно, причины я уже GS> излагал. Программирование на сях для PIC не блещет оптимальностью кода. На PIC на асе писать - одно удовольствие. Пока всё влазит в один банк и в одну страницу. А потом начинаются просто другие трудности. Поработавшему раньше с другой load/store архитектурой - в AVR нет ничего особо неудобного.

p.s. Повторяю - кривизна AVR не там, где ты её показываешь, преимущества "14-битных" пиков, мне кажется, тоже.