Do you have a question? Post it now! No Registration Necessary
Threaded View
Subject
Reply
Save
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
Всем привет.
Он умеет делать все, что делает 16-битный ПИКовский таймер и плюс много чего,
что ПИКовская 16-битка не умеет...
"Под лежачий камень вода не течет"
Дык если допустима остановка таймера, то разницы между 8-и битным и 16-и битным
таймерами нет.
Там почти наверняка есть автовыбор диапазона измеряемой частоты. Т.е. если за 1
мс событий мало, продолжают до 10мс, если все еще мало - до 100... И никаких
остановок.
.........^^^^^^^^^^^^^
"Способ"...
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.
Хоть документашку на ПИКи читай внимательно...
Само собой в прерывании по переполнению. Но если ты будешь читать значение
таймера из другого прерывания, а не из основног цикла программы, код будет
немного отличаться.
Я тебе один способ уже привел. А вот ты не умеешь т.к. у тебя единственный
способ корректно прочитать таймер это его остановить.
Кстати, глупый ты способ выбрал мерять частоту - у тебя ведь работает чип на
котором легко можно делить! А твой способ просто перенесен с частотомеров а-ля
журнал Радио у которых была железная логика.
Ну вот, посмотрел в доке на 12С629_675. Таблица 12-5, параметр ?47 T1CKI Input
Period: в ассинхронном режиме период входного внешнего сигнала как минимум 60ns.
17МГц :(... И где эти высокие входные частоты таймера?
Первое, что пришло в голову - старые советские ВЧ делители 193ПЦ или 193ИЕ :).
АртемКАД
Он умеет делать все, что делает 16-битный ПИКовский таймер и плюс много чего,
что ПИКовская 16-битка не умеет...
"Под лежачий камень вода не течет"
Дык если допустима остановка таймера, то разницы между 8-и битным и 16-и битным
таймерами нет.
Там почти наверняка есть автовыбор диапазона измеряемой частоты. Т.е. если за 1
мс событий мало, продолжают до 10мс, если все еще мало - до 100... И никаких
остановок.
.........^^^^^^^^^^^^^
"Способ"...
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.
Хоть документашку на ПИКи читай внимательно...
Само собой в прерывании по переполнению. Но если ты будешь читать значение
таймера из другого прерывания, а не из основног цикла программы, код будет
немного отличаться.
Я тебе один способ уже привел. А вот ты не умеешь т.к. у тебя единственный
способ корректно прочитать таймер это его остановить.
Кстати, глупый ты способ выбрал мерять частоту - у тебя ведь работает чип на
котором легко можно делить! А твой способ просто перенесен с частотомеров а-ля
журнал Радио у которых была железная логика.
Ну вот, посмотрел в доке на 12С629_675. Таблица 12-5, параметр ?47 T1CKI Input
Period: в ассинхронном режиме период входного внешнего сигнала как минимум 60ns.
17МГц :(... И где эти высокие входные частоты таймера?
Первое, что пришло в голову - старые советские ВЧ делители 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
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
приходится указатель стекового кадра каждый раз городить.
Не веришь мне, возьми и сам сравни.
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
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
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. Хоть на этот раз дошло, или снова повторять придётся?
Это не повод назвать архитектуру "уродской".
[бред и оскорбления поскипаны]
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
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Re: AVR vs PIC
Всем привет.
На себя посмотри. В качестве аргумента нелинейности ОЗУ приводишь работу с
ножками... Вообще-то у тебя это уход от прямого ответа. Причем повторяемый с
завидной регулярностью.
Чукче лень разбираться со сферическими конями в вакууме...
А может давай возьмем реальную задачу, а не "чем быстрей тем лучше". Вспомним,
что длительности должны быть конкретными в секундах, а не в жареных гвоздях.
Вспомним, что импульсы должны быть куда-то поданы и между задним фронтом одного
и передним другого должен быть промежуток для защиты от сквозных токов. Может
еще вспомнить, что времена на закрытие верхнего ключа и нижнего разные. В ТАКОЙ
РЕАЛЬНОЙ задаче куда ставить XORWF ?!!!
Особенно удобно в прерывании...
Только вот не все они доступны одновременно...
Если бредовые примеры, то почему-бы и не затянуть. :)
АртемКАД
AVR vs PIC
Hello George.
18 Jul 04 02:19, you wrote to Alexey Krasnov:
AK>> Все линейно и без дебильного переключения страниц.
GS> Hу конечно, каждый раз грузить указатели и гонять байты в РОH и
GS> обратно куда менее дебильно, чем один раз страничку переключить и
GS> спокойно работать со всеми данными на этой странице ;)))
Таки да. Грузить указатели куда менее дебильно, чем переключать страницы.
Потому-что не изменяет контекст.
Alexey
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
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
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ешать до того, как она появится. ====
Вот что 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.
Во вто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!? В контексте "типовых структур данных".
[...]
MB>> Вплоть до их пеpекpытия? ;-)))
VR> Когда они встречаются -- это значит, что в системе кончилась память.
VR> Вообще, исходное утверждение HZ -- просто от незнакомства с типовыми
VR> структурами данных. Существует много употребляемых на практике способов
VR> реализации одного или нескольких стеков, и вовсе не обязательно соседние
VR> элементы при этом располагаются в последовательных адресах. Да кстати, и
VR> адреса возвратов и локальные переменные необязательно хранить в стеке. Это
VR> просто в некоторых архитектурах ЭВМ так обычно принято делать.
Во-первых, я говорил конкретно про AVR. Хочется услышать, с чем я там не
знаком, от чего два стека там - это лучше, чем один (как, например, у 430-го)!?
Во-вторых, причем тут структуры данных!? Это вообще посторонняя по
отношению к предмету обсуждения область - списки, деревья, ассоциативные
массивы и т.д.
В-третьих, причем тут какие-то "много употребляемых на практике способов
реализации одного или нескольких стеков...", когда речь идет про конкретные
процессоры с их конкретной реализацией указателя стека!?
Хочется увидеть/услышать на конкретных примерах, как два стека в AVR лучше
одного у MSP430!? В контексте "типовых структур данных".
--