AVR vs PIC

Привет!

Tue Jul 13 2004 00:24, Oleksandr Redchuk wrote to "Alexander Golov":

...

OR> Тут одня задачка с год (а то и два уже) назад вылазила. Заглохла, OR> правда, так две игральных платки под столом и валяются). Потребление OR> процессора весит немного - режим работы непрерывный, постоянно есть OR> индикация на 7-сегментном светодиодном. Быстродействие в широких OR> пределах по барабану - т.е. pic18 я бы поставил, вероятно, с тем же OR> кварцем (3.6864), что и AVR или MSP.

...

OR> Точных цен не помню, но по сравнению с соответствующими pic18 OR> MSP430F149 и F147 оказались ощутимо дешевле. При этом цены запрашивались OR> у местной Гаммы (у ещё какого-то перепродавца как обычно было дороже) OR> и у местного Пульсара (при том, что MSP потом нашли дешевле). Сейчас я OR> бы не глядя поставил ATmega64 - ещё дешевле.

Тут спорить не о чем, если фактор цены важен то его необходимо учитывать. Изначально же разговор начался что де легко/никак можно заменить PIC на AVR. Ну нет этого.

Я уже несколько раз брался за устройства с экстремальными требованиями к аппаратуре и рассматривал всё, до чего реально могу дотянуться (от AVR и MSP, до TMS320) и каждый раз мне в последний момент Microchip подкидывает новое решение полностью меня удовлетворяющее. Вот хотел с повысить частоту АЦ преобразования со 100 кГц до 200 и подумал это сделать с помощью dSPIC30. Куда там... Т.е. АЦ-преобразование он сделать может даже быстрее и данные буферировать, скомпоновать тоже, но вот передать... У него UART тактуется от ядра, что при 120 МГц оказывается медленнее чем у PIC18 при 40, да и потребление... ATmega88 на 20 МГц может обеспечить 2,5 Мбит/с (правда при 8 тактовом бите), но АЦП то подходящего на борту нет, а по SPI -- медленно (100 KSPS ещё получалось, но 200 уже перебор). TMS320LF2401 обеспечивает нужную производительность, частоту выборок, но UART опять тактуется 40 МГц, а жрёт он при этом (прибор то батарейный)!

А тут Microchip подкидывает просто идеально подходящий PIC18F2331... И как он быстро позволяет перекидывать в буфер группу из 4-х отсчётов при всего 50 кГц прерываний и сам каналы перебирает... И вот только что подобное получилось с PIC18F2610. Я начал упираться в объёмы памяти на PIC18F252 (а мне всё таки идеально подходит именно МК в корпусе DIP и 28 выводов у меня не все задействованы), хоть на монстра 64-ногого меняй и -- привет ICSP в полевых условиях), тут столько бонусов сразу. Конечно эмоции только положительные.

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

...

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

OR> Кстати, что у них с инструментарием?

Да вроде нормально, хотя я лично ещё не пробовал (задач пока нет). Микрочиповские: асм, си, эмуляционные головы правда только для ICE4000. PRO MATE II их поддерживает (PM3 естественно тоже), PICSTART -- нет. Hi-Tech выпустила компилятор dsPICC. Может ещё кто, я просто особенно не приглядывался.

...

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

OR> Можно счётчик поместить в пару, которая, к сожалению, не указатель, OR> но adiw/sbiw с ними работают. OR> sbiw r24,1 ; 2 OR> brne label ; 2

Просто это всё таки медленнее и нивелирует 1-цикловое преимущество AVR при суммировании на двух указателях.

12-Jul-04 09:52 George Shepelev wrote to Oleksandr Redchuk:

AK>>>> Ты че - таймер-то продолжает считать (его никто не сбрасывает, AK>>>> не перезаписывает и не тормозит). _____________!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

GS>>> И какие данные ты с него получишь? Отфонарные? ;) [...] GS> А нафиг для этого защёлка, если таймер можно _остановить_, а потом GS> читать из него в любом порядке и с любой скоростью? Битик TMR1ON. Вот отфонарные данные получишь ты. Определись сначала, что ты хочешь. То тебе перенос из младшего в старший байт потерять страшно (чего никто не заставляет делать даже не останавливая таймер), то ты готов потерять такты на входе таймера за то время, пока он будет остановлен.

1) Какой же это таймер, если его постоянно останавливают? 2) Если таймер остановить, то и при чтении его+софтового расширения тоже никаких потерь переносов из младшего в старший не будет 3) остановить+снова запустить таймер - это две команды (если ты в пике - то ещё и если ты в нужном банке, иначе больше), где большой выигрыш у кривого решения с остановкой таймера по сравнению с честным чтением без остановки?

