Embedded OS

Hello George.

14 Apr 05 08:05, you wrote to Vladimir V Teplouhov: GS> Среда Апрель 13 2005 05:02, Vladimir V Teplouhov wrote to George Shepelev: ... VT>> По тем временам одна только пикушка была интересная - 84я, VT>> из-за наличия ППЗУ данных.

GS> Это не мешало мне в то время делать технику на C73.

51 привычнее :)

VT>> Hынче проще применить нормальный DSP и тп.

GS> Покажи "нормальный DSP" с кучей встроенной периферии и суммарным GS> потреблением до 40 мкА - для "батарейных" применений.

ты удивишься, но тот DSP будет экономичнее любой пикушки. Он на 400 МГц меньше ватта ест, теперь посчитай сколько будет на 1 операцию, и учти что там разрядов дофига - одна комманда DSP заменяет десятки-сотни пика и тп.

Vladimir

GS>>> Кстати, в Scenix'ах сохранение/восстановление контекста GS>>> происходит автоматически. RA>> Уйди на 18е пики - кошмары сразу прекратятся ;-)

GS> А нету кошмаров. Меня и 16е особо не напрягают...

Напрягают, напрягают ;-) Раз все время в потасовки типа ... vs pic ввязывешься. С 18ми у тебя столько аргументов появятся ;-)

Привет Vladimir!

Saturday April 16 2005 08:35, Vladimir V Teplouhov wrote to George Shepelev:

GS>> Покажи "нормальный DSP" с кучей встроенной периферии и суммарным GS>> потреблением до 40 мкА - для "батарейных" применений. VT>

VT> ты удивишься, но тот DSP будет экономичнее любой пикушки. VT> Он на 400 МГц меньше ватта ест, теперь посчитай сколько VT> будет на 1 операцию,

А какая разница? С падением тактовой потребляемая мощность вовсе не обязана падать линейно, поэтому ожидать что при 4мгц он будет потреблять не 1вт а 10мВт ? Совсем не обязательно.

VT> и учти что там разрядов дофига - одна комманда DSP заменяет VT> десятки-сотни пика и тп.

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

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

, ftp://altor.sytes.net

[Жора, не хами !]

Приветствую, Vladislav!

Однажды, 15.04.05 18:44:05, Vladislav писал к Alexey Boyko по поводу "Понеслась...".

AB>> Ты так и не понял. Редко когда обрабатывается просто одна ячейка. Обычно AB>> обрабатываются блоки каких-то данных.

VB> А что, блок загружается как-то иначе или с меньшими затратами, чем VB> отдельно взятые ячейки ?

Для работы с блоками в Z80 специальные команды были. Какие именно - не помню, давно это было, лет эдак 7 назад.

-- С уважением, Andrew O. Shadoura

Пpивет, Andrew!

*** 17 Apr 05 05:51, Andrew O Shadoura wrote to Vladislav Baliasov:

AB>>> Ты так и не понял. Редко когда обрабатывается просто одна AB>>> ячейка. Обычно обрабатываются блоки каких-то данных.

VB>> А что, блок загружается как-то иначе или с меньшими затратами, VB>> чем отдельно взятые ячейки ?

AS> Для работы с блоками в Z80 специальные команды были. Какие именно - не AS> помню, давно это было, лет эдак 7 назад.

Речь a) шла о AVR, конкретно о загрузке регистров из оперативной памяти; b) Z80 умел делать блочные пересылки и сравнение, но на памяти. А тут - про работу с регистрами.

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

Sat Apr 16 2005 09:26, Vladimir V. Teplouhov wrote to Alex Kouznetsov:

VVT>>>>> впринципе если применить те-же методы, что и применяются в VVT>>>>> безадресных системах комманд, то в 2 байта кода операции легко VVT>>>>> умещаются 3 адреса,

AK>>>> Поясни подробнее, что ты имеешь ввиду, если можно - с примерами. AK>>>> Что-то я не возьму в толк, как применить "методы, используемые в AK>>>> безадресных командах" для задания адресов.

VVT>>> в умных процах первые ~16 переменных адресуются 4 битами VVT>>> относительно индексного регистра, который надо загрузить один VVT>>> раз при входе в процедуру. Есть 2 регистра - для локальных VVT>>> и для глобальных переменных...

AK>> А, адрес в поле команды все-таки есть, хоть и неполный. В безадресных AK>> командах его нет вообще.

VVT> в самих командах их нет - это в командах загрузки/выгрузки на стек так.

Туманно выражаешься.

VVT> Впринципе ничто не мешает иметь и такие команды с адресами, но просто VVT> не нужно - проще работать через стек, причем еще и быстрее тк не надо VVT> тратить время на обращение к памяти.

Создавал ли ты виртуальные стековые машины?

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

