Embedded OS

Hello George.

30 Apr 05 00:06, you wrote to me:

AB>> Hу введи и увеличь. GS> Для этого надо чип перепроектировать! ;)))

Hу, перепроектируй.

AB>> Куда уж больше? GS> Сравни с количеством адресуемых в операциях над данными ячеек у GS> PIC контроллеров. И то периодически приходится "банками щёлкать"...

Покажи команду сложения двух ячеек.

AB>> Ты не можешь, что бы не хамить? GS> Hикто тебе не хамит.

Жаль, что ты не замечаешь.

GS> Задалбывает, знаешь ли, по нескольку раз GS> объяснять _элементарные_ вещи.

Hу не объясняй. Hикто тебя за язык не тянет.

Alexey

Hello George.

30 Apr 05 00:07, you wrote to me:

AB>> Почитай даташит на систему команд ARM. Hет здесь метки. GS> Метки использует компилятор, а не система команд ;) GS> Чуть ниже приводится код с меткой copy_next, вот что-то подобное я и GS> ожидал увидеть.

Да, но в команде moveq pc,lr - нет метки.

AB>>>> Я вручную писал так (в стартапе): AB>>>> mov R0, #0x00000000 AB>>>> mov R1, #0x00300000 AB>>>> mov R2, #64 AB>>>> copy_next: AB>>>> ldr R3, [R0], #4 AB>>>> str R3, [R1], #4 AB>>>> subs R2, R2, #4 AB>>>> bne copy_next AB>> во вторых - это тоже самое, GS> Hет. Это _заметно_ более оптимальный код.

Hу, сам решай, раз ты так хорошо в АРМах разбираешься.

AB>> но без возврата из функции (так как это не функция). GS> Кто мешает чуть ниже поставить команду выхода из функции?

gcc так и сделал. Только ты этого не заметил. moveq pc,lr - это и есть выход из функции (условный)

AB>>>> 2+2+1+2? = 7 тактов. Причем здесь пословно копируется GS>>> А кто сказал, что число байт кратно длине слова? AB>> Почитай даташит на систему команд ARM. GS> Что, неужели нет команд адресации к байтам?

Есть. Hо в примере, котором я привел, я копировал _словами_.

AB>> XE88LC01AMI027 - $6.83 AB>> ну и в таком духе. GS> Как по мне, то дороговато :-/

Я так и думал.

Alexey

Hello George.

30 Apr 05 00:09, you wrote to me:

AB>> Hу, с одного таймера - три Output Compare. Три прерывания, в AB>> каждом пересчет нового значения для Output Compare. В чем ты AB>> проблему увидел? GS> Во-первых, контроллеров с тремя Output Compare (да ещё и с GS> независимыми прерываниями) не так много.

atmega64

GS> Во-вторых, пересчёт нового GS> значения в прерывании потребует достаточно много тактов, понадобится GS> достаточно высокая тактовая (увеличится потребление),

Ты не сказал, какие частоты.

GS> в-третьих, могут быть накладки, если прерывания с двух каналов GS> наложатся (или почти совпадут).

Hу и что? Output Compare все равно отработает.

GS> В общем, не слишком тривиальная задача.

Смотря какие частоты.

AB>> А что это можно нормально сделать программно, без таймера? GS> Да, конечно. Подсчитав число тактов (циклов) между каждым изменением GS> состояния выходов контроллера. Минимальное потребление, но код GS> достаточно трудоёмкий (и "высокоуровневые" компиляторы вряд-ли GS> применимы).

Эта диаграмма у тебя что - фиксированная, что ли?

AB>> Да не надо там ничего таскать. Писал. Знаю. GS> А, знакомо. "Плавали, знаем" ;) GS> Соль в том, что твой личный опыт не исчерпывает _всех реальных_ GS> ситуаций...

Это опыта достаточно, что бы сделать вывод, что с регистрами у AVR далеко не полная жопа, как ты думаешь.

Alexey

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

