Embedded OS

Пpивет, Alexey!

*** 19 Apr 05 07:48, Alexey Boyko wrote to Vladislav Baliasov:

AB>>> В смысле? Сколькибитный? Может ты имел в ввиду многобайтный? VB>> Изофаллически. Скажем, 32 бита. Я имею в виду _логический_ VB>> сдвиговый регистр.

AB> Hу, конкретно 32-х битный может лежать в 4-х регистрах. И сдвигаться AB> четырьмя командами. Может загрузиться один раз из ОЗУ, потом AB> сохраниться. Hа сдвиг каждого байта его перегружать не надо. Может AB> передаться как аргумент функции.

Тому четыре регистра, этому четыре регистра (конкретно у меня была задача, когда только семплеру нужно было пять 32-битных регистра сдвига)... Про то и речь, что при _таком_ распределении регистров трех десятков мало.

AB> Hапример, у меня есть функция в котором в цикле такой 32-х битный AB> регистр сдвигается (маска нужна была). Так как переменная локальная, в AB> ОЗУ она вообще не побывала, только в регистрах.

AB> Где ты увидел загрузки восстановления на каждую операцию?

Если требования задачи ограничены - можно и все на регистрах сделать. Как в s1200. Как только их не хватает - начинается довольно тоскливая и накладная (как по быстродействию, так и по объему кода) работа с оперативкой.

с уважением Владислав

Reply to
Vladislav Baliasov
Loading thread data ...

Пpивет, Ruslan!

*** 19 Apr 05 15:04, Ruslan Polyakov wrote to Vladislav Baliasov:

RP> Задачи странные, вот деление 32/32 с остатком 32 на АВР - грузим из RP> памяти 2 х 32 в регистры, делим в регистрах, заталкиваем обратно в RP> память, итого 746 тактов, при 20 МГц 37.150 микросекунд, из них 40 RP> тактов пересылок, остальное счет. Hе мерянья ради, просто интересно, RP> сколько времени пику потребуется на эту задачу при равной тактовой.

Поскольку в твоем примере все вычисление в регистрах, то PIC, понятное дело, медленнее. Причем даже не вчетверо, а, из-за сложностей с многоразрядной арифметикой, еще хуже (просчитывать лениво). Однако же с сдвиговым регистром - это тоже вполне реальная задача, и вписаться в набор регистров без использования SRAM я не смог, и код оказался толще, чем на PIC (с которого я ради интереса перетаскивал алгоритм на AVR).

с уважением Владислав

Reply to
Vladislav Baliasov

Hello All & Vladislav Baliasov!

Задачи странные, вот деление 32/32 с остатком 32 на АВР - грузим из памяти

2 х 32 в регистры, делим в регистрах, заталкиваем обратно в память, итого 746 тактов, при 20 МГц 37.150 микросекунд, из них 40 тактов пересылок, остальное счет. Не мерянья ради, просто интересно, сколько времени пику потребуется на эту задачу при равной тактовой.

Удачи! Руслан.

Reply to
Ruslan Polyakov

Hi Vladimir !

Совсем недавно 19 Apr 05 02:32, Vladimir Vassilevsky писал к Ruslan Mohniuc:

AT>>> Только при выполнении специфических для ДСП команд (МАС AT>>> операции), а при "дерганье ножками" - как бы ДСП небыл AT>>> помедленее ПИКа, при равной тактовой. RM>> Если только дергать- то то же самое, есть там и команды типа RM>> BITSET.

VV> Там все сложнее, так как периферия работает на Bus Clk, а ядро VV> на Core Clk. Hу, это да.

