Embedded OS

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

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

GS>> Если бы были выкинуты цепи защиты - эту технику возвращали бы почти GS>> сразу, уже на протяжении нескольких лет! Чего не наблюдается ;))) RA> Я рад за тебя. Hо - что за полевики на шлейфах, если не секрет?

В разных версиях разное ставили. Скорее всего что-нибудь из серии КП50x.

Георгий

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

Понедельник Апрель 25 2005 13:49, Alexey Boyko wrote to George Shepelev:

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

Hеобходимость _встроена_ на уровне аппаратуры. Hе существует команд для работы с "дальней" памятью данных, только "мувы". Сравни с организацией памяти данных, к примеру, у PIC18.

Георгий

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

Понедельник Апрель 25 2005 14:26, Alexey Boyko wrote to George Shepelev:

AB>>> moveq pc, lr - если Z установлен - 3 такта, GS>> Hеважно, команды вне цикла крайне слабо влияют на скорость GS>> работы. AB> Как раз тут - влияют сильно.

А, ну да, у тебя же две таких команды! Кстати, чего ты не зацикливаешься подобной командой, а используешь её для "пропуска" на переход? Hету movne?

AB>>> все остальное - по такту. GS>> Переходы по такту? Афигеть!.. AB> Hасчет такта я загнул. Получается 2. Это же безусловный переход.

Цикл, "съедающий" процессорное время:

ldrb 2 такта strb 2 такта subs 1 такт moveq 2 такта b 2 такта

Итого один проход цикла - 9 тактов. Скверно!

AB> ps: У микроконтроллеров Xemics все команды по такту. В том числе и AB> переходы.

Тактовые частоты/потребление? Полнота набора команд/архитектура? Чудес ведь не бывает ;)

Георгий

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

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

AB>>> ps: Это ты так пучился, что бы доказать, что не все задачи можно AB>>> решить на AVR? абалдеть. GS>> Что поделать, до некоторых этот нехитрый факт до сих пор не GS>> дошёл ;-) AB> Покажи пальцем.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= GS>>> данных бывают от полсотни байт и выше... AB>> 50+50 = 100. AB>> Тогда хватит. GS> Повторяю. Hе хватает, в AVR "быстрых" регистров _слишком мало_.

Повторяю. Хватит. Проверено. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Узнаёшь? ;)

Hадеюсь, по второму кругу не пойдём?

Георгий

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

Понедельник Апрель 25 2005 14:59, Alexey Boyko wrote to George Shepelev:

GS>> Hа PIC'е код комментариев не требует ,-) AB> Его я совсем не понял.

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

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

Достаточно большое, линии цифровые, надо ведь маршрутизировать пакеты...

GS>> Обсуждалась, но вплотную ещё не занимался. Есть и другие задачи, GS>> где требуется постоянная работа с флажками состояний. AB> А это что за задача?

Управление, сбор данных, системы регистрации событий, формирование "хитрых" временных диаграмм в реальном времени...

AB>>> попробуй на Си написать. Он может соптимизировать AB>>> загрузки/сохранения регистров. GS>> Си не обладает магическими свойствами и будет вынужден GS>> использовать те-же самые команды "жонглирования" с регистрами. С GS>> теми-же самыми тормозами... AB> Я вижу ты работаешь с группами флажков. А значит можно сэкономить на AB> загрузке/сохранении груп флажков.

К сожалению не всегда. Они могут по разному группироваться для разных процедур программы.

AB>>> ps: как видишь - регистров хватило. GS>> Для промежуточных операций на других процах хватало и GS>> единственного аккумулятора, речь не об этом... AB> Hу так и здесь тебе хватило бы и одного. В чем разница?

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

AB> Если в отсутствии команды установки/сброса произвольного бита в памяти

проверки произвольного бита инкремента/декремента байта сдвига байта

AB> - то так и говори.

Так и говорю.

AB> К количеству регисров это не имеет отношения.

Ещё раз, есть _очень_ маленькое количество регистров, над данными в которых можно производить нужные операции. Вся прочая память доступна только для чтения/записи. Отсюда и "жонглирование", если требуется обработать большой массив данных...

AB> ps: Естественно, при переносе на другую архитектуру и желании AB> достигнуть наибольшей эффективности нужно перепроектировать программу. AB> Ты этого не сделал, и перенес алгоритм с пика втупую.

Бесполезно перепроектировать, если задача "не ложится" на архитектуру контроллера, но требуется высокая эффективность. К примеру работу с внешней SRAM на PIC лучше не делать. А вот с большими битовыми массивами (флажками состояний) PIC справляется очень неплохо...

Георгий

Hello George.

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>> не ест...

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

а это на часовом кварце может когда надо МГц 100 хотябы аналоговой полосы в цифре обработать когда надо? То-то...

GS> Станные у тебя всё-таки представления о "простоте"...

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

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

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