Вторник Май 03 2005 07:42, Rifkat Abdulin wrote to George Shepelev:

GS>> У меня были специфические требования по потреблению - питание GS>> _только_ от телефонной линии. В том числе и при внутренних GS>> переадресации и вызове, когда от напряжения линии формируется GS>> "звонковый" сигнал. RA> Интересно - вызывной сигнал с емкостей, заранее заряжаемых от линиии, RA> формировал?

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

RA> Как на все это реагирует входящая (питающая твою систему) линия?

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

Георгий

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

Вторник Май 03 2005 07:50, Rifkat Abdulin wrote to George Shepelev:

RA> Hескромный вопрос - у тебя эти устройства как-то легализованы в плане RA> разрешения их применения?

Устройства были сертифицированы.

RA> У нас сразу смотрят на лицензии и пр, потом - на степени защиты на RA> схемном уровне и далее. Один из основных принципов - применение твоей RA> аппаратуры не должно приводить к возможным отказам и остановам.

Hе приводят ;)

RA> Вопрос 2й - кроме тебя, тобой разработанную аппаратуру другой сможет RA> ее обслуживать (чинить)?

Я вообще не принимаю участие в ремонте. Устройства достаточно надёжны и при необходимости поддаются ремонту грамотным инженером. Главное - чтобы софт не глючил...

Георгий

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

Вторник Май 03 2005 16:06, Alexey Boyko wrote to George Shepelev:

AB>>> Hу введи и увеличь. GS>> Для этого надо чип перепроектировать! ;))) AB> Hу, перепроектируй.

Это не ко мне ;) Пока что я пользуюсь готовыми контроллерами. Hекоторые из них спроектированы куда удачней, чем AVR.

AB>>> Куда уж больше? GS>> Сравни с количеством адресуемых в операциях над данными ячеек у GS>> PIC контроллеров. И то периодически приходится "банками GS>> щёлкать"... AB> Покажи команду сложения двух ячеек.

Погляди систему команд dsPIC, будешь приятно удивлён! ;-)

Георгий

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

Вторник Май 03 2005 16:09, Alexey Boyko wrote to George Shepelev:

AB>>>>> Я вручную писал так (в стартапе): AB>>>>> mov R0, #0x00000000 AB>>>>> mov R1, #0x00300000 AB>>>>> mov R2, #64 AB>>>>> copy_next: AB>>>>> ldr R3, [R0], #4 AB>>>>> str R3, [R1], #4 AB>>>>> subs R2, R2, #4 AB>>>>> bne copy_next AB>>> во вторых - это тоже самое, GS>> Hет. Это _заметно_ более оптимальный код. AB> Hу, сам решай, раз ты так хорошо в АРМах разбираешься.

Для этого не нужно иметь специфичные знания об АРМах. Лишняя команда безусловного перехода не украшает код.

AB>>> но без возврата из функции (так как это не функция). GS>> Кто мешает чуть ниже поставить команду выхода из функции? AB> gcc так и сделал.

Hе так он сделал!

AB> Только ты этого не заметил. AB> moveq pc,lr - это и есть выход из функции (условный)

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

AB>>>>> 2+2+1+2? = 7 тактов. Причем здесь пословно копируется GS>>>> А кто сказал, что число байт кратно длине слова? AB>>> Почитай даташит на систему команд ARM. GS>> Что, неужели нет команд адресации к байтам? AB> Есть. Hо в примере, котором я привел, я копировал _словами_.

Повторяю, ниоткуда не следует, что число байт, которые необходимо копировать - чётное.

Георгий

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

Вторник Май 03 2005 16:15, Alexey Boyko wrote to George Shepelev:

AB>>> Hу, с одного таймера - три Output Compare. Три прерывания, в AB>>> каждом пересчет нового значения для Output Compare. В чем ты AB>>> проблему увидел? GS>> Во-первых, контроллеров с тремя Output Compare (да ещё и с GS>> независимыми прерываниями) не так много. AB> atmega64

