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 -- контроллером дежурного (микропотребляющего) режима и на всякие служебные функции при работе. Там ему было самое место. Так кого и на каких задачах будем сравнивать?
Didn't find your answer? Ask the community — no account required.
bit 6-3 T3CCP2:T3CCP1: Timer3 and Timer1 to CCPx Enable bits
1x = Timer3 is the clock source for compare/capture CCP modules
01 = Timer3 is the clock source for compare/capture of CCP2, Timer1 is the clock source for compare/capture of CCP1
00 = Timer1 is the clock source for compare/capture CCP modules
WBR, AVB
A
Alexey V Bugrov
Hi Alexey, hope you are having a nice day!
10 éÀÌ 04, Alexey Boyko wrote to Alexander Torres:
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 можно.
Y
Yuriy K
Sun Jul 11 2004 07:20, Dima Orlov wrote to Alexey Boyko:
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-битных" пиков, мне кажется, тоже.