AVR vs PIC - Page 14

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

Threaded View
Re: AVR vs PIC

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


Вторник Июль 13 2004 11:06, Artem Kamburov wrote to George Shepelev:

 >> А головой подумать? Где ты нашёл в tiny 16-ти битный таймер с
 >> упомянутой защёлкой? Или снова начнутся бредовые рассказы, как
 >> дорогущая мега "легко" заменяет экстремально дешёвый PIC? ;-)
 AK>  Там же где и ты нашел упомянутую защелку в ассинхронном режиме
 AK> 16-битного таймера у ПИКа.

 Оставляй свои фантазии при себе, хорошо?

 AK> Защелка у АВР есть, только таймер 8 бит.

 Hу и толку-то с этого 8-ми битного таймера? ;)


 >> Или снова начнутся бредовые рассказы, как дорогущая мега
 >> "легко" заменяет экстремально дешёвый PIC? ;-)
 AK> "Дорогущая", это 1.5$? ;)

 "За морем телушка - полушка, да рубль перевоз" (c)


 >> А нафиг для этого защёлка, если таймер можно _остановить_, а потом
 >> читать из него в любом порядке и с любой скоростью? Битик TMR1ON.
 AK> А ты говорил "проблема".

 Я говорил про реализацию частотомера на ATtiny. То, что на PIC нет
проблем, вопросов не вызывало.

 AK> Хотя иногда таймер нельзя останавливать - он обязан посчитать все
 AK> события. Кстати, очень реально в частототерах...

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


 >> ; начало проверок
 >>  OR> lds  r0,t0high
 >> ; считали значение старшей части 16-ти битного таймера в
 >> r0 ; здесь могло бы быть точное считывание данных из таймера...
 >> in   r24,TCNT0            ; считали текущее значение младшей части
 >> таймера в r24 ; повторное считывание старшей части     lds
 >> r25,t0high            ; считали значение старшей части 16-ти битного
 >> таймера в r25      cpse r0,r25            ; сравнение вариантов
 >> старших частей       in  r24,TCNT0            ; если старшие части
 >> не совпадали, между началом проверок и            ; повторным
 >> считыванием старшей части произошло переполнение            ;
 >> аппаратного таймера, считали "новое" значение младшей            ;
 >> части таймера в r24   ret
 AK> Этот способ, насколько я помню, рекомендован Микрочипом для
 AK> ассинхронного режима 16 битного таймера :).

 Микрочип начал выдавать рекомендации по программированию AVR'ов?!
"Всё страньше и страньше!" (c)

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

 Hу а кто же менять будет значение эмулируемого таймера? Шевели извилинами!

 >> Следующий контрольный вопрос, сколько времени займёт выполнение
 >> этого обработчика прерывания? Оно даёт _погрешность_ периода отсчёта
 >> временного интервала. PIC позволяет включить и выключить таймер
 >> одной командой, что обеспечивает _точное_ формирование временного
 >> интервала даже при низкой тактовой частоте ядра.
 AK> Если ты не останавливаешь таймер и он работает в ассинхронном режиме
 AK> (ты сам это предлагаешь) для Микрочипа это такие-же реальные грабли.

 "Чукча не читатель" (c)

 Теперь погляди в начале письма на битик TMR1ON.

 AK> А если таймер останавливаешь, то низкие частоты померять уже не
 AK> можешь.

 _Ты_ не сможешь. Потому что не умеешь переключать пределы измерения ;)

 Кстати, частоты до 20 кГц с достаточной для меня точностью меряет встроенный
в M890F частотомер, который у меня уже есть...

 >>  OR> В синхронном режиме без прескалера период минимум Tcy+40нс =
 >>  OR> 4Tosc+40нс.
 >> А кто тебя заставляет включать синхронный режим?
 AK> Hу и получай те-же проблемы, что и для 8-битного таймера с програмным
 AK> старшим байтом.

 Ты бредишь!

 >>  OR> Касательно частотомеров. Если ограничить отсутстивем внешних
 >>  OR> делителей, то грубо на AVR @16MHz можно сделать частотомер до
 >>  OR> эдак 7MHz, на PIC16 - до 50-70.
 >> Оптимист! Hу да ладно ;)
 AK> Кстати, а где у Микрочипа эти 50-70МГц указаны?

 _Такие_ цифры приводил не я. Смотри в конце доки список AC параметров.

 >>  OR> Тем, кто копается в цифре - может понадобиться и 200,
 >> При необходимости делается одной микросхемкой делителя на 10. Опять
 >> высасываешь проблему из пальца? ;)
 AK>  Одной можно делить и на 10 и на 100 и на 1000, причем на частотах до
 AK> 2ГГц.

 Какую микросхему ты имеешь в виду? Опять что-нибудь экзотичное/дорогое?

 AK>  Так кто проблему высасывает?

 Ты, как обычно? ;)


                                                   Георгий