OR>> Так что чтение 16-битного таймера в два приёма и чтение OR>> 8-битного таймера + байта программного расширения не отличаются OR>> ничем,

GS> Исключительно для тех, кто правильно работать с контроллерами не умеет GS> ;) Ну покажи мне, неучу, да всем остальным страждущим сокровенных знаний, пример чтения 16-битного таймера и 8-битного с софтовым расширением. Комментарии не обязательны. Я-то думал, что на пике с тем, что доступ к SFR и переменным выглядит одинаково - разницы вообще не будет.

OR>> 5 команд надо как раз для того, чтобы HЕ потерять: OR>> MCS51, GS> Я где-то говорил за 51-е? Или ты сам с собой споришь? Я привёл примеры на двух разных процессорах, у обоих заняло по 5 команд. Я не виноват, что на пике будет больше.

OR>> GetTimer:

GS> Это что, попытка считать "полное" значение таймера в момент завершения GS> временного интервала? Очень хорошо, смотрим: Это чтение текущего состояния таймера без нарушения его хода.

GS> Отсюда приходится сделать вывод, что ты собираешься заполнять регистр GS> t0high в прерывании по переполнению 8-ми битного таймера, подсчитывающего GS> входную частоту (иначе значение t0high не могло бы измениться). Да, конечно, t0high ведь программное расширение 8-битного таймера.

GS> Следующий контрольный вопрос, сколько времени займёт выполнение этого GS> обработчика прерывания? Оно даёт _погрешность_ периода отсчёта временного GS> интервала.

GS> PIC позволяет включить и выключить таймер одной командой, что обеспечивает GS> _точное_ формирование временного интервала даже при низкой тактовой GS> частоте ядра. Что-то я не понял, как выключение таймера (и пропуск им за это время входных импульсов) повышает точность определения временных интервалов? Ну ладо, пусть, это наверно выше моего понимания. Но тогда тем более

1) остановили таймер 2) прочли младшую часть в SFR 3) прочли старшую часть в SFR или из переменной на пике совсем одинаковый вид 4) запустили таймер. Усё.

OR>> С одной стороны - громадный выигрыш. С другой - диапазон 7..70МГц это OR>> узкая ниша даже с точки зрения 0..200Мгц.

GS> Меня интересует возможность заполнить нишу от 20кГц до 20МГц. PIC это А почему именно такой? Потому что именно в нём у пиков преимущество?

OR>> Мне так вообще за последние несколько лет частотомер крепко OR>> понадобился (осциллографа не хватило :-) только один раз и там надо OR>> было померять отношение частот.

GS> Твой самый серьёзный аргумент во всём обсуждении ;) GS> Правда он другим может быть абсолютно неубедителен...

Твоё "меня интересует диапазон XX...YY" -- это серьёзный аргумент Моё "меня интересует диапазон выше ZZZ + возможность мерять отношение частот" -- это неубедительно. Так ты всегда будешь прав.

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,

13-Jul-04 11:23 Alexander Golov wrote to Oleksandr Redchuk:

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

OR>> Кстати, что у них с инструментарием?

AG> Да вроде нормально, хотя я лично ещё не пробовал (задач пока нет). Не.. Не катит. Там, где мне сейчас надо АЦП на уровне 150-200кГц, и в перспективе может захотеться побыстрее считать (и ШИМ-ы килогерц 50 несколько согласованных), там мне и ОЗУ надо где-то под 32КБ (а лучше ещё больше). А у dsPIC ни внутри нет столько, ни шины внешней нет. А так машинка вроде неплохая. А я вот даже не знаю, толи что-то в духе TMS320LF2407 заложить с внешним ОЗУ, толи пока послать подальше перспективу "побыстрее считать и ШИМ-ы шустрые".

AG>>> brne label ; 2/1 / AG>>> dec r13 ; 1 \ AG>>> brne label ; 2/1 / 3

OR>> Можно счётчик поместить в пару, которая, к сожалению, не указатель, OR>> но adiw/sbiw с ними работают. OR>> sbiw r24,1 ; 2 OR>> brne label ; 2

AG> Просто это всё таки медленнее и нивелирует 1-цикловое преимущество AVR AG> при суммировании на двух указателях. Да я уже после отпарвки понял, что это будет короче, но не быстрее.

wbr,

13-Jul-04 05:31 Harry Zhurov wrote to Alexander Derazhne:

AD>> Пойдёт в качестве "два, три"?

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

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

out SPH,r29 out SPL,r28

Ну а нормальный стек на одной из регистровых пар и никаких идиотских 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> из регистровых пар была указателем стека. Эти два пункта взаимосвязаны. 32 регистра сожрали 10 бит в КОП-ах