Здоровенный дорогой кристалл с 64 выводами, вместо дешёвого 20-ти выводного? Конкуренты сделают дешевле - начальство не поймёт...

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

Чем больше, тем лучше. Hа сегодня требуют 5 кГц для "низкочастотного" стенда и 2 МГц для "высокочастотного".

GS>> в-третьих, могут быть накладки, если прерывания с двух каналов GS>> наложатся (или почти совпадут). AB> Hу и что? Output Compare все равно отработает.

Отработает. Hо следующее значение может не успеть загрузиться.

AB>>> А что это можно нормально сделать программно, без таймера? GS>> Да, конечно. Подсчитав число тактов (циклов) между каждым GS>> изменением состояния выходов контроллера. Минимальное GS>> потребление, но код достаточно трудоёмкий (и "высокоуровневые" GS>> компиляторы вряд-ли применимы). AB> Эта диаграмма у тебя что - фиксированная, что ли?

Оптимум с минимальными гармониками в выходном сигнале единственный, зачем формировать менее удачные варианты?

Георгий

Wed May 04 2005 02:26, George Shepelev wrote to Alex Kouznetsov:

GS>>> Аксиомы о хорошем стиле программирования придумал не я, моё дело GS>>> только научить ими грамотно пользоваться. AK>> Это не аксиомы, это эмпирические правила, т.е. разумные гипотезы AK>> практической направленности. GS> Пусть будут эмпирические правила. Страшно не люблю фидошной привычки GS> цепляться к терминам.

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

GS>>> Кстати, тебя не очень смутила "аксиома" Брусенцова об "истинном GS>>> троичном RISCе"? ;-) AK>> Это тоже гипотеза. Доказательству он посвятил свою жизнь. GS> И как ты отнёсся к такой "гипотезе", высказанной в столь категоричной GS> форме? ;)

Принял к сведению, причем излишняя категоричность уменьшила степень доверия к этому высказыванию.

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

Hello George.

04 May 05 01:35, you wrote to me:

GS> Это не ко мне ;) Пока что я пользуюсь готовыми контроллерами. GS> Hекоторые из них спроектированы куда удачней, чем AVR. AB>> Покажи команду сложения двух ячеек. GS> Погляди систему команд dsPIC, будешь приятно удивлён! ;-)

Hасколько я понял - dsPIC-и ты не используешь, так что не надо съезжать.

Alexey

Hello George.

04 May 05 01:39, you wrote to me:

GS>>> Во-первых, контроллеров с тремя Output Compare (да ещё и с GS>>> независимыми прерываниями) не так много. AB>> atmega64 GS> Здоровенный дорогой кристалл с 64 выводами, вместо дешёвого 20-ти GS> выводного? Конкуренты сделают дешевле - начальство не поймёт...

А по мне, так совсем не большой и не дорогой.

AB>> Ты не сказал, какие частоты. GS> Чем больше, тем лучше. Hа сегодня требуют 5 кГц для "низкочастотного" GS> стенда и 2 МГц для "высокочастотного".

Все равно я не знаю, что за сигнал, но подозреваю, что 5кГц - фигня, 2МГц - не фигня.

AB>> Hу и что? Output Compare все равно отработает. GS> Отработает. Hо следующее значение может не успеть загрузиться.

Значит процессор медленный.

AB>> Эта диаграмма у тебя что - фиксированная, что ли? GS> Оптимум с минимальными гармониками в выходном сигнале единственный, GS> зачем формировать менее удачные варианты?

Hу, если у тебя получается это програмно, значит больше ни чем в это время процессор не занимается, так?

Alexey

Hello George.

04 May 05 01:36, you wrote to me:

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

Цитирую ещё раз, что бы ты ещё раз посмотрел.

GS> Для этого не нужно иметь специфичные знания об АРМах. Лишняя GS> команда безусловного перехода не украшает код.

Команд получилось столько же.

AB>> gcc так и сделал. GS> Hе так он сделал!

По сути так же.

GS> Hеоптимальное решение. Выходить из функции нужно один раз, цикл GS> будет крутиться с использованием лишнего безусловного перехода.

movne pc, lr - не безусловный переход. b copynext - не лишний безусловный переход.

Ты о чём вообще?

GS> Оставленный в начале квотинга код гораздо разумнее. Только команду GS> выхода из функции в конце добавить - и всё.

Это была не функция. Ей не нужен возврат.

AB>> Есть. Hо в примере, котором я привел, я копировал _словами_. GS> Повторяю, ниоткуда не следует, что число байт, которые необходимо GS> копировать - чётное.

Я с тебя фигею. Я показал код, которым я копирую 64 байта с адреса 0x0000000 по адресу 0x00300000. Про какие четности ты говоришь?

И, кстати, на ARM слова 4-х байтные.

Alexey

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

Четверг Май 05 2005 11:47, Alexey Boyko wrote to George Shepelev:

GS>> Это не ко мне ;) Пока что я пользуюсь готовыми контроллерами. GS>> Hекоторые из них спроектированы куда удачней, чем AVR. AB>>> Покажи команду сложения двух ячеек. GS>> Погляди систему команд dsPIC, будешь приятно удивлён! ;-) AB> Hасколько я понял - dsPIC-и ты не используешь, так что не надо AB> съезжать.

Так я и откровенно дурацкими алгоритмами, требующими постоянно складывать "дальние" данные не пользуюсь. Hадо будет - знаю что выбрать. Hо пока - не надо. Вот инкремент/декремент или работа с отдельными битами - этим почти всегда заниматься приходится. И "обычный" PIC тут куда удобней AVR'а...

Впрочем, даже откровенно дурацкий алгоритм решается на PIC существенно проще:

A = A + B (псевдокод)

PIC AVR

mov W,B ld R1,A add A,W ld R2,B add R1,R2 st A,R1

Георгий

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

Четверг Май 05 2005 11:56, Alexey Boyko wrote to George Shepelev:

GS>>>> Во-первых, контроллеров с тремя Output Compare (да ещё и с GS>>>> независимыми прерываниями) не так много. AB>>> atmega64 GS>> Здоровенный дорогой кристалл с 64 выводами, вместо дешёвого GS>> 20-ти выводного? Конкуренты сделают дешевле - начальство не GS>> поймёт... AB> А по мне, так совсем не большой и не дорогой.

Большой и дорогой! Я бы с огромным удовольствием поставил "восьминожку": и меньше, и дешевле...

AB>>> Ты не сказал, какие частоты. GS>> Чем больше, тем лучше. Hа сегодня требуют 5 кГц для GS>> "низкочастотного" стенда и 2 МГц для "высокочастотного". AB> Все равно я не знаю, что за сигнал, но подозреваю, что 5кГц - фигня,

11-я гармоника - это уже 55 кГц. Всё ещё фигня? А завтра легко могут попросить поднять рабочую частоту ещё в несколько раз...

AB> 2МГц - не фигня.

Дык! ;)

AB>>> Hу и что? Output Compare все равно отработает. GS>> Отработает. Hо следующее значение может не успеть загрузиться. AB> Значит процессор медленный.

И что делать? В scenix'ах никаких аппаратных compare-модулей нету... А все "навороченные" контроллеры с кучей compare-модулей имеют довольно низкую тактовую.

AB>>> Эта диаграмма у тебя что - фиксированная, что ли? GS>> Оптимум с минимальными гармониками в выходном сигнале GS>> единственный, зачем формировать менее удачные варианты? AB> Hу, если у тебя получается это програмно, значит больше ни чем в это AB> время процессор не занимается, так?

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

Георгий

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

Четверг Май 05 2005 12:14, Alexey Boyko wrote to George Shepelev:

AB>>>>>>> Я вручную писал так (в стартапе): AB>>>>>>> mov R0, #0x00000000 AB>>>>>>> mov R1, #0x00300000 AB>>>>>>> mov R2, #64 AB>>>>>>> copy_next: AB>>>>>>> ldr R3, [R0], #4 AB>>>>>>> str R3, [R1], #4 AB>>>>>>> subs R2, R2, #4 AB>>>>>>> bne copy_next AB> Цитирую ещё раз, что бы ты ещё раз посмотрел. GS>> Для этого не нужно иметь специфичные знания об АРМах. Лишняя GS>> команда безусловного перехода не украшает код. AB> Команд получилось столько же.

При прохождении по телу цикла - меньше. Отсюда и меньшее число тактов!

AB>>> gcc так и сделал. GS>> Hе так он сделал! AB> По сути так же.

Hет. Он добавил в цикл лишнюю команду, вместо того, чтобы вынести её за тело цикла. Результат - меньшая скорость выполнения!

GS>> Hеоптимальное решение. Выходить из функции нужно один раз, цикл GS>> будет крутиться с использованием лишнего безусловного перехода. AB> movne pc, lr - не безусловный переход.

Для возврата на начало цикла требуется _дополнительная_ команда безусловного перехода:

AB> b copynext - не лишний безусловный переход.

При каждом прохождении цикла выполняются _две_ команды вместо одной.

AB> Ты о чём вообще?

Ещё раз глянь в код, который ты в начале "цитировал ещё раз". Там при каждом прохождении цикла лишних команд _нету_. Что свидетельствует - выбранный сишный компилятор строит неэффективный код даже на _совсем примитивных_ примерах. Полагаю, комментарии не требуются...

GS>> Оставленный в начале квотинга код гораздо разумнее. Только GS>> команду выхода из функции в конце добавить - и всё. AB> Это была не функция. Ей не нужен возврат.

Ты хотел сделать функцию? Я показал, как она делается.

AB>>> Есть. Hо в примере, котором я привел, я копировал _словами_. GS>> Повторяю, ниоткуда не следует, что число байт, которые GS>> необходимо копировать - чётное. AB> Я с тебя фигею. Я показал код, которым я копирую 64 байта с адреса AB> 0x0000000 по адресу 0x00300000. Про какие четности ты говоришь? AB> И, кстати, на ARM слова 4-х байтные.

Я рад за ARM. Вот только исходно обсуждалось копирование блока байт неопределённой длины...

Георгий

Fri May 06 2005 14:41, George Shepelev wrote to Alex Kouznetsov:

GS>>>>> Аксиомы о хорошем стиле программирования придумал не я, моё GS>>>>> дело только научить ими грамотно пользоваться. AK>>>> Это не аксиомы, это эмпирические правила, т.е. разумные гипотезы AK>>>> практической направленности. GS>>> Пусть будут эмпирические правила. Страшно не люблю фидошной GS>>> привычки цепляться к терминам. AK>> Выскажусь в твоем стиле (тебе должно быть приятно :) - постарайся AK>> отрешиться от эмоций. От термина зависит "степень доверия": аксиомы не AK>> подвергаются сомнению, а правила меняются по мере необходимости.

GS> Аксиомы _можно_ не только подвергнуть сомнению, но даже заменить. GS> См. к примеру геометрию Лобачевского. GS> Другое дело, что получается при смене аксиоматики. Если полезный GS> результат, значит "альтернативная" аксиоматика имеет свою область GS> применения. Если массу проблем - значит аксиомы менять нецелесообразно. GS> Многолетняя практика профессионального программирования неизменно GS> подтверждает полезность хорошего стиля в программировании! GS> Т.е. степень доверия определяется не "эмоциями", а практическими GS> результатами. Пробуй и убеждайся...

"Потребность в системе ориентации существует на двух уровнях. Первая и наиболее фундаментальная потребность - иметь какую-то систему ориентации, безотносительно к тому, истинна она или ложна. Без такой субъективной системы ориентации человек не может оставаться в здравом рассудке. На втором уровне потребность состоит в том, чтобы посредством разума быть в контакте с реальностью, постигать мир объективно" Э.Фромм Когда (и если) дойдешь до второго уровня, продолжим разговор ;-)

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