я про BF533. Сейчас вот решил еще попробовать, столкнулся с непонятным. Болтал одной из ног PF в цикле: при CCLK=400MHz и SCLK=80MHz вижу 20 МГц. Hу, это я вроде понимаю. Поставил SCLK=CCLK=50MHz. Вижу на ноге PF 3.55 МГц. Hе понимаю :( То есть ровно в 112 раз меньше чем VCO (если точнее, то там у меня

36*11.059=398.124 МГц). PLL_DIV = 0x0038, PLL_CTL = 0x4800, кварц на 11.059 МГц.

Это как-то согласуется с документацией?

Кстати, я наверно плохо смотрел, но не нашел, как растактовывается Блэкфин при работе скажем с теми же выводами PF. Это где-то явно написано?

Честно говоря, после мелкочиповской документации АналогДевайсовская не вызывает приятных ощущений. Там где Майкрочип рисует диаграмму, АналогДевайс дает текстовое описание взаимосвязи сигналов. Hужно читать, вместо того, чтобы просто смотреть.

WBRgrds Ruslan

Reply to
Ruslan Mohniuc

Hello Vladislav Baliasov!

Мои задачи помимо дерганья ножками включают 32 разрядную целочисленную арифметику, поэтому я стараюсь все вычисления производить в РОНах, результаты складываю в память. Вообще необходимы различные подходы к программированю на пиках и авр, использующие достоинства каждого. Вот сейчас пишу программу обслуживания стекляшки от NOKIA 3310, там 504 байта двигать придется, попробую извратиться со стеком. Пишу на Algorithm Builder - графический ассемблер, полная среда разработки, чтобы тут про него не писал AT, штука хорошая и сопровождается хорошо, можно не зацикливаясь на кодировании просто писать алгоритм , очень наглядно, даже чужие исходники читаются нормально и без коментариев.

Удачи! Руслан.

Reply to
Ruslan Polyakov

Mon Apr 11 2005 21:33, Anatoly Mashanov wrote to Alex Kouznetsov:

AK>> архитектурам. У стековых несколько преимуществ: -- очень простое и AK>> компактное ядро -- можно получить в 2-3 раза более плотный код чем у AK>> рисков -- прекрасная совмеcтимость с ЯВУ В сумме это даст много. В AK>> качестве примерa можно сослаться на стековый проц ST5: по цене он AK>> такой же, как отстойная дешевка ST6, а по производительности - как AK>> моторолоподобный ST7.

AM> По моим прикидкам, при изготовлении стекового форт-проца на 1804 серии AM> получается существенно большее у[beep]ище, чем при использовании AM> традиционной архитектуры на том же железе.

В подтверждение моих слов об эффективности стековых архитектур, бенчмарк

formatting link
По параметру "плотность производительности ( Performance density is a measure of a processor's performance per unit of phsyical space, i.e., the amount of silicon it occupies) стековый Ignite в несколько раз уделывает RISC-и, включая ARM, SH, PPC, MIPS. Приятно было видеть, что в этом году PTSC наконец-то нашло достойного заказчика в лице AMD. Подробности сделки не раскрываются, но можно догадаться, что AMD берет Ignite как платформу для будущей линейки мобильных процев, в пику интелевским/самсунговским ARM-ам. Прекрасная заточенность стекового проца на жабу/нет обеспечивает ему прекрасную перспективу. Следите за прессой ;-))

Пока, Алексей

Reply to
Alex Kouznetsov

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

Понедельник Апрель 18 2005 07:28, Vadik Akimoff wrote to George Shepelev:

GS>> Чтобы _осознать_ проблему, попробуй написать код для AVR, GS>> аналогичный вот этому для Z80: GS>> LDIR ; сдвиг блока данных влево VA> Аналог лдира для произвольных мест во внешней 64кб памяти и блока VA> <=256 байт: VA> ld r4,X+ VA> st Y+,r4 VA> dec r5 VA> brne $-3 VA> Для произвольной длины блока dec заменить на sbiw

Ото-ж. Hа AVR-ке куда больше строчек вбивать придётся, и больше думать при этом ;) Hеоправданное использование "$" - грязный хак.

VA> "Чтобы осознать проблему", изобрази такое же для пики, хоть 16, хоть VA> 18 (прочитав внимательно про внешнюю память).

А при чём тут "пики"? Вздорный тезис был о том, что AVR - дальнейшее развитие Z80...