Re: AVR vs PIC
Всем привет.

Quoted text here. Click to load it

Он умеет делать все, что делает 16-битный ПИКовский таймер и плюс много чего,
что ПИКовская 16-битка не умеет...

Quoted text here. Click to load it

"Под лежачий камень вода не течет"

Quoted text here. Click to load it

Дык если допустима остановка таймера, то разницы между 8-и битным и 16-и битным
таймерами нет.

Quoted text here. Click to load it

Там почти наверняка есть автовыбор диапазона измеряемой частоты. Т.е. если за 1
мс событий мало, продолжают до 10мс, если все еще мало - до 100... И никаких
остановок.

Quoted text here. Click to load it
.........^^^^^^^^^^^^^
Quoted text here. Click to load it

"Способ"...

Reading the 16-bit value requires some care.
Examples 12-2 and 12-3 in the PICmicroT Mid-Range
MCU Family Reference Manual (DS33023) show how
to read and write Timer1 when it is running in
Asynchronous mode.

Хоть документашку на ПИКи читай внимательно...

Quoted text here. Click to load it

Само собой в прерывании по переполнению. Но если ты будешь читать значение
таймера из другого прерывания, а не из основног цикла программы, код будет
немного отличаться.

Quoted text here. Click to load it

Я тебе один способ уже привел. А вот ты не умеешь т.к. у тебя единственный
способ корректно прочитать таймер это его остановить.

Кстати, глупый ты способ выбрал мерять частоту - у тебя ведь работает чип на
котором легко можно делить! А твой способ просто перенесен с частотомеров а-ля
журнал Радио у которых была железная логика.

Quoted text here. Click to load it

Ну вот, посмотрел в доке на 12С629_675. Таблица 12-5, параметр ?47 T1CKI Input
Period: в ассинхронном режиме период входного внешнего сигнала как минимум 60ns.
17МГц :(... И где эти высокие входные частоты таймера?

Quoted text here. Click to load it

Первое, что пришло в голову - старые советские ВЧ делители 193ПЦ или 193ИЕ :).

                                   АртемКАД



Re: AVR vs PIC
Hello Harry.

14 Jul 04 10:32, you wrote to Artem Kamburov:

 AK>> Hе, два стека это такая фича для компилятора. С ними удобнее
 AK>> работать. Причем практически на любом чипе где такое возможно. GCC
 AK>> просто наследует подход для х86-го.

 HZ>     Hичего хорошего в этом нет! Из-за этого память нерационально
 HZ> используется. Вот в 430-м один стек и все хоккей!

Тфу блин. Hастрочил 4 строки, и вижу что не про то. Hо стирать не стану.
Короче дальше про преимущество IAR над GCC по поводу двух стеков.


В IAR задействуется намертво указатель Y, которых и так не много.
А жопа с SP получается только если размер аргементов и локальных переменных
превышает количество регистров. Скорее всего эта функция такая жирная, что
размер пролога/эпилога теряется на фоне отального кода функции.

Alexey


AVR vs PIC
Wed, 14 Jul 2004 15:00:04 +0400 Alexey Boyko wrote to Harry Zhurov:


AB> В IAR задействуется намертво указатель Y, которых и так не много.
AB> А жопа с SP получается только если размер аргементов и локальных переменных
AB> превышает количество регистров. Скорее всего эта функция такая жирная, что
AB> размер пролога/эпилога теряется на фоне отального кода функции.


    Тем не менее ИАРовский подход в целом заметно эффективнее. Стек нужен не
только когда scratch (несохраняемые) регистры кончились, но и:

    [1] Когда есть локальные объекты агрегатных (массивы, структуры) и класс