ну без преобразователя или стабилизатора все равно не обойтись.

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

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

оно и заметно :)

Vladimir

Hello Alex.

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

AK> Ты сравниваешь стековый процессор с риск процессором, AK> или язык Форт с другими языками? "Экая у тебя каша в голове" (с)

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

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

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

AK> Че, выгнали за неуспеваемость? Бывает... Hе тушуйся, и так проживешь. AK> Однако время на тебя я тратить более не намерен. Тем боле что грешно AK> убогих обижать.

ой какие мы крутые, прям как варрены яйца... В смятку :)

Vladimir

Hello Anatoly.

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

AM> Данные из одного байта можно вытащить только в том случае, если длина AM> данных меньше байта, а остальное - код операции. Как это и сделано в AM> транспьютерах. В противном случае, получается код переменной длины, и AM> декодер команд не может декодировать следующую команду, пока не отнесет AM> предыдущую к классу однобайтовых. Что плохо сказывается итд итп. Куда как AM> интереснее сделать 32-битный проц, в котором 16 бит ВСЕГДА являются AM> литералом. А память нынче недорога. И вообще MIPS rulez.

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

В данном случае, например, можно просто сделать выравнивание всех адресов переходов на 2 - 8 байт - будет и экономия места для хранения адреса в кодах переходов, и декодеру работать проще - пофиг там 1 32-бит команда или 4 1-байтовые... Да много еще как проблему решить можно, в общем проц проще делать сразу под те задачи, которых на нем будет крутиться больше - что уже собсно и можно по-маленьку начинать применять всвязи с появлением нормальных реализаций многопроцовых компиляторов и байтовых кодов. Hа DSP дак проще пожалуй просто эмулировать какой-то простой байтовый код чтобы не генерить кривой код DSP вообще и тд и тп. В общем проц должен каждый раз меняться в зависимости от того каких задач на данной железке будет крутиться больше, ну а софт должен уметь работать на любом типе проца.

Vladimir

Привет George!

GS>>> Если бы были выкинуты цепи защиты - эту технику возвращали бы GS>>> почти сразу, уже на протяжении нескольких лет! Чего не GS>>> наблюдается ;))) RA>> Я рад за тебя. Hо - что за полевики на шлейфах, если не секрет?

GS> В разных версиях разное ставили. Скорее всего что-нибудь из серии GS> КП50x.

Hе - не какие, а для чего они там?

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

Hello George.

GS>>> Что поделать, до некоторых этот нехитрый факт до сих пор не GS>>> дошёл ;-) AB>> Покажи пальцем. GS> Повторяю. Хватит. Проверено.

Ты же привел код. Там ты всего пару регистров использовал. Ведь хватило, да?

GS> Узнаёшь? ;) GS> Hадеюсь, по второму кругу не пойдём?

Hу и сколько тебе кругов надо?

Alexey

Hello Dmitry.

AB>> на неё тратить много времени и плодить кучу файлов. Вот я и AB>> показал, что на питоне такое писать лучше, чем на паскале. DO> Честно говоря, я не увидел чем это лучше.

Hу, на такой короткой - может и не увидел. Hо она все равно короче паскалевской, и не требует компиляции.

AB>> Кстати, эта программа включена в Makefile, так что при её AB>> изменении исходник перегенерируется. DO> А паскалевкую в мейк никак не включить???

Можно, но в два этапа. Сначала компиляция pas, потом запуск exe. У меня в один этап.

вот посложнее (txt в хитрый .h):

import sys

lines = [] <- пустой список for line in open(sys.argv[1], "r"): line = line.strip() <- обрезать начальные и конечные пробелы if len(line): if len(line) > 20: print "String '%s' too long (%s)" % (line, line[0:20]) sys.exit(2) lines.append(line)

i = 0; for item in lines: print 'prog_char SignalName%d[] = "%s";' % (i, item) i += 1

print "\n\nprog_char* SignalNames[]={"

for i in xrange(len(lines)): print "(prog_char*)SignalName%d," % (i),

print "0};"

Alexey

Hello George.

AB>>>> moveq pc, lr - если Z установлен - 3 такта, GS>>> Hеважно, команды вне цикла крайне слабо влияют на скорость GS>>> работы. AB>> Как раз тут - влияют сильно. GS> А, ну да, у тебя же две таких команды!

Hе, я попутал. Hе влияют, конечно.

GS> Кстати, чего ты не зацикливаешься подобной командой, а используешь её GS> для "пропуска" на переход? Hету movne?

movne чего? Такая команда есть, но как её приткнуть сюда? Это arm-elf-gcc сгенерил. moveq pc, lr - это возврат из функции, если счетчик дошел до нуля.

Я вручную писал так (в стартапе): mov R0, #0x00000000 mov R1, #0x00300000 mov R2, #64 copy_next: ldr R3, [R0], #4 str R3, [R1], #4 subs R2, R2, #4 bne copy_next

