AVR vs PIC

Привет!

Mon Jul 12 2004 10:29, Harry Zhurov wrote to Alexander Golov:

...

OR>>> А потом - суммирования массивов в третий массив для pic18 (два OR>>> указателя) и AVR.

AG>> Здесь что-то я не понял, почему для PIC18 только 2 указателя? Hа PIC18:

AG>> label movf postinc0,w ; 1 \ AG>> addwf postinc1,w ; 1 | AG>> movwf postinc2 ; 1 | 6 AG>> decf cnt+0,f ; 1 | AG>> bnz label ; 2/1 / AG>> decf cnt+1,f ; 1 \ AG>> bra label ; 2/1 / 3

AG>> Hа AVR (если я, конечно что-то не упускаю в смысле убыстрения):

AG>> label ld r10,x+ ; 2 \ AG>> ld r11,y+ ; 2 | AG>> add r10,r11 ; 1 | 10 AG>> st z+,r10 ; 2 | AG>> dec r12 ; 1 | AG>> brne label ; 2/1 / AG>> dec r13 ; 1 \ AG>> brne label ; 2/1 / 3

HZ> label ld r10,x+ ; 2 HZ> ld r11,y+ ; 2 HZ> add r10,r11 ; 1 HZ> st z+,r10 ; 2 HZ> subi r30,low(...) ; 1 HZ> sbci r30,high(...) ; 1 HZ> brne label ; 2/1

А смысл? Это конечно коротче, но ведь цикл станет на 1 такт длиннее.

Привет!

Mon Jul 12 2004 09:50, Artem Kamburov wrote to George Shepelev:

...

AK> Да нет. Просто не вспоминаю самое больное место ПИК-ов - систему AK> прерываний.

Что-то я не помню, чтобы в PIC16 это когда-то "болело". А по сравнению с PIC18 AVR вообще выглядит слабо: нет высокоприоритетного прерывания (пожалуй это единственное чего по настоящему не хватало в PIC16), много времени уходит на вход/выход.

AK> Да и про табличные операции в PIC16 еще не вспоминал.

Команда "retlw" в PIC16 решает свои задачи вполне эффективно, да и нет нужды в другом варианте при 14-разрядной программной памяти. Кстати, я и на PIC18 подчас "retlw" пользуюсь, как и табличными переходами на список из "bra".

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

AB>> ... фу, какие заморочки. В AVR этого нет. GS> Да, в AVR с этим гораздо хуже. БОльшая часть SRAM и все порты GS> напрямую недоступны.

Чего ??? Ты хоть знаешь о чем говоришь ? Прочти хотя бы даташиты, коли уж говоришь о том, с чем на практике не встречался.

GS> Остаётся радоваться, что "если у вас нет собаки - её не отравит GS> сосед..." ;)

Привет!

Sat Jul 10 2004 18:29, Oleksandr Redchuk wrote to Alexander Torres:

...

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

OR> ; pic16 OR> loop: OR> mowlv mask1 ; 1 OR> xorwf PORTA,f ; 1 OR> ; goto $+1 ;; 2 OR> mowlv mask2 ; 1 OR> xorwf PORTA,f ; 1 OR> goto loop ; 2 OR> 12 или 16 циклов (48 или 64 такта) в зависимости от необходимости OR> центровки, 83,3 или 62.5 кГц при 4МГц осцилляторе, при 1 МГц ядра.

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

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

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

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

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

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

OR> 8 или 12 циклов, 125 или 83.3 кГц при 1 МГц ядра, меньше циклов, OR> чем у пика :-) А на

Точно такой же "хит" даёт и PIC18:

loop btg porta,0 ; 1 bra $+2 ; 2 btg porta,1 ; 1 bra loop ; 2

Привет!

Mon Jul 12 2004 14:39, Alexey Boyko wrote to George Shepelev:

...

AB>>> Я на PIC18 мануал скачал. GS>> Умница. Изучай.

AB> Пока что, кроме возможности прицепить два Input Capture на один AB> таймер ничего превосходного не нашел. Hо лучше уж я msp430 возьму.

Это было в самом старом PIC16C73, а в PIC18 как раз появилась возможность использовать разные таймеры.

11-Jul-04 21:12 Alexander Golov wrote to Oleksandr Redchuk:

OR>> Как-то странно у тебя защита пиков выходит. OR>> "а у пиков доступна вся память!"... Если у пиков и есть преимущества, OR>> то не там ты их показываешь. *Как* доступна? Поячеечно OR>> или мелкими кусками. OR>> А я в 90s8515 запросто сделал 259-байтный непрерывный буфер OR>> (тип+длина+до 255 данных+crc16) для принимаемых пакетов.

AG> На Саш, всё таки Microchip на данный момент довольно чётко разграничивает AG> применимость соответствующих PIC'ов. PIC16 -- для жёсткой экономии. AG> Хочешь AG> сэкономить -- помучайся с кодом. В них особенно и не поворочаешь буферами AG> в 260 байтов и строки не посравниваешь -- памяти кот наплакал. _Я_ это понимаю. Но человек хвалит именно пик16 именно за *свободную* работу со *всей* памятью. Ну пусть будет не 259-байтовый буфер, пусть даже не 128-байтовый. Лишь бы больше 96 :-)

AG> Нужна большая AG> память -- бери PIC18, для них указанных проблем просто нет. Тут одня задачка с год (а то и два уже) назад вылазила. Заглохла, правда, так две игральных платки под столом и валяются). Потребление процессора весит немного - режим работы непрерывный, постоянно есть индикация на 7-сегментном светодиодном. Быстродействие в широких пределах по барабану - т.е. pic18 я бы поставил, вероятно, с тем же кварцем (3.6864), что и AVR или MSP. Точнее, учитывая PLL - точно на том же :-). По ногам нужно было 64-ногий корпус. 32Kбайт флеш 1Kб ОЗУ хватило бы, 60..64Кбайт/2Кбайт неплохо бы про запас иметь,

128Кбайт/4Кбайт явный перебор. Таймера -- хватило бы 4 out comp на 16 бит и ещё одного хоть 8-битного счётчика внешних импульсов. Желательны два UART и SPI одновремённо, но один из UART медленный (2400), можно на compare сделать (+1 к тем 4). АЦП 10 бит, хоть и 100мксек. ATmega64 тогда почему-то нельзя было купить, ATmega128 - перебор по цене. Решил "за счёт заказчика" поработать с чем-то ещё :-) Точных цен не помню, но по сравнению с соответствующими pic18 MSP430F149 и F147 оказались ощутимо дешевле. При этом цены запрашивались у местной Гаммы (у ещё какого-то перепродавца как обычно было дороже) и у местного Пульсара (при том, что MSP потом нашли дешевле). Сейчас я бы не глядя поставил ATmega64 - ещё дешевле. Ситуация действительно странная, но тут и пики16 не блещут малой ценой, а соответствующеи по flash/ram пик18 явно дороже Atmega32 и Atmega64. Да, если интересно. Во время выбора компилировался "тестовый пример" (кусок кода, выдернутый из другого проекта). IAR/AVR 1.40 (другого под рукой не было) -s9 13189 байт -z9 11486 AVRGCC -O2 14306 байт MSPGCC -O2 11608 MCC18 -scs 13986 -sco 14000

AG> Хочешь быстро считать -- появились dsPIC30 -- они намного быстрее AG> самого быстрого AVR'а. Кстати, что у них с инструментарием?

OR>> А потом - суммирования массивов в третий массив для pic18 (два OR>> указателя) и AVR.

AG> Здесь что-то я не понял, почему для PIC18 только 2 указателя? На PIC18: Почему-то у меня в памяти сидит "о, классно, в пик18 уже два указателя" :-) Ну значит я что-то недочитал и/или забыл.

AG> На AVR (если я, конечно что-то не упускаю в смысле убыстрения):

AG> label ld r10,x+ ; 2 \ AG> ld r11,y+ ; 2 | AG> add r10,r11 ; 1 | 10 AG> st z+,r10 ; 2 | AG> dec r12 ; 1 | AG> brne label ; 2/1 / AG> dec r13 ; 1 \ AG> brne label ; 2/1 / 3 Можно счётчик поместить в пару, которая, к сожалению, не указатель, но adiw/sbiw с ними работают. sbiw r24,1 ; 2 brne label ; 2

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

AG> Вот с этим однозначно согласен. Дык!

Wbr,

12-Jul-04 08:21 Alexander Golov wrote to Artem Kamburov:

AK>> Да нет. Просто не вспоминаю самое больное место ПИК-ов - систему AK>> прерываний.

AG> Что-то я не помню, чтобы в PIC16 это когда-то "болело". А по сравнению с AG> PIC18 AG> AVR вообще выглядит слабо: нет высокоприоритетного прерывания (пожалуй

Раз.

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

wbr,