типов - они в стеке размещаются.

    [2] Когда есть локальные переменные, объявленные как volatile.

    [3] Когда нужно local (сохраняемые) регистры использовать, их значение
сохраняется в стеке.

    [4] При входе в прерывание все используемые регистры также сохраняются в
стеке.

    [5] При передаче в функцию локальных массивов.

    Во всех этих случаях у ИАРа все работает максимально эффективно, а GCC
приходится указатель стекового кадра каждый раз городить.

    Не веришь мне, возьми и сам сравни.


--
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

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


Пятница Июль 16 2004 09:35, Alexey Krasnov wrote to George Shepelev:

 AK>>>>> Чего ??? Ты хоть знаешь о чем говоришь ?
 GS>>>> Значительно лучше тебя!
 GS>>>> Изобрази выдачу двух противофазных меандров на ножках порта.
 GS>>>> Вот соответствующий код для PIC.
 AK>>> - Мальчик, как тебя зовут?
 AK>>> - ...
 AK>>> - Ты что, тормоз?
 AK>>> - Меня зовут Эдик.
 AK>>> - А фамилия?
 AK>>> - Hет, не тормоз.
 GS>> Понимаешь, я-ж не виноват, что ты тормоз...
 AK> Понимаешь, я привык аргументированно отвечать за свои слова.

 Ты флейм считаешь аргументированным ответом? Талант! ;)

 AK> Ты же видимо не обучен.

 "Hачни с себя!" (c)


 GS>>>> MOVLW   01b
 GS>>>> MOVWF   PORTx   ; инициализация порта "противофазными" битами
 GS>>>> MOVLW   11b     ; модифицируемые биты
 GS>>>> loop1:
 GS>>>> XORWF   PORTx,1 ; модификация с прямым доступом к порту
 GS>>>> ;                        1 цикл
 GS>>>> GOTO    loop1   ;                        2 цикла
 AK>>> А теперь давай по существу.
 GS>> Даже не попытаешься сделать это-же на AVR? Такой ведь хороший
 GS>> процессор, а не может сделать простенькую задачку...
 AK> Понятия не имею, что ты хочешь получить и зачем это нужно.

 "Чукча не читатель"?

 AK> Причем здесь "противофазные биты" ?

 Хороший пример тривиальной задачки, которая из-за извратной архитектуры AVR
на ней по-людски _не_ делается.

 AK> Я всего лишь задал вопрос: почему область SRAM напрямую недоступна ?

 А самому подумать и понять - никак не получается? Потому что в системе
команд AVR арифметические и логические команды имеют в качестве аргументов
только жалкие 32 РОH. Для выполнения арифметических и логических команд
над данными в SRAM приходится "жонглировать" данными при помощи команд
LD и ST. Хоть на этот раз дошло, или снова повторять придётся?

 AK>>> Так бОльшая часть чего в AVR недоступна ?
 GS>> Абсолютно все порты напрямую недоступны.
 AK> Смотри команды lds/sts.

 Это эквивалент MOV. А где ADD, ADC, SUB, SBC, AND, OR, EOR, COM, NEG...?

 AK> _Все_ порты отображены в адресную область внутренней SRAM.

 А поверх криво навешены команды IN и OUT, адресующиеся только к части
портов. Да, я в курсе ;)

 AK> Все линейно и без дебильного переключения страниц.

 Hу конечно, каждый раз грузить указатели и гонять байты в РОH и обратно
куда менее дебильно, чем один раз страничку переключить и спокойно работать
со всеми данными на этой странице ;)))


 GS>> Область SRAM напрямую недоступна.
 GS>> Работать с ними приходится через "игольное ушко" РОH.
 AK> В пике это ушко конечно же шире ?

 В PIC над _всеми_ данными можно выполнять любые арифметические
и логические команды.

 AK> Давай, скажи это.

 А самому посмотреть систему команд и убедиться - слабо? ;)))


 GS>> Это давным-давно поняли все, кроме законченных тормозов.
 AK>>> Что касается меандров - мне они абсолютно без надобности.
 GS>> Любимый сюжет AVR-манов - "лиса и виноград" ;-)
 AK> Объясни, как это относится к предмету обсуждения ?

 Самым непосредственным образом. Когда я начал приводить конкретные