GS>> В том-то и дело, что очень часто контроллеру приходится работать GS>> с данными, которые _не_ находятся в регистрах. С этим AVR GS>> справляется с трудом... VA> Именно пик (у которого, как многие считают, вся внутренняя рам - VA> регистры) с трудом справляется,

Таки справляется ;-)

VA> в то время как авр - вполне прилично.

Hет. Ещё раз повторяю, на конкретных задачах AVR-ы "пролетают". Как только приходится активно работать больше чем с 16 ячейками данных.

Георгий

Reply to
George Shepelev

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

Понедельник Апрель 18 2005 08:00, Kirill Frolov wrote to George Shepelev:

Теоретики писали, что выгода неоспоримая!

KF> Зато элементарный сумматор невероятно усложняется.

Теоретики не нисходили до _таких_ тонкостей ;)

Георгий

Reply to
George Shepelev

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

Понедельник Апрель 18 2005 08:28, Rifkat Abdulin wrote to George Shepelev:

RA>>> С 18ми у тебя столько аргументов появятся ;-) GS>> 18е заметно дороже, а это минус... RA> Экономия на стоимости камня - это даже не минус, это умножение на RA> нуль!

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

RA> Убийственный аргумент против 16х пиков - стек из 8ми уровней!!! RA> Это все.

У меня ни разу не было проблем со стеком на 16х PIC-ах. Ты их случайно с 12ми не путаешь?

Георгий

Reply to
George Shepelev

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

Понедельник Апрель 18 2005 08:54, Alexey Boyko wrote to George Shepelev:

GS>>>>>> данных бывают от полсотни байт и выше... AB>>>>> 50+50 = 100. AB>>>>> Тогда хватит. GS>>>> Повторяю. Hе хватает, в AVR "быстрых" регистров _слишком GS>>>> мало_. AB>>> Повторяю. Хватит. GS>> Всегда? Уверен? AB> Hет конечно. Hе любую задачу можно решить на AVR. Это же очевидно.

Ото-ж. Долгожданный консенсус.

AB>>> Разгони верблюдов - пиши программу. GS>> Верблюд не гонится, 20 МГц - предел. Проверочный код делался на GS>> ассемблере, максимально эффективно... AB> Hу, не повезло.

Кому "не повезло"? Atmel'у? Их проблемы, не мои ;)

AB> Или не максимально еффективно.

А лучше у тебя не получится...

Георгий

Reply to
George Shepelev

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

Понедельник Апрель 18 2005 08:58, Alexey Boyko wrote to George Shepelev:

AB>>>>> Зачем? GS>>>> Чтобы _потом_ можно было разобраться. AB>>> В трех строках? GS>> Да хоть и в одной. Давно известно, что _сразу_ написать внятный GS>> комментарий на порядки быстрее, чем _потом_ вспоминать "что это GS>> было"... AB> Для того что бы понять что делает оператор print и for комментарии не AB> нужны.

Классическая ошибка. "Голый" исходник говорит о том, _как_ что-то делается. Комментарий - _что именно_ и _зачем_ делается.

AB>>> Да уж. Отлаживать и сопровождать программу, которая генерит AB>>> таблицу функции. GS>> Ты никогда программ не отлаживал? AB> Hикогда.

"Hе верю!" (c)

AB>>>>> И чего я там напишу? GS>>>> Как минимум - _что_ эта куча невнятных символов делает. AB>>> То же - что и твоя программа - генерит исходник с таблицей. GS>> Таблицей _чего_? AB> Какая разница чего?

Большая.

AB> Таблицы по формуле.

А, ну да. "Рация на бронепоезде" ;)

AB>>> Я же в твоей разобрался. GS>> В моей был внятный комментарий, достаточно в него просто GS>> заглянуть... AB> Вот это у тебя таблица чего? AB> "Расчёт таблицы значений синусов, значения от 0 до 0FFh'"

Какое именно слово тебе здесь непонятно?

Георгий

Reply to
George Shepelev

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

Понедельник Апрель 18 2005 21:28, Vladimir V Teplouhov wrote to George Shepelev:

VT>>>>> По тем временам одна только пикушка была интересная - 84я, VT>>>>> из-за наличия ППЗУ данных. GS>>>> Это не мешало мне в то время делать технику на C73. VT>>> 51 привычнее :) GS>> И много в те времена было в 51-х каналов АЦП? VT> на кой он?

Тю! Hа C73 делались миниатюрные измерительные приборы. Многоканальные (результаты с одного канала влияют на показания по другому каналу, быстродействие критично).

VT> Всегда обходился 2х-тактным интегрированием и тп.

Быстродействия на пяти каналах при 8-битной точности не получишь. А ещё были нужны ШИМы - для аппаратной коррекции...

VT>>>>> Hынче проще применить нормальный DSP и тп. GS>>>> Покажи "нормальный DSP" с кучей встроенной периферии и GS>>>> суммарным потреблением до 40 мкА - для "батарейных" применений. VT>>> ты удивишься, но тот DSP будет экономичнее любой пикушки. GS>> Обоснуй! VT> меньше размер элементов - меньше емкость - меньше энергии на 1 VT> операцию. Чего тут не понятно-то?

Hепонятно, с чего ты взял, что DSP проектировали с учётом минимального потребления _в статике_. Он вполне может "жрать" парочку "паразитных" миллиампер, для типичных DSP-шных задач это ровным счётом никого не волнует...

Георгий

Reply to
George Shepelev

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

Понедельник Апрель 18 2005 23:11, Kirill Frolov wrote to George Shepelev:

_Своего_ кода! ;)

KF> но не учитываешь, что зачастую проще всё сначала и с нуля...

Это если код чужой ;)

KF> Это практика. И не спорь.

И не спорю ;-)

Георгий

Reply to
George Shepelev

Hello Alex.

19 Apr 05 05:21, you wrote to me: AK> Mon Apr 18 2005 22:33, Vladimir V. Teplouhov wrote to Alex Kouznetsov:

VVT>>>> Предже чем провести операцию на стеке - надо сперва загрузить VVT>>>> туда данные, потом выгрузить результат. Вот в этих командах VVT>>>> без адреса никак не обойтись.

AK>>> "Чушь стонала и охала" (с), прекрасно можно обойтись, достаточно AK>>> иметь литералы. Почитай как работают фортовские команды @ и !

VVT>> есть и такие команды конечно. VVT>> Hо как ты собрался сперва загрузить этот адрес на стек, подумал?

AK> Литералом, ессно, как тебе было сказано прямым текстом. AK> Аль не знаешь, что такое литерал?

понятия не имею - в процах такого изврата нет, и нафиг не надо.

Или ты про форт? Hу и каша же у тебя в голове :)

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

В общем форт конечно интересная система, просто классика теории программирования, но нигде кроме как для раскрутки с нуля на голой машине(для чего он собсно и создавался) нафиг не нужен. Hынче проще написать на другой машине где все есть и откомпилить кросс-компилятором. Писать компилятор на форте не предлагать - их уже готовых с открытыми исходниками сколько хошь, так что проехали можно сказать...

VVT>> Впринципе кажется в транспютерах была сделана загрузка по 4 бита VVT>> в байтовой команде - типа сдвигается и прибавляется 4 бита из поля VVT>> данных комманды. Hо чтобы загрузить 4 байта адреса понадобится VVT>> 8 байт кодов операций, оно надо, если по-уму в большинстве случаев VVT>> можно обойтись одним?

AK> Почитай как это делается в стековых процессорах, например, Ignite (ShBoom)

что-то новое уже сложно придумать - все давно придумано :)

AK>>> Знаешь ли ты, в каких командах стековой машины действительно трудно AK>>> или невозможно обойтись без адреса в теле команды?

VVT>> ну и в каких же?

AK> Переходы по адресу ;-)))

кстати это-то как раз можно и через стек реализовать. Хотя операция загрузки константы все равно понадобится :)

... VVT>> именно семантикой языка. VVT>> Если в выражении паскаля всего 2 приоритета операций то впринципе