2-адресных команд и 5 бит в кодах одноадресных команд, из-за чего стало тесно и не хватает кодов ни для нормального X, ни для большего количества регисторвых пар. Кстати, вполне возможно, что и для 16 регистров не хватило бы кодов для того, чтобы они все могли быть парами. Но вот старшие 8 из них чтобы были парами, одинаковыми по методам адресации, да чтобы самые старшие были указателем стека -- это точно хватило бы. Я не уверен, что 7 указателей (кроме SP) прямо так нужны. Полная симметрия это "красиво", но вот экономично ли? А вот SP с адресацией смещением и к этому ещё три "нормальных" пары - это IMHO было бы достаточно. Это было бы в два раза лучше, чем сейчас (у IAR - один SP на Y и ещё Z, X практически не в счёт). А освободившиеся коды лучше отправить на загрузку/выгрузку по указателю регистровых пар и т.п. Т.е. код адресной пары 7 ld/st в регистр косвенно по паре 7 6 6 5 5 4 4

3 пусть лучше ld/st пары регистров по паре 7, чем одного регистра по паре 3. Тебе бы очень понравилась загрузка/выгрузка всей старшей пары (указателя стека!) одной неразрывной командой по паре 6 :-)

2 и т.д. 1 0

Но это при чётном номере регистра-получателя :-) А при нечётном - ld пусть в памяти берёт один байт, и знаково его расширяет в пару по (номеру dst) & 0b110

HZ> [7] Все-таки, имхо, медленная работа с памятью. Она все гробит - при HZ> элементарном инкременте ячейки ОЗУ - 80% накладных расходов на копирование. HZ> Это явный перекос. Опять вопрос на тему свободного кодового пространства.

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

Хотя это ещё кодовое пространство смотреть надо - не понадобится ли мне ГЗМ увеличенной мощности :-)

HZ> Вот это, имхо, самые серьезные недостатки AVR. Все относится к HZ> архитектуре. Убить мало за то, что они наворотили :-(

wbr,

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

AB>>>> ... фу, какие заморочки. В AVR этого нет. GS>>> Да, в AVR с этим гораздо хуже. БОльшая часть SRAM и все порты GS>>> напрямую недоступны. AK>> Чего ??? Ты хоть знаешь о чем говоришь ? GS> Значительно лучше тебя! GS> Изобрази выдачу двух противофазных меандров на ножках порта. GS> Вот соответствующий код для PIC.

- Мальчик, как тебя зовут?

- ...

- Ты что, тормоз?

- Меня зовут Эдик.

- А фамилия?

- Нет, не тормоз.

GS> MOVLW 01b GS> MOVWF PORTx ; инициализация порта "противофазными" битами

GS> MOVLW 11b ; модифицируемые биты GS> loop1: GS> XORWF PORTx,1 ; модификация с прямым доступом к порту GS> ; 1 цикл GS> GOTO loop1 ; 2 цикла

А теперь давай по существу. Так бОльшая часть чего в AVR недоступна ? Что касается меандров - мне они абсолютно без надобности.

RA>> Уж не DTMF ли ШИМом генерил?

GS> Естественно. 8-ми битный ШИМ.

RA>> У меня на 2х ножках и 2х таймерах получилось.

GS> Ужас какой! 1 таймер, 1 ножка. Прекрасно формируется на 16F874. GS> При желании сэкономить берётся дешёвый 16F818.

Угу. Покажи, как сделал? Особенно момент суммирования 2х частот ;-)

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

GS> Мне _вполне_ хватает 16-го семейства. Опыт ;)

Иди дальше. Опыт 16х очень даже в 18х пригождается.

Привет!

Tue Jul 13 2004 10:49, Alexey Boyko wrote to Alexander Golov:

...

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

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

AB> Hеужели я так и не смог объяснить.

По-моему в полной форме это звучит впервые.

AB> Есть два периодических события AB> нужно измерять период одного и время между первым и вторым. Еще нужно AB> будет генерировать третье, тоже периодическое, через определенное AB> время от первого события. Для этого надо завести один таймер и иметь AB> с этого таймера 2 Input Capture,

Вот эта возможность была ещё в 73-м.

AB> 1 Output Compare.

Третьего CCP в них не было.

AB> С этим нет проблем AB> в msp430, так как у него есть модели с пятью Capture/Compare модулями.

Сейчас 3 CCP есть и в PIC16 (737...777).

AB> Hа atmega128 мне пришлось завести два таймера синхронно (atmega126/64 AB> позволяет синхронизировать их прескелеры). При этом я имею 2 Input AB> Capture, AB> и 6 Output Compare. В остальном задача не сложная, поэтому что-то мне AB> подсказывает, что mega128/mega64 - избыточны. Вот и думаю, мем бы AB> заменить.

Несколько CCP на одном таймере есть также в HC08 (но лично я забыл про них как про страшный сон и возвращаться не имею никакого желания).