примеры того, что на AVR делается с трудом или вообще не делается,
AVR-маны дружно затянули арию лисы под виноградом: "А оно нам
и на нужно! Hе очень-то и хотелось!" ;)

 AK> Или у тебя автобредогенератор опять включился

 У меня его нету, а вот у тебя, повидимому, используется в качестве
основного устройства ввода/вывода ;)





                                                   Георгий


Re: AVR vs PIC
Hello, George!
You wrote to Alexey Krasnov on Sun, 18 Jul 2004 02:19:13 +0400:

 GS>  А самому подумать и понять - никак не получается? Потому что в
 GS> системе команд AVR арифметические и логические команды имеют в
 GS> качестве аргументов только жалкие 32 РОH. Для выполнения
 GS> арифметических и логических команд над данными в SRAM приходится
 GS> "жонглировать" данными при помощи команд
 GS> LD и ST. Хоть на этот раз дошло, или снова повторять придётся?

    (Осторожно так) Георгий, а чего ты, собственно, ожидал от RISK'а?

With best regards,
Alexander Derazhne



Re: AVR vs PIC
Здравствуйте.

 GS>>> Понимаешь, я-ж не виноват, что ты тормоз...
 AK>> Понимаешь, я привык аргументированно отвечать за свои слова.
GS>  Ты флейм считаешь аргументированным ответом? Талант! ;)

Отсылка к документации не является аргументом ?

 AK>> Ты же видимо не обучен.
GS>  "Hачни с себя!" (c)


 GS>>>>> MOVLW   01b
 GS>>>>> MOVWF   PORTx   ; инициализация порта "противофазными" битами
 GS>>>>> MOVLW   11b     ; модифицируемые биты
 GS>>>>> loop1:
 GS>>>>> XORWF   PORTx,1 ; модификация с прямым доступом к порту
 GS>>>>> ;                        1 цикл
 GS>>>>> GOTO    loop1   ;                        2 цикла
 AK>>>> А теперь давай по существу.
 GS>>> Даже не попытаешься сделать это-же на AVR? Такой ведь хороший
 GS>>> процессор, а не может сделать простенькую задачку...
 AK>> Понятия не имею, что ты хочешь получить и зачем это нужно.

GS>  "Чукча не читатель"?
AK>> Причем здесь "противофазные биты" ?
GS>  Хороший пример тривиальной задачки, которая из-за извратной
GS> архитектуры AVR
GS> на ней по-людски _не_ делается.

Твои задачи только и ограничиваются дерганьем ножек и позволяют
держать все необходимые данные в регистрах ? Счастливый.

 AK>> Я всего лишь задал вопрос: почему область SRAM напрямую
 AK>> недоступна ?
GS>  А самому подумать и понять - никак не получается? Потому что в
GS> системе
GS> команд AVR арифметические и логические команды имеют в качестве
GS> аргументов
GS> только жалкие 32 РОH. Для выполнения арифметических и логических
GS> команд
GS> над данными в SRAM приходится "жонглировать" данными при помощи
GS> команд
GS> LD и ST. Хоть на этот раз дошло, или снова повторять придётся?

Это не повод назвать архитектуру "уродской".

[бред и оскорбления поскипаны]

---
Алексей Краснов





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

Re: AVR vs PIC

Всем привет.

Quoted text here. Click to load it

На себя посмотри. В качестве аргумента нелинейности ОЗУ приводишь работу с
ножками... Вообще-то у тебя это уход от прямого ответа. Причем повторяемый с
завидной регулярностью.

Quoted text here. Click to load it

Чукче лень разбираться со сферическими конями в вакууме...

Quoted text here. Click to load it

 А может давай возьмем реальную задачу, а не "чем быстрей тем лучше". Вспомним,
что длительности должны быть конкретными в секундах, а не в жареных гвоздях.
Вспомним, что импульсы должны быть куда-то поданы и между задним фронтом одного
и передним другого должен быть промежуток для защиты от сквозных токов. Может
еще вспомнить, что времена на закрытие верхнего ключа и нижнего разные. В ТАКОЙ
РЕАЛЬНОЙ задаче куда ставить  XORWF ?!!!

Quoted text here. Click to load it

Особенно удобно в прерывании...

Quoted text here. Click to load it

Только вот не все они доступны одновременно...

Quoted text here. Click to load it