Ты говоришь это на основе собственного опыта и знаний, или это твои фантазии и иллюзии, навеянные упомянутой тобой "книжкой из библиотеки", которую ты когда-то видел? Какие у тебя есть основания, чтобы заявлять, что "компилятор всегда может..."? Писал ли ты когда-нибудь на форте? Судя по твоим шапкозакидательским высказываниям - не писал...

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

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

Суббота Апрель 16 2005 08:11, Rifkat Abdulin wrote to George Shepelev:

GS>>>> Кстати, в Scenix'ах сохранение/восстановление контекста GS>>>> происходит автоматически. RA>>> Уйди на 18е пики - кошмары сразу прекратятся ;-) GS>> А нету кошмаров. Меня и 16е особо не напрягают... RA> Hапрягают, напрягают ;-)

Давай договоримся, я сам буду решать, что меня напрягает, а что нет ;)

RA> Раз все время в потасовки типа ... vs pic ввязывешься.

Hе аргумент ;-)

RA> С 18ми у тебя столько аргументов появятся ;-)

18е заметно дороже, а это минус...

Георгий

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

Суббота Апрель 16 2005 08:35, Vladimir V Teplouhov wrote to George Shepelev:

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

И много в те времена было в 51-х каналов АЦП?

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

Обоснуй!

VT> Он на 400 МГц меньше ватта ест,

И что? Мне не нужно 400 МГц, мне нужно до 40 мкА. С учётом _всей_ задействованной периферии, включая WDT.

VT> теперь посчитай сколько будет на 1 операцию,

Это не считается, а берётся из даташита производителя. Погляди что именно там записано...

Георгий

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

Суббота Апрель 16 2005 13:33, Kirill Frolov wrote to George Shepelev:

О, да!

Георгий

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

Суббота Апрель 16 2005 13:35, Kirill Frolov wrote to George Shepelev:

Вместе с writeonly "проектом" ;)

KF> Ибо на документацию, отладку и сопровожение ещё неделя нужна...

Hеотлаженная и недокументированная программа вообще никому не нужна!

Георгий

Hello Alexander.

17 Apr 05 00:13, you wrote to Vladimir V Teplouhov: AT> Saturday April 16 2005 08:35, Vladimir V Teplouhov wrote to George AT> Shepelev:

GS>>> Покажи "нормальный DSP" с кучей встроенной периферии и суммарным GS>>> потреблением до 40 мкА - для "батарейных" применений. VT>>

VT>> ты удивишься, но тот DSP будет экономичнее любой пикушки. VT>> Он на 400 МГц меньше ватта ест, теперь посчитай сколько VT>> будет на 1 операцию,

AT> А какая разница? С падением тактовой потребляемая мощность вовсе не AT> обязана падать линейно, поэтому ожидать что при 4мгц он будет потреблять AT> не 1вт а 10мВт ? Совсем не обязательно.

так, еще раз попался :) Могу обрадовать - не ты первый - до этого несколько студентов...

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

VT>> и учти что там разрядов дофига - одна комманда DSP заменяет VT>> десятки-сотни пика и тп.

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

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

Vladimir

Привет Vladimir!

Sunday April 17 2005 21:18, Vladimir V Teplouhov wrote to Alexander Torres:

AT>> А какая разница? С падением тактовой потребляемая мощность вовсе не AT>> обязана падать линейно, поэтому ожидать что при 4мгц он будет AT>> потреблять не 1вт а 10мВт ? Совсем не обязательно. VT>

VT> так, еще раз попался :) VT> Могу обрадовать - не ты первый - до этого несколько студентов...

Да уж конечно...

VT> А слабо на проце вообще не кмоп линейно потребление понизить? VT> Hамек - никто не запрещает завести сигнальчик на БП и рубить VT> его вообще нафиг когда не нужен... У меня было так в одном

Hамек - режим "слип" ии "шатдаун" - есть на многих МК.

VT>>> и учти что там разрядов дофига - одна комманда DSP заменяет VT>>> десятки-сотни пика и тп. VT>

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

VT> ну это сравнивать надо. VT> В любом случае нынешние DSP мало чем отличаются от обычных

Вот ты пока пойди, посравнивай, потом доложишь.

VT> процов по возможностям, разве что немного заточен под видео.

Видео тут причем? или ты ДСП кроме как в компе ниге не видел ? :)

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

, ftp://altor.sytes.net

Hello Alex.

17 Apr 05 11:36, you wrote to me: AK> Sat Apr 16 2005 09:26, Vladimir V. Teplouhov wrote to Alex Kouznetsov: ... AK>>> А, адрес в поле команды все-таки есть, хоть и неполный. В AK>>> безадресных командах его нет вообще.

VVT>> в самих командах их нет - это в командах загрузки/выгрузки на стек VVT>> так.

AK> Туманно выражаешься.

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

VVT>> Впринципе ничто не мешает иметь и такие команды с адресами, но просто VVT>> не нужно - проще работать через стек, причем еще и быстрее тк не надо VVT>> тратить время на обращение к памяти.

AK> Создавал ли ты виртуальные стековые машины?

всяко извращался, раньше я много теорией программирования и архитектурами процов занимался.

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

AK> Ты говоришь это на основе собственного опыта и знаний, или это твои AK> фантазии и иллюзии, навеянные упомянутой тобой "книжкой из библиотеки", AK> которую ты когда-то видел? Какие у тебя есть основания, чтобы заявлять, AK> что "компилятор всегда может..."?

определяется семантикой языка.

AK> Писал ли ты когда-нибудь на форте?

писал конечно - грех такой изврат не попробовать :) Правда на практике всегда можно обойтись и без него более привычными средствами, но сам по себе он довольно интересный.

AK> Судя по твоим шапкозакидательским высказываниям - не писал...

и даже для МК-61 писал :)

Кстати в транспьютерах стек тоже всего 4 регистра - хватает. (в кроносе вроде 7 или 8 был) Слишком большой стек на практике и не нужен - проще считать сразу(в языках вроде паскаля всего 2 уровня приоритетов в арифметике, так что много пром. данных хранить не надо), а при вызове прерывания и тп будет сильно тормозить при большом стеке и в тп местах.

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

Vladimir

Sun Apr 17 2005 22:41, Vladimir V. Teplouhov wrote to Alex Kouznetsov:

AK>>>> А, адрес в поле команды все-таки есть, хоть и неполный. В AK>>>> безадресных командах его нет вообще.

VVT>>> в самих командах их нет - это в командах загрузки/выгрузки на стек VVT>>> так.

AK>> Туманно выражаешься.

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

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

VVT>>> Впринципе ничто не мешает иметь и такие команды с адресами, но просто VVT>>> не нужно - проще работать через стек, причем еще и быстрее тк не надо VVT>>> тратить время на обращение к памяти.

AK>> Создавал ли ты виртуальные стековые машины?

VVT> всяко извращался, раньше я много теорией программирования VVT> и архитектурами процов занимался.

Напомнил присказку про то, как кот в школу ходил: "все классы прошел, ни одного не пропустил" (с) ;-) Знаешь ли ты, в каких командах стековой машины действительно трудно или невозможно обойтись без адреса в теле команды?

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

AK>> Ты говоришь это на основе собственного опыта и знаний, или это твои AK>> фантазии и иллюзии, навеянные упомянутой тобой "книжкой из библиотеки", AK>> которую ты когда-то видел? Какие у тебя есть основания, чтобы заявлять, AK>> что "компилятор всегда может..."?

VVT> определяется семантикой языка.

В огороде бузина...

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

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

Воскресенье Апрель 17 2005 09:41, Vladislav Baliasov wrote to Andrew O Shadoura:

AB>>>> Ты так и не понял. Редко когда обрабатывается просто одна AB>>>> ячейка. Обычно обрабатываются блоки каких-то данных. VB>>> А что, блок загружается как-то иначе или с меньшими затратами, VB>>> чем отдельно взятые ячейки ? AS>> Для работы с блоками в Z80 специальные команды были. Какие именно AS>> - не помню, давно это было, лет эдак 7 назад. VB> Речь a) шла о AVR, конкретно о загрузке регистров из оперативной VB> памяти; b) Z80 умел делать блочные пересылки и сравнение, но на VB> памяти.

Так ведь блоки данных почти наверняка будут в памяти, в набор РОH они не влезут. То, что на AVR их приходится перетаскивать через "игольное ушко" РОH'ов - недостаток архитектуры контроллера. Чтобы _осознать_ проблему, попробуй написать код для AVR, аналогичный вот этому для Z80:

... ; бегущая строка - сдвиг символов влево, очередной символ в аккумуляторе LD DE,pos_buff ; адрес начала буфера LD HL,pos_buff+1 ; адрес первого сдвигаемого символа LD BC,len_buff-1 ; число сдвигаемых символов LDIR ; сдвиг блока данных влево new_symb: LD (DE),A ; очередной символ вдвигается в буфер ...

... ; бегущая строка - сдвиг символов вправо, очередной символ в аккумуляторе LD DE,pos_buff+len_buff-1 ; адрес конца буфера LD HL,pos_buff+len_buff-2 ; адрес первого сдвигаемого символа LD BC,len_buff-1 ; число сдвигаемых символов LDDR ; сдвиг блока данных вправо JR new_symb

VB> А тут - про работу с регистрами.

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

Георгий

Hi!

In a message of 18 Apr 05 George Shepelev wrote to Vladislav Baliasov:

GS> Чтобы _осознать_ проблему, попробуй написать код для AVR, GS> аналогичный вот этому для Z80:

GS> LDIR ; сдвиг блока данных влево

Аналог лдира для произвольных мест во внешней 64кб памяти и блока <=256 байт:

ld r4,X+ st Y+,r4 dec r5 brne $-3

Для произвольной длины блока dec заменить на sbiw

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

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

Именно пик (у которого, как многие считают, вся внутренняя рам - регистры) с трудом справляется, в то время как авр - вполне прилично.

Bye...