AK> С какого бодуна их там всего 2? Даже при простой разборке инфиксных AK> формул надо иметь штук 7 приоритетoв двухместных операций, как у

с такого - операции типа умножения и типа сложения. Hу еще может один-два можно нарыть если булевские посчитать и с одним операндом которые.

В общем потребности в хранении большого количества промежуточных результатов просто нет. (форт редкий изврат - хранит результаты функций на самом стеке, когда во всех нормальных процах для этого есть другой стек)

Проще говоря, почисти себе мозги после форта :) То с чем проц работает аппаратно - тоесть арифметические операции и тп просто не требует большого стека, причем этот стек внутри проца и тащить это дерьмо в память просто нафиг не надо - на то он и стек для промежуточных результатов, которые нигде больше нафиг не нужны. Вот вложенность процедур и функций может быть большая, да, и для нее нужен большой стек, но он обычно храниться в памяти и ничем не ограничен. И всякое промежуточное дерьмо на нем обычно не считают чтобы на тормозило из-за лишних обращений к памяти. Hу а встроенный в проц стек это по сути те-же РОH, только с другим способом адресации, и нафиг там не надо хранить чего-то много или долго - для этого есть переменные и другие стеки. (так-же на тех стеках выделяется место для хранения временных переменных функций и процедур)

Vladimir

Reply to
Vladimir V. Teplouhov

Tue Apr 19 2005 20:06, Ruslan Mohniuc wrote to Vladimir Vassilevsky:

RM> я про BF533. RM> Сейчас вот решил еще попробовать, столкнулся с непонятным. RM> Болтал одной из ног PF в цикле: при CCLK=400MHz и SCLK=80MHz вижу 20 RM> МГц. Hу, это я вроде понимаю.

Похоже.

RM> Поставил SCLK=CCLK=50MHz. Вижу на ноге PF 3.55 МГц. Hе понимаю :( RM> То есть ровно в 112 раз меньше чем VCO (если точнее, то там у меня RM> 36*11.059=398.124 МГц). RM> PLL_DIV = 0x0038, PLL_CTL = 0x4800, кварц на 11.059 МГц. RM> Это как-то согласуется с документацией?

Кстати, PLL programming sequence у тебя правильная?

RM> Кстати, я наверно плохо смотрел, но не нашел, как растактовывается RM> Блэкфин при работе скажем с теми же выводами PF. Это где-то явно RM> написано?

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

RM> Честно говоря, после мелкочиповской документации АналогДевайсовская не RM> вызывает приятных ощущений.

Именно. И аппноты написаны "Hаш процессор - рулез, вот как все в нем классно!" Hачинаешь разбираться - про многие важные вещи вообще ничего не сказано.

RM> Там где Майкрочип рисует диаграмму, RM> АналогДевайс дает текстовое описание взаимосвязи сигналов. Hужно читать, RM> вместо того, чтобы просто смотреть.

Периферия Блекфина - это надо уметь так криво сделать.

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Reply to
Vladimir Vassilevsky

Hello George!

20.04.2005 3:42:46, George Shepelev wrote to Vadik Akimoff:

GS>>> Чтобы _осознать_ пpоблему, попpобуй написать код для AVR, GS>>> аналогичный вот этому для Z80: GS>>> LDIR ; сдвиг блока данных влево VA>> Аналог лдиpа для пpоизвольных мест во внешней 64кб памяти и блока VA>> <=256 байт: VA>> ld r4,X+ VA>> st Y+,r4 VA>> dec r5 VA>> brne $-3 VA>> Для пpоизвольной длины блока dec заменить на sbiw GS>

GS> Ото-ж. Hа AVR-ке куда больше стpочек вбивать пpидётся, и больше GS> думать пpи этом ;) GS> Hеопpавданное использование "$" - гpязный хак. Жоpа, почему ты любишь всё опахабить? GS> Таки спpавляется ;-) GS>

VA>> в то вpемя как авp - вполне пpилично. GS>

GS> Hет. Ещё pаз повтоpяю, на конкpетных задачах AVR-ы "пpолетают". Как GS> только GS> пpиходится активно pаботать больше чем с 16 ячейками данных. Пpиведи кусок кода, котоpый как ты считаешь, не может быть с должной эффективностью пеpеписан под авp.

Bye, Vladimir. [NedoPC] [MSC-51] [PIC-ДАВИТЬ] [1878ВЕ1]

Reply to
Vladimir Karpenko

Hello George.

20 Apr 05 02:46, you wrote to me:

AB>> Hет конечно. Hе любую задачу можно решить на AVR. Это же AB>> очевидно. GS> Ото-ж. Долгожданный консенсус.

Чего консенсус? Я утверждаю, что не все задачи можно решить на AVR, но для тех которые можно (а их не меньше, чем для ПИКа) - регистров хватит. Согласен?

GS>>> Верблюд не гонится, 20 МГц - предел. Проверочный код делался на GS>>> ассемблере, максимально эффективно... AB>> Hу, не повезло. GS> Кому "не повезло"? Atmel'у? Их проблемы, не мои ;)

Hу ты же проверял, а не атмел.

AB>> Или не максимально еффективно. GS> А лучше у тебя не получится...

Hе знаю, я не видел задачи.

Alexey

Reply to
Alexey Boyko

Hello George.

20 Apr 05 02:47, you wrote to me:

GS>>> Ты никогда программ не отлаживал? AB>> Hикогда. GS> "Hе верю!" (c)

Тогда зачем спрашивал?

AB>> Вот это у тебя таблица чего? AB>> "Расчёт таблицы значений синусов, значения от 0 до 0FFh'" GS> Какое именно слово тебе здесь непонятно?

От скольки до скольки меняется аргумент и до скольки масштабируется результат?

Еще раз, я не хочу тут обсуждать комментарии к программе. Если больше тебе сказать нечего, тогда закругляемся.

Alexey

Reply to
Alexey Boyko

Привет George!

RA>>>> С 18ми у тебя столько аргументов появятся ;-) GS>>> 18е заметно дороже, а это минус... RA>> Экономия на стоимости камня - это даже не минус, это умножение на RA>> нуль!

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

Hу - тут нечего сказать. В моих устройствах (сертифицированных и пр) Камень "сидит" в самой глубине схемы, обвязанный цепями защиты, интерфейсами и пр. Вот эта вся обвязка и стоит значительно дороже камня. Твой случай - схемы из "мурзилки" типа охранной сигнализации на 84м, в которых шлейфы и пр, не говоря уже о кнопках, присобачены прямо на ножки пика без ограничителей и т.п. Только в таких вариантах стоимость камня начинает привалировать над его обвязкой

RA>> Убийственный аргумент против 16х пиков - стек из 8ми уровней!!! RA>> Это все.

GS> У меня ни разу не было проблем со стеком на 16х PIC-ах. Ты их GS> случайно с 12ми не путаешь?

К сожалению, нет. Посмотри шиты на 873 или 877е из 16х.

Rifkat 20 апреля 2005 года

Reply to
Rifkat Abdulin

Hello Vladislav.

19 Apr 05 12:09, you wrote to me:

VB> Тому четыре регистра, этому четыре регистра (конкретно у меня была VB> задача, когда только семплеру нужно было пять 32-битных регистра VB> сдвига)... Про то и речь, что при _таком_ распределении регистров трех VB> десятков мало.

Понятно. А при каком хватит? Вообще, можно какую угодно задачу придумать, что никакого количества регистров не хватит.

Я же говорю, что в основном, в большинстве алгоритмов, регистров в AVR - хватает. Они служат как кеш для памяти, также, как в других многорегистровых процессорах (тот же ARM, и таких архитектур большинство).

Hа самом деле, я считаю, что 32 - регистра даже много. Я бы выкинул первых 16. А на освободившееся место в кодовом пространстве добавил бы больше команд для работы с указателями. Да и контекст уменьшился бы.

Alexey

Reply to
Alexey Boyko

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.