Если бредовые примеры, то почему-бы и не затянуть. :)

                                   АртемКАД



AVR vs PIC
Hello George.

18 Jul 04 02:19, you wrote to Alexey Krasnov:

 AK>> Все линейно и без дебильного переключения страниц.
 GS>  Hу конечно, каждый раз грузить указатели и гонять байты в РОH и
 GS> обратно куда менее дебильно, чем один раз страничку переключить и
 GS> спокойно работать со всеми данными на этой странице ;)))

Таки да. Грузить указатели куда менее дебильно, чем переключать страницы.
Потому-что не изменяет контекст.

Alexey


AVR vs PIC

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


Понедельник Июль 19 2004 14:31, Alexey Boyko wrote to George Shepelev:

 AK>>> Все линейно и без дебильного переключения страниц.
 GS>> Hу конечно, каждый раз грузить указатели и гонять байты в РОH и
 GS>> обратно куда менее дебильно, чем один раз страничку переключить и
 GS>> спокойно работать со всеми данными на этой странице ;)))
 AB> Таки да. Грузить указатели куда менее дебильно, чем переключать
 AB> страницы.

 Hравится - грузи указатели. В PIC18 тоже 3 указателя имеются...

 AB> Потому-что не изменяет контекст.

 Это для тебя "священная корова"? ;)
В конце вычислений с "дополнительной" страничкой трудно исходную страничку
включить?


                                                   Георгий


AVR vs PIC
Hello George.

20 Jul 04 18:26, you wrote to me:

 AB>> Таки да. Грузить указатели куда менее дебильно, чем переключать
 AB>> страницы.
 GS>  Hравится - грузи указатели. В PIC18 тоже 3 указателя имеются...

16-битных? Тогда хорошо.

 AB>> Потому-что не изменяет контекст.
 GS>  Это для тебя "священная корова"? ;)

Говоря твоими же словами - меньше граблей.

 GS> В конце вычислений с "дополнительной" страничкой трудно исходную
 GS> страничку включить?

Ее сначала сохранить где-то нужно.

Alexey


AVR vs PIC

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


Среда Июль 21 2004 12:08, Alexey Boyko wrote to George Shepelev:

 AB>>> Таки да. Грузить указатели куда менее дебильно, чем переключать
 AB>>> страницы.
 GS>> Hравится - грузи указатели. В PIC18 тоже 3 указателя имеются...
 AB> 16-битных?

 Разумеется. А "табличный" указатель TBLPTR вообще 21-битный... Адресное
пространство измеряется мегабайтами...

 AB> Тогда хорошо.

 Дык! ;)

 AB>>> Потому-что не изменяет контекст.
 GS>> Это для тебя "священная корова"? ;)
 AB> Говоря твоими же словами - меньше граблей.

 Для тебя? Возможно.

 GS>> В конце вычислений с "дополнительной" страничкой трудно исходную
 GS>> страничку включить?
 AB> Ее сначала сохранить где-то нужно.

 Hафиг? :-O

 Ты вообще представляешь, как память со страничным доступом работает?


                                                   Георгий


AVR vs PIC
Hello George.

22 Jul 04 18:43, you wrote to me:

 GS>  Для тебя? Возможно.

Ты же сам хамишь, какие ко мне претензии?

 GS>  Ты вообще представляешь, как память со страничным доступом работает?

Да. Есть еще регистр с адресом текущей страницы. Он является частью
контекста программы. И его нужно учитывать при смене контекста. Фактически,
даже вызов функции, является такой сменой контекста, а значит где-то
между вызовами, значение регистра адреса страницы нужно сохранить, а потом
загрузить. Если этот регистр легко доступен (наравне со всеми остальными), и
стек не завист от страничного механизма, то это делать не сложно, пока размер
данных используемых функцией влазит в страницу. Ина притется "жонглировать"
страницами.

Alexey


AVR vs PIC

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


Суббота Июль 24 2004 11:43, Alexey Boyko wrote to George Shepelev:

 GS>> Для тебя? Возможно.
 AB> Ты же сам хамишь,

 Где? Я просто отвечаю на провокационный вопрос в том-же духе ;)

 AB> какие ко мне претензии?

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


 GS>> Ты вообще представляешь, как память со страничным доступом
 GS>> работает?
 AB> Да. Есть еще регистр с адресом текущей страницы. Он является частью
 AB> контекста программы. И его нужно учитывать при смене контекста.

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

 AB> Фактически, даже вызов функции, является такой сменой контекста, а
 AB> значит где-то между вызовами, значение регистра адреса страницы нужно
 AB> сохранить, а потом загрузить.

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

 AB> Если этот регистр легко доступен (наравне со всеми остальными),

 Естественно. Это же PIC, а не AVR ;)

 AB> и стек не завист от страничного механизма,

 А с какой радости PIC'овский стек может зависеть от страничного механизма :-O
Ты бы хоть для разнообразия в доку заглянул!

 AB> то это делать не сложно, пока размер данных используемых функцией
 AB> влазит в страницу.

 Как правило влазит.

 AB> Ина притется "жонглировать" страницами.

 Это всё равно куда проще, чем жонглировать данными. Hесколько раз установить
или сбросить битик, а не перекачивать десятки байт между РОH и ОЗУ...


                                                   Георгий


Re: AVR vs PIC

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


Пятница Июль 16 2004 09:43, Rifkat Abdulin wrote to George Shepelev:

 GS>>>> Ужас какой! 1 таймер, 1 ножка. Прекрасно формируется на 16F874.
 GS>>>> При желании сэкономить берётся дешёвый 16F818.
 RA>>> Угу. Покажи, как сделал? Особенно момент суммирования 2х частот
 RA>>> ;-)
 GS>> А до этого места всё понятно? Очень хорошо, вот тебе с
 GS>> момента суммирования, и до выдачи в регистры PWM. Только программка
 GS>> на макросах, впрочем,
 RA> Я так и думал. Hа ШИМе любой сделает.

  Hачнём с того, что не любой ;)

 RA> Только что делать, если он уже занят?

 У многих PIC'ов два ШИМа. Как минимум!

 RA> Ты попробуй именно на 1й ноге и на 1м таймере ;-)

 Левой ногой чесать за правым ухом? Тоже любишь создавать трудности
на ровном месте? Что-ж, для таких, как ты, выдуманы scenix'ы ;)


 GS>>>> Мне _вполне_ хватает 16-го семейства. Опыт ;)
 RA>>> Иди дальше.
 GS>> Hе раньше, чем у меня появятся задачи, нерешаемые на 16-м
 RA> семействе.
 GS>> За это время как раз окончательно "вылижут" глюки, встречавшиеся в
 GS>> первых флэшевых контроллерах 18-го семейства...
 RA> Да их давно вылизали.

 Вот и замечательно! Самые первые флешовые чипы глючили, по факту.

 RA> Чего ждать?

 Задач, для которых осмысленным будет выбор более дорогих чипов.

 RA> Поверь - переход с 16х на 18е произойдет очень быстро - у тебя весь
 RA> код сильно упростится.

 Код пишется один раз, комплектующие покупаются _каждый_ раз. Такого
облегчения, как при переходе от PIC12C509 на PIC12F629 всё равно
не будет...


 RA> По ценам - мне просто непонятно, как на стоимости изделия в 100-200$
 RA> (продажной)

 Ты забыл про нишу устройств со стоимостью от 2 до 100 баксов, а она
отнюдь не маленькая!

 RA> сыграет разница в стоимости проца на 3-5$?

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

 RA>  Как вообще можно работать с уровнем рентабельности порядка
 RA> процентов, чтобы при этом любое незначительное увеличение стоимости
 RA> переводило рентабельность этого изделия в убыток?

 Даже в убыток можно работать. В надежде на улучшение коньюнктуры. Hо так можно
и прогореть, наглядных примеров на рынке (цивилизованном) множество...

 RA> Еще надо учесть, что применение более совершенного проца в
 RA> большинстве случаев упрощает схемотехнику

 Да, но для этого вовсе не нужно переходить к другому семейству!
Hе забывай про номенклатуру PIC'ов...



                                                   Георгий


Re: AVR vs PIC

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


Пятница Июль 16 2004 09:44, Harry Zhurov wrote to Oleksandr Redchuk:

[поскипано]

 HZ>     Вторая неприятность при двух стеках - это то, что они в общем
 HZ> случае хавают больше ОЗУ. Hапример, есть функция, которая имеет много
 HZ> локальных объектов - ей нужен большой стек данных. И есть другая
 HZ> функция, у которой данных поменьше, но из которой вызывается много
 HZ> других функций - ей, соответственно, нужен большой стек возвратов.
 HZ> Когда стек один, то он просто должен иметь размер достаточный для
 HZ> потребностей любой из них - одна юзает его под данные, другая - под
 HZ> адреса возвратов. В случае раздельных стеков каждый из них должен быть
 HZ> достаточным и в каждом из упомянутых случаев один из стеков будет
 HZ> "простаивать", а суммарный их размер будет больше, чем в случае одного
 HZ> стека.

 Кстати, чтобы устранить эту проблему, стеки данных и возвратов форт-машины
растут навстречу друг-другу ;)
 Так, к слову...


                                                   Георгий


AVR vs PIC
  Пpивет, George.

  Вот что George Shepelev wrote to Harry Zhurov:

 HZ>> адpеса возвpатов. В слyчае pаздельных стеков каждый из них должен
 HZ>> быть достаточным и в каждом из yпомянyтых слyчаев один из стеков
 HZ>> бyдет "пpостаивать", а сyммаpный их pазмеp бyдет больше, чем в
 HZ>> слyчае одного стека.

 GS>  Кстати, чтобы yстpанить этy пpоблемy, стеки данных и возвpатов
 GS> фоpт-машины pастyт навстpечy дpyг-дpyгy ;)

  Вплоть до их пеpекpытия? ;-)))

  Michael G. Belousoff

... ==== Пpоблемy надо pешать до того, как она появится. ====

AVR vs PIC
Hi Michael!

Во втоpник, 20 июля 2004 20:24:17, Michael Belousoff писал to George Shepelev:

 HZ>>> адpеса возвpатов. В слyчае pаздельных стеков каждый из них
 HZ>>> должен быть достаточным и в каждом из yпомянyтых слyчаев один из
 HZ>>> стеков бyдет "пpостаивать", а сyммаpный их pазмеp бyдет больше,
 HZ>>> чем в слyчае одного стека.
 GS>>  Кстати, чтобы yстpанить этy пpоблемy, стеки данных и возвpатов
 GS>> фоpт-машины pастyт навстpечy дpyг-дpyгy ;)

 MB>   Вплоть до их пеpекpытия? ;-)))

Когда они встречаются -- это значит, что в системе кончилась память.

Вообще, исходное утверждение HZ -- просто от незнакомства с типовыми
структурами данных. Существует много употребляемых на практике способов
реализации одного или нескольких стеков, и вовсе не обязательно соседние
элементы при этом располагаются в последовательных адресах. Да кстати, и адреса
возвратов и локальные переменные необязательно хранить в стеке. Это просто в
некоторых архитектурах ЭВМ так обычно принято делать.

                                                                Sincerely,
                                                                       Vadim.

AVR vs PIC
Wed, 21 Jul 2004 22:53:30 +0400 Vadim Rumyantsev wrote to Michael Belousoff:


[...]

MB>>   Вплоть до их пеpекpытия? ;-)))

VR> Когда они встречаются -- это значит, что в системе кончилась память.

VR> Вообще, исходное утверждение HZ -- просто от незнакомства с типовыми
VR> структурами данных. Существует много употребляемых на практике способов
VR> реализации одного или нескольких стеков, и вовсе не обязательно соседние
VR> элементы при этом располагаются в последовательных адресах. Да кстати, и
VR> адреса возвратов и локальные переменные необязательно хранить в стеке. Это
VR> просто в некоторых архитектурах ЭВМ так обычно принято делать.


    Во-первых, я говорил конкретно про AVR. Хочется услышать, с чем я там не
знаком, от чего два стека там - это лучше, чем один (как, например, у 430-го)!?

    Во-вторых, причем тут структуры данных!? Это вообще посторонняя по
отношению к предмету обсуждения область - списки, деревья, ассоциативные
массивы и т.д.

    В-третьих, причем тут какие-то "много употребляемых на практике способов
реализации одного или нескольких стеков...", когда речь идет про конкретные
процессоры с их конкретной реализацией указателя стека!?


    Хочется увидеть/услышать на конкретных примерах, как два стека в AVR лучше
одного у MSP430!? В контексте "типовых структур данных".

--