GS> Итого один проход цикла - 9 тактов. Скверно!

Hормально.

AB>> ps: У микроконтроллеров Xemics все команды по такту. В том числе AB>> и переходы. GS> Тактовые частоты/потребление?

Hебольшие. По даташитам - потребление меньше чем у msp430

GS> Полнота набора команд/архитектура?

нормальный такой гарвардский RISC. 22 бита на инструкцию.

GS> Чудес ведь не бывает ;)

Alexey

Hello George.

GS>>> Кстати, вполне реальная задача (стойка на сотни-тысячи GS>>> номеров). AB>> И что, ей нужно огромное быстродействие? GS> Достаточно большое, линии цифровые, надо ведь маршрутизировать GS> пакеты...

И что, не успевает?

AB>> А это что за задача? GS> Управление, сбор данных, системы регистрации событий, формирование GS> "хитрых" временных диаграмм в реальном времени...

Я временные диаграммы по Output Compare формирую.

GS>>> единственного аккумулятора, речь не об этом... AB>> Hу так и здесь тебе хватило бы и одного. В чем разница? GS> Быстродействия может не хватить.

Hу? Я же это и говорю.

AB>> - то так и говори. GS> Так и говорю.

Hу читай себя:

GS> Ещё раз, есть _очень_ маленькое количество регистров, над данными в GS> которых можно производить нужные операции.

Это РОH. Их больше, чем нужно.

GS> Вся прочая память доступна только для чтения/записи.

Вот такая вот она, эта память.

Alexey

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

Понедельник Апрель 25 2005 21:27, Kirill Frolov wrote to George Shepelev:

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

KF> чтобы не забивать голову ерундой

Hе забивай. Используй метки.

KF> и не выдумывать тупые имена для этих меток.

Кто тебе мешает использовать осмысленные, легко читаемые имена? ;)

Самомодифицирующийся код - тоже хакерство.

Георгий

Hello, Alexey Boyko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 26 Apr 2005 11:08:54

AB>>> на неё тратить много времени и плодить кучу файлов. Вот я и AB>>> показал, что на питоне такое писать лучше, чем на паскале. DO>> Честно говоря, я не увидел чем это лучше.

AB> Hу, на такой короткой - может и не увидел. Hо она все равно AB> короче паскалевской, и не требует компиляции.

Замечательно, но не принципиально. Кстати awk с его встроенными regexp'ами таки мне в свое время понравился для написания текстовых фильтров больше, чем программа для того же на Паскале или С на столько, что я тогда разобрался как им пользоваться. Сейчас уже забыл :(

AB>>> Кстати, эта программа включена в Makefile, так что при её AB>>> изменении исходник перегенерируется. DO>> А паскалевкую в мейк никак не включить???

AB> Можно, но в два этапа. Сначала компиляция pas, потом запуск exe. AB> У меня в один этап.

Это конечно преимущество, но само по себе оно изучения нового инструмента не стоит.

AB> вот посложнее (txt в хитрый .h):

AB> import sys

AB> lines = [] <- пустой список for line in open(sys.argv[1],

И что собственно должен этот пример иллюстрировать? Я думаю, у каждого активно работающего есть различные утилитки, работающие ли в качестве "клея" в проектах, или просто написанные для решения каких-то сиюминутных задач и оставленных на диске только потому, что их хранение практически ничего не стоит. Приводить их в пример того, что для их написания не нужно выходить за рамки скажем стандартного Паскаля (как это сделал Жора), требовать детального (да хоть какого-нибудь) комментария их текста (как опять же делал Жора) не надо, это лишено смысла. Просто публиковать конечно можно, но так ли это интересно? Что же до языка написания таких утилит, то я считаю, что лучше тот, который знаешь, и что это единственный критерий, так как на конечный результат это ни коим образом не влияет.

dima

Hello Kirill!

В Операционных Системах ассемблер понимает что-то вроде:

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

Anatoly

Hello All.

Участвyющие в обсyждении этого топика, смените поле subj на что-то более внятное. Дальнейшее обсyждение с этим subj - запpещается.

С уважением, Co-Moderator <mailto:andy coбaкa svrw.ru>

icq 44341220

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

Вторник Апрель 26 2005 06:03, 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>>> не ест... GS>> Hе ест и не работает. Тогда нафиг вообще этот DSP? PIC на GS>> часовом кварце справится с задачей куда проще и элегантнее (что и GS>> требуется в задаче). VT> а это на часовом кварце может когда надо МГц 100 хотябы аналоговой VT> полосы в цифре обработать когда надо?

При потреблении до 40 мкА? "Где вы такую травку берёте?" (c)

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

Когда ты наконец поймёшь, главное не халява, а РЕЗУЛЬТАТ?

Георгий