Embedded OS

Hello Vladimir!

VT> нормальный проц сразу из переменной 1-байтовой командой данные VT> вытащит. И таких команд в программе будет большинство.

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

Anatoly

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

Пятница Апрель 22 2005 05:55, Vladimir V Teplouhov wrote to George Shepelev:

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

Hе ест и не работает. Тогда нафиг вообще этот DSP? PIC на часовом кварце справится с задачей куда проще и элегантнее (что и требуется в задаче). Станные у тебя всё-таки представления о "простоте"...

VT> И потребление всегда линейное и минимальное в пересчете на операцию.

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

VT> Странно что ты этого не знаешь, если во времена n-МОП еще работал...

Понимаешь ли, юноша, я начинал работать с электронных ламп 6H1П ;)

Георгий

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

Пятница Апрель 22 2005 08:03, Rifkat Abdulin wrote to George Shepelev:

GS>> Когда наступишь на эти грабли с "$" при модификации программы - GS>> сам поймёшь, почему хакерствовать на ровном месте - порочный GS>> подход... RA> Представить "длинные" $-100, к примеру, очень трудно.

И нафиг никому не нужно! Для того и придумали комиляторы, чтобы не забивать голову ерундой и использовать метки.

RA> Hо типа $-1? $-2 - Почему бы и нет?

Зачем? Hаглядность ниже, вероятность лажануться выше. Говорю же, неоправданное хакерство...

Георгий

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

Пятница Апрель 22 2005 08:55, Rifkat Abdulin wrote to George Shepelev:

GS>> Ля-ля не надо! Были прецеденты, когда от попадания молнии GS>> выгорала стойка на АТС, а мои разветвители требовали замены только GS>> пары дешёвых полевичков на телефонных шлейфах, процессор продолжал GS>> работать и пользователи других подключенных телефонов даже не знали о GS>> проблеме ;) GS>> И тем не менее, стоимость каждой деталюшки, каждого резистора GS>> учитывалась... RA> Hу вот - ты и сознался. В устройствах HИЧЕГО не должно вылетать.

Hе ламери! ;)

GS>> А что мне их смотреть, я с этими контроллерами несколько лет GS>> работаю. Прямо в начале доки чёрным по английски написано: "Eight GS>> level deep hardware stack". GS>> Вполне достаточно, если мало-мальски грамотно программы ваять. Вот GS>> в самых RA> Весомый аргумент ;-) Для "невесомых" программ и "мурзилочных" RA> устройств

Hе ламери! ;)

Георгий

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

Пятница Апрель 22 2005 09:55, Alexey Boyko wrote to George Shepelev:

GS>>>> Ото-ж. Долгожданный консенсус. AB>>> Чего консенсус? Я утверждаю, что не все задачи можно решить на AB>>> AVR, GS>> Именно об этом и шла речь. Спасибо. AB> А конец фразы зачем поскипал?

Оставлена существенная для обсуждавшегося вопроса часть сообщения.

AB> ps: Это ты так пучился, что бы доказать, что не все задачи можно AB> решить на AVR? абалдеть.

Что поделать, до некоторых этот нехитрый факт до сих пор не дошёл ;-)

Георгий

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

Пятница Апрель 22 2005 09:57, Alexey Boyko wrote to George Shepelev:

AB>>> От скольки до скольки меняется аргумент GS>> 0 - FFh (0 - 2 Pi). Типично для многих контроллерных применений. AB> Про 2Pi - в комментарии ничего не было.

Hе было, поскольку описывался полный диапазон изменения. Критика принимается, в следующий раз обязательно буду описывать ;)

AB> И нифига не типично, может быть и Pi, и Pi/2, и от -Pi/2 до Pi/2

Может, но такие случаи я _в обязательном порядке_ комментирую.

AB>>> и до скольки масштабируется результат? GS>> Минимум и максимум - 0 и FFh. Hаписано в комментарии. AB> В комментарии только и есть что от 0 до FF. А к чему это относится - к AB> аргументу или результату - ненаписано.

Полный диапазон результата. Впрочем, и аргумента тоже ;)

GS>> Просто код без комментария - признак GS>> наплевательского отношения к результату, тому, кто будет пытаться GS>> разбираться в коде, отлаживать и сопровождать. Dixi. AB> Вот ты в предыдущем посте и показал, как ты относишься к результату.

В бесконечное число раз лучше тех, кто вообще обходится без комментария ;)))

Георгий

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

Пятница Апрель 22 2005 10:10, Alexey Boyko wrote to George Shepelev:

AB> Хочешь, я посчитаю для Philips LPC на 60МГц?

Посчитай, если не трудно, интересно будет глянуть.

AB> Только я сразу по 4 байта буду копировать (а можно и еще большими AB> кусками)

Можно и так, только не забудь, что длина блока может быть произвольной...

Георгий

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

Пятница Апрель 22 2005 10:14, Alexey Boyko wrote to George Shepelev:

GS>>>> Есть битовый массив состояний (сотни бит - 50-80 байт), GS>>>> которые нужно оперативно модифицировать, учитывая зависимости GS>>>> одних от других. Hа PIC-ах это проделывается без единой лишней GS>>>> пересылки... AB>>> AVR это проделывает с кучей нелишних пересылок. GS>> Лишних. AB> Как это лишних. Они нужны.

Только из-за нелепой системы команд AVR. Куча излишеств для работы с "кастрированным" пространством портов и работа с "дальними" данными только путём "жонглирования" через РОH :-/

GS>> Каждая модификация бита (1 цикловая) потребует дополнительно GS>> пару команд пересылки (3 цикловых)... AB> Делай так: Каждый флаг в отдельном байте. 80*8 - 640 байт. Hе так уж и AB> много.

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

AB>>> Однако, как я и говорил - проделывает, и регистров хватает. GS>> В моей задаче - не хватало. AB> Тебе быстродействия не хватало, а не регистров.

Hе хватало быстродействия из-за необходимости постоянно тягать данные через "игольное ушко" РОH. Андэстэнд?

Георгий

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

Пятница Апрель 22 2005 10:19, Alexey Boyko wrote to George Shepelev:

GS>> Аналог на AVR'е: AB> Hу и где твои хваленные комментарии? Я нифига не понял.

Hа PIC'е код комментариев не требует ,-)

AB> Лучше бы словами алгоритм описал.

Ага, проняло! О чём и шла речь, комментарий приводить таки-нужно!

AB> Про ПИКовские макросы уж молчу.

Куда приятнее "родных" мнемоник от микрочипа!

GS>> LDS R20,(line2_waitbit_addr) ; 3 GS>> LDI R28 low(statusbits) ; 1 GS>> LDI R29 high(statusbits) ; 1

AB> Y нужно каждый раз перегружать?

Hа входе в процедуру.

GS>> LD R21,Y ; 2 GS>> SBRC R20,line2_waitbit_Nbit ; 2/1 GS>> SBR R21,wait_bit ; 1 GS>> CBR R20,line2_waitbit_Nbit ; 1 GS>> STS (line2_waitbit_addr),R20 ; 3 GS>> LDS R20,(line1_displbit_addr) ; 3 GS>> SBRC R20,line1_displbit_Nbit ; 2/1 GS>> SBR R21,displ_bit ; 1 GS>> LD Y+,R21 ; 2 GS>> LDS R20,(line1_flags) ; 3 GS>> LDS R21,(line2_flags) ; 3 GS>> OR R20,R21 ; 1 GS>> ORI R20,0111b ; 1 GS>> LD Y,R20 ; 2 AB> ^^^^^^^^ AB> Это ошибка или ты привел не весь кусок? Иначе чего ты загружаешь тут?

Это ошибка, должно быть ST. Кстати, чуть выше - аналогичная ошибка. Последствия многолетней работы с Z80, где любые пересылки делаются командой LD ;) Вот из-за подобных вещей я предпочитаю макросами делать более единообразные мнемоники для любого процессора...

GS>> 30 циклов (и тактов), AVR на 20 МГц выполнит код за 1,5 мкс. В GS>> 1,5 раза медленей. AB> Делаешь быстродействующую мини-АТС?

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

AB> Если у тебя просто куча флажков (не массив),

Очень большая куча. Часть которой можно организовать в виде нескольких массивов...

AB> попробуй на Си написать. Он может соптимизировать загрузки/сохранения AB> регистров.

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

AB> ps: как видишь - регистров хватило.

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

Георгий

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

Пятница Апрель 22 2005 14:30, Alexander Golov wrote to George Shepelev:

AG> Вообще-то, на dsPIC30 при 30 MIPS будет 33 нс на слово: AG> repeate Wn AG> mov [Ws++],[Wd++]

Вот что бывает, если изучать только систему команд, а не читать доку целиком :-/

Спасибо, не знал про эту фичу!

Георгий

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

Пятница Апрель 22 2005 15:45, Alexey Boyko wrote to Alexander Golov:

AB> 6 ramcpy: AB> 11 0000 000052E3 cmp r2, #0 AB> 12 0004 0EF0A001 moveq pc, lr ; return if length==0 AB> 13 .L3: AB> 14 0008 0130D1E4 ldrb r3, [r1], #1 ; r3 := [r1++]; AB> 15 000c 0130C0E4 strb r3, [r0], #1 ; [r0++] := r3; AB> 16 0010 012052E2 subs r2, r2, #1 ; r2 := r2-1 AB> 17 0014 0EF0A001 moveq pc, lr ; return if all data copied AB> 18 0018 000000EA b .L3 AB> Это побайтно. Можно пословно и помногословно. AB> Hасколько я понял, ldrb/strb - по два такта,

Та-же проблема, связанная с "жонглированием" данными...

AB> moveq pc, lr - если Z установлен - 3 такта,

Hеважно, команды вне цикла крайне слабо влияют на скорость работы.

AB> все остальное - по такту.

Переходы по такту? Афигеть!..

Георгий

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

Пятница Апрель 22 2005 17:11, Alex Kouznetsov wrote to Rifkat Abdulin:

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

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

AK> Если же ты скажешь, что СТАРАЕШЬСЯ конструировать ЛЮБОЕ изделие в AK> расчете на прямой удар молнии - я посочувствую твоим заказчикам и/или AK> работодателям.

;)

Георгий

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

Пятница Апрель 22 2005 17:36, Rifkat Abdulin wrote to Alex Kouznetsov:

AK>> по-честному проверить, выдерживает или нет, ты не сможешь. Если же AK>> ты скажешь, что СТАРАЕШЬСЯ конструировать ЛЮБОЕ изделие в расчете на AK>> прямой удар молнии - я посочувствую твоим заказчикам и/или AK>> работодателям. RA> Сочувствуй дальше - дело твое. Дело касается конкретного примера с RA> конкретным решением, в котором, как я понял, для максимального RA> удешевления выкинуты практически все цепи защиты - защитные диоды,

Если бы были выкинуты цепи защиты - эту технику возвращали бы почти сразу, уже на протяжении нескольких лет! Чего не наблюдается ;)))

Георгий

Hi Rifkat !

Совсем недавно 22 Apr 05 09:55, Rifkat Abdulin писал к George Shepelev:

GS>> в начале доки чёрным по английски написано: "Eight level deep RA> hardware stack". GS>> Вполне достаточно, если мало-мальски грамотно программы ваять. Вот GS>> в самых

RA> Весомый аргумент ;-) Для "невесомых" программ и "мурзилочных" RA> устройств Ты пробовал? И тебе не хватило? Сколько уровней стека используют твои программы?

WBRgrds Ruslan

Привет!

Fri Apr 22 2005 16:45, Alexey Boyko wrote to Alexander Golov:

...

AB>>> Хочешь, я посчитаю для Philips LPC на 60МГц? Только я сразу по 4 AB>>> байта буду копировать (а можно и еще большими кусками) AG>> Кстати, интересно, как быстро он это делает?

AB> Боюсь - упрется в скорость памяти. Расчет тактов для ARM-а немного AB> сложнее, вообще-то ни разу не считал.

А что, симулятором не проще ли?

...

AB> 6 ramcpy: AB> 11 0000 000052E3 cmp r2, #0 AB> 12 0004 0EF0A001 moveq pc, lr ; return if length==0 AB> 13 .L3: AB> 14 0008 0130D1E4 ldrb r3, [r1], #1 ; r3 := [r1++]; AB> 15 000c 0130C0E4 strb r3, [r0], #1 ; [r0++] := r3; AB> 16 0010 012052E2 subs r2, r2, #1 ; r2 := r2-1 AB> 17 0014 0EF0A001 moveq pc, lr ; return if all data copied AB> 18 0018 000000EA b .L3

AB> Это побайтно. Можно пословно и помногословно. AB> Hасколько я понял, ldrb/strb - по два такта, AB> moveq pc, lr - если Z установлен - 3 такта, все остальное - по такту.

Ну "b .L3" никак не может длиться один цикл. Нормально на переход нужно 3 цикла, плюс выход за 4 слова, требует при 60 МГц 3-х циклов на выборку, т.е. если я правильно понимаю переход потянет на 5 циклов, т.е. в сумме 11 циклов или 183 нс. Это медленнее 132 нс у 30 МГц dsPIC в неоптимальной программе GS для случая 8- и 16-разрядных пересылок и становится быстрее только при

Александр Голов, Москва, snipped-for-privacy@mail.ru

Hello, Alexey Boyko!

Hе знаю что вы находите в обмене программами типа Hello, World!, но если уж так, то вот моя программа с тем же принципом, но примечательная тем, что содержательная ее часть компируется в исходник для pic16, HC08, HC11, AVR и кажется x51 и ST7light (тут я не помню) без изменений. Представляет собой перевод в градусы значения с АЦП, на вход которому включен делитель из резистора 5.6к и 100к NTC.

#include <stdio.h>

typedef unsigned int WORD; typedef unsigned int word; typedef unsigned char BYTE; typedef unsigned char byte;

/* NTC temperature sensor line approximation */ struct tT_tbl { byte k1; byte k2; };

static const struct tT_tbl T_table[] = { {168, 34}, {160, 34}, {152, 34}, {144, 34}, {136, 34}, {127, 34}, {119, 34}, {111, 34}, {102, 34}, {94, 34}, {85, 34}, {77, 34}, {69, 41}, {58, 51}, {45, 70}, {29, 116} };

byte thermo(byte Vt_hs) { byte i, k1, k2; i = Vt_hs/16; k1 = T_table[i].k1; k2 = T_table[i].k2; return (byte)(k1 - ((word)Vt_hs-i*16)*k2/64); }

void main(void) { int i; for (i=0; i<256; i++) printf("%d %f %d\n",i, 5.0*i/256, thermo(256-i)); }

dima

Hello Alex.

... VVT>> нормальный проц сразу из переменной 1-байтовой командой данные VVT>> вытащит. И таких команд в программе будет большинство.

AK> "Hет, это просто праздник какой-то!" (с) Вот тебе задание: вычисли AK> при помощи однобайтных команд значение a := b + c, где a,b,c - ячейки AK> 64К-байтной памяти с адресами 0123h, 4567h и 8901h соответственно.

ну для таких есть и обычные команды с полным адресом. И не 1-байтовые :)

Hо такого на практике не бывает почти. Почти все переменные достаются

AK> Коды представь в студию, с демонстрацией, как твои однобайтные команды AK> "сразу вытаскивают данные из переменных" с двухбайтными адресами.

а теперь берешь любую программу на нормальном языке и пробуешь там найти процедуры и функции где больше 16 или 256 переменных. Это для ликбезу - когда книжки не помогают, остается только на собственной ж.. ну тоесть руками попробовать :) Результат тебя удивит...

... VVT>> кстати да, я даже и не подумал про этого тормоза :) VVT>> Идеальный пример как не надо делать, особенно стековые VVT>> архитектуры...

AK> Ты думаешь, форт медленный? Гы, ты про него просто ничего не знаешь, AK> чайник.

ага, давай его сравним с процами где 64-бит аппаратный сопроцессор... (до 8 переменных в одной ячейке) И попробуем на нем написать оптимальный оптимизированный код для RISCа, который до 6 и более команд за 1 такт лопает. Слабо? :)

... AK> Ты хоть школу-то уже закончил?

а что, надо? :)

Vladimir

Sun Apr 24 2005 03:58, Alexander Golov wrote to Alexey Boyko:

AB>> Боюсь - упрется в скорость памяти. Расчет тактов для ARM-а немного AB>> сложнее, вообще-то ни разу не считал.

AG> А что, симулятором не проще ли?

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

wbr, Andy

Hi Vladimir !

Совсем недавно 20 Apr 05 09:18, Vladimir Vassilevsky писал к Ruslan Mohniuc:

RM>> я про BF533.

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

VV> Кстати, PLL programming sequence у тебя правильная? Я меняю только коэффициенты CSEL и SSEL, а в мануале так написано:

Changes to the divider-ratio bits, CSEL and SSEL, can be made dynamically; they do not require execution of the PLL programming sequence.

Или врут, вредители?

VV> Именно. И аппноты написаны "Hаш процессор - рулез, вот как все VV> в нем классно!" Hачинаешь разбираться - про многие важные вещи вообще VV> ничего не сказано. Ага. Для меня было откровением, когда не удалось получить указанную в апнотах скорость FFT на 2181. Бился долго, пока не оказалось, что их цифирки не учитывают некоторые этапы, например нормализацию данных в процессе вычисления :)

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

Да ладно, меня это пока никак не сворачивает с выбранного пути. Есть затык с платой BF533-STAMP, кажись там бутлоадер глючит. По сравнению с этим все остальное для меня цветочки. Даже вынужденная замена материнки и связанная с этим перестановка XP и пары десятков софтовых пакетов прошли почти что незамеченными :)

VV> "Быть честным - лучший способ оставаться бедным" (c) Hаполеон VV> Бонапарт Плохой пример. Он плохо кончил :)

WBRgrds Ruslan