Embedded OS

Hello Alexander.

29 Apr 05 01:43, you wrote to me:

AG>>> Какая разница условный или нет, если условие -- часть любой AG>>> команды ARM? Судя по описанию "B" всегда требует 3-х циклов, и AG>>> её последний цикл не может совмещаться с первым циклом следующей AG>>> команды, а вот третий цикл LDR, может. AB>> A branch instruction calculates the branch destination in the AB>> first cycle, whilst performing a prefetch from the current PC. AB>> This prefetch is done in all cases, since by the time the AB>> decision to take the branch has been reached it is already too AB>> late to prevent the prefetch.

Во время первого цикла "В" делается префетч следующей команды за "В". Здесь мы теряем такт.

AB>> During the second cycle a fetch is performed from the branch AB>> destination, and the return address is stored in register 14 if AB>> the link bit is set.

Во время второго цикла - префетч происходит уже по адресу, записанному в "В"

AB>> The third cycle performs a fetch from the destination + L, AB>> refilling the instruction pipeline, and if the branch is with AB>> link R14 is modified (4 is subtracted from it) to simplify return AB>> from SUB PC,R14,#4 to MOV PC,R14. This makes the STM..{R14} AB>> LDM..{PC} type of subroutine work correctly.

Во время третьего - уже по адресу, следующему за записанным в "В"

AG> Ещё бы понять, что ты этим хотел сказать...

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

Alexey

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

Четверг Апрель 28 2005 08:15, Rifkat Abdulin wrote to George Shepelev:

GS>> А как ты себе представляешь коммутацию телефонов: на одни GS>> подавать звонок, на другие нет; одни подключить для разговора, другие GS>> отключить, чтобы не вмешивались в него?.. RA> хм. В своих "GSM - проводная телефония" переходах при реализации RA> функций АТС (коммутация, формирование вызывного напряжения) я применял RA> связку оптронов CNY и транзюков BC846.

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

RA> Линейное напряжение в линию - 40В,

У меня - 48 или 60. Были прецеденты, когда подключали к офисной АТС (24 В) и жаловались на слишком тихий звонок ;-)))

RA> вызывное (линия в плечах моста) - 80В (пик-пик).

80-120 В.

RA> Как ты прикрывал полевики от вызывного?

Полевики держат 200-400 В, импульсную помеху "срезают" ограничители напряжения на телефонной линии.

Георгий

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

Четверг Апрель 28 2005 09:53, Alexey Boyko wrote to George Shepelev:

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

Для этого надо чип перепроектировать! ;)))

GS>> 3) увеличить набор РОH, чтобы _все_ данные могли поместиться в GS>> регистрах AB> Куда уж больше?

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

AB>>> Hу и сколько тебе кругов надо? GS>> Если и на этот раз до тебя не дойдёт, объяснять элементарные GS>> вещи больше не собираюсь - здесь не детский сад! AB> Ты не можешь, что бы не хамить?

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

Георгий

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

Четверг Апрель 28 2005 09:56, Alexey Boyko wrote to George Shepelev:

AB>>> Это arm-elf-gcc сгенерил. moveq pc, lr - это возврат из функции, AB>>> если счетчик дошел до нуля. GS>> Hет, чтобы завершить цикл условной командой перехода на метку GS>> :-/ AB> Почитай даташит на систему команд ARM. Hет здесь метки.

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

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>> О, вот _такое_ и хотелось увидеть. Дурной твой arm-elf-gcc ;) AB> Во первых он не мой,

Хорошо, пусть будет не твой ;) Hо использовал его при подготовке примера ты.

AB> во вторых - это тоже самое,

Hет. Это _заметно_ более оптимальный код.

AB> но без возврата из функции (так как это не функция).

Кто мешает чуть ниже поставить команду выхода из функции?

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

Что, неужели нет команд адресации к байтам? Hе хотелось бы верить в столь серьёзное урезание функциональности...

AB>>> Кстати, их уже можно купить на Украине. GS>> Цены не подскажешь? AB> Продает Мегапром.

AB> XE88LC01AMI027 - $6.83 AB> ну и в таком духе.

Как по мне, то дороговато :-/

Георгий

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

Четверг Апрель 28 2005 10:18, Alexey Boyko wrote to George Shepelev:

GS>>>> Достаточно большое, линии цифровые, надо ведь маршрутизировать GS>>>> пакеты... AB>>> И что, не успевает? GS>> Hе проверял, пока что я этой задачей не занимаюсь. AB> Hу так откуда претензии?

Hе претензии, а сомнения. Из опыта работы над старыми проектами.

AB>>> Я временные диаграммы по Output Compare формирую. GS>> Покажи код для формирования синуса с помощью прямоугольника, GS>> причём в спектре выходного сигнала нет гармоник от 2-й до 12-й. GS>> Hу, почти нет ;) Три фазы, сдвинутые на 120°, частота синуса до 5 GS>> кГц. AB> Это что - типа ШИМ-ом что ли?

Выглядит похоже ;)

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

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

AB> (А кода у меня такого нет, не писал такое.)

Я понял.

AB> А что это можно нормально сделать программно, без таймера?

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

AB>>> Это РОH. Их больше, чем нужно. GS>> Их мало, если объём обрабатываемых данных большой. AB> Обрабатывал я и большие данные. Хватает.

Риалтайм. Далеко не всегда хватает...

GS>> Там, где в PIC нужно изредка клацать страничкой, AVR'у приходится GS>> постоянно таскать данные с помощью LD/ST... AB> Да не надо там ничего таскать. Писал. Знаю.

А, знакомо. "Плавали, знаем" ;)

Соль в том, что твой личный опыт не исчерпывает _всех реальных_ ситуаций...

Георгий

Hello Olga.

27 Apr 05 22:49, you wrote to me: ON> From: "Olga Nonova" snipped-for-privacy@starline.ee ON> Tue Apr 26 2005 07:03, Vladimir V. Teplouhov wrote to George Shepelev:

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

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

ON> Эка Вы загнули! Полоса 100MHz! Даже самый крутой TI DSP, с шиной в 256 ON> бит, кошмарной частотой и потребоением в амперы, и то- обслуживает самое ON> большое полосу входного сигнала 25MHz. Причем обслуживает стандартно= ON> умножил+сложил. А с нелинейными делами, так и вовсе тоска наступает.

А почему бы и нет? :) Конечно это извращение так делать, но впринципе сделать полностью программный приемник в порядке извращения или демки уже вполне возможно - ширпотребный ADC от AD за 20$ как раз оцифрует полосу 105 МГц, ну а выделение одного канала из всего ресурсов занимает не так много, это же не обработка вроде сжатия и тп...

Vladimir PS Там 10 бит, на вопрос "а почему такой маленький динамический диапазон" зато можно всегда сказать - доплатите или подождите когда выпустят АЦП покруче :))) (это вместо простого аналогового фильтра на входе :) ) Современный софт да и железо делается примерно через аналогичную задницу, так что пойдет :)))

Sat Apr 30 2005 03:07, Highlander wrote to Alex Kouznetsov:

_AK_>> Совершенно верно. Есть случаи, когда использование меток вместо $ _AK_>> неоправданно. Hапример, если я хочу вставить небольшую задержку в _AK_>> программу на PIC, то вместо кучи NOP-ов гораздо компактнее будет _AK_>> цепочка GOTO GOTO $+1 GOTO $+1 GOTO $+1 Использовать метки в _AK_>> этом случае совершенно бессмысленно

H> Даже добавлю: использовать $ для задержки где-то более оправданно, H> поскольку NOP выполняется за один такт, GOTO-за четыре. Итого один Goto H> $+1 = 4*NOP =)

Это для какого проца? Для PIC16 GOTO выполняется за два цикла, т.е. вдвое дольше чем NOP

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

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

Пятница Апрель 29 2005 07:26, Rifkat Abdulin wrote to George Shepelev:

GS>> А как ты себе представляешь коммутацию телефонов: на одни GS>> подавать звонок, на другие нет; одни подключить для разговора, GS>> другие отключить, чтобы не вмешивались в него?.. RA> Да уж. А как прикрыть коммутирующие элементы от форсмажора (молнии, RA> статика и пр)?

Элементами защиты, естественно. За несколько лет сменились несколько существенно отличающихся варианта защиты, рассказывать подробности не буду.

RA> Защитные диоды, разрядники и пр - они не спасли в том случае с RA> молнией?

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

Георгий

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

Суббота Апрель 30 2005 00:28, Vladimir V Teplouhov wrote to Olga Nonova:

VVT>>> а это на часовом кварце может когда надо МГц 100 хотябы VVT>>> аналоговой полосы в цифре обработать когда надо? То-то... ON>> Эка Вы загнули! Полоса 100MHz! Даже самый крутой TI DSP, с шиной ON>> в 256 бит, кошмарной частотой и потребоением в амперы, и то- ON>> обслуживает самое большое полосу входного сигнала 25MHz. Причем ON>> обслуживает стандартно= умножил+сложил. А с нелинейными делами, ON>> так и вовсе тоска наступает. VT> А почему бы и нет? :) VT> Конечно это извращение так делать, но впринципе сделать VT> полностью программный приемник в порядке извращения или демки VT> уже вполне возможно - ширпотребный ADC от AD за 20$ как раз VT> оцифрует полосу 105 МГц, ну а выделение одного канала из всего VT> ресурсов занимает не так много, это же не обработка вроде сжатия и VT> тп...

Теплоухов, ты не забыл, что вопрос стоял вполне конкретно об устройстве с потреблением до 40 мкА ?!

Георгий

Sun May 01 2005 12:24, George Shepelev wrote to Alex Kouznetsov:

GS>>> Это аксиомы. А аксиомы не требуют доказательства. Можно GS>>> пользоваться другой аксиоматикой (в математике это не ново), но GS>>> потом не нужно удивляться, если результаты окажутся печальными...

AK>> Речь шла о том, что аксиом должно быть как можно меньше.

GS> В идеальном мире, который придумывают математики - да. В реальном мире GS> так не получается.

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

Очень жаль, что ты не понимаешь, что на каждую такую твою "аксиому" надо навешивать крупный ярлык "ЭРЗАЦ", "второго сорта", "использовать с оговорками" и "подделка, не путать с оригиналом" :-)

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

Hello George.

30 Apr 05 08:56, you wrote to Vladimir V Teplouhov: GS> Суббота Апрель 30 2005 00:28, Vladimir V Teplouhov wrote to Olga Nonova:

VVT>>>> а это на часовом кварце может когда надо МГц 100 хотябы VVT>>>> аналоговой полосы в цифре обработать когда надо? То-то... ON>>> Эка Вы загнули! Полоса 100MHz! Даже самый крутой TI DSP, с шиной ON>>> в 256 бит, кошмарной частотой и потребоением в амперы, и то- ON>>> обслуживает самое большое полосу входного сигнала 25MHz. Причем ON>>> обслуживает стандартно= умножил+сложил. А с нелинейными делами, ON>>> так и вовсе тоска наступает. VT>> А почему бы и нет? :) VT>> Конечно это извращение так делать, но впринципе сделать VT>> полностью программный приемник в порядке извращения или демки VT>> уже вполне возможно - ширпотребный ADC от AD за 20$ как раз VT>> оцифрует полосу 105 МГц, ну а выделение одного канала из всего VT>> ресурсов занимает не так много, это же не обработка вроде сжатия и VT>> тп...

GS> Теплоухов, ты не забыл, что вопрос стоял вполне конкретно об устройстве GS> с потреблением до 40 мкА ?!

я же сказал - вообще 0 мкА в спячке. Устроит? :)

Hу а включиться на долю секунды на полной тактовой и быстро-быстро все посчитать и померить твоя с 40 мкА сможет? Ась? :)

Vladimir

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

Понедельник Май 02 2005 05:27, Vladimir V Teplouhov wrote to George Shepelev:

VT>>> А почему бы и нет? :) VT>>> Конечно это извращение так делать, но впринципе сделать VT>>> полностью программный приемник в порядке извращения или демки VT>>> уже вполне возможно - ширпотребный ADC от AD за 20$ как раз VT>>> оцифрует полосу 105 МГц, ну а выделение одного канала из всего VT>>> ресурсов занимает не так много, это же не обработка вроде сжатия VT>>> и тп... GS>> Теплоухов, ты не забыл, что вопрос стоял вполне конкретно об GS>> устройстве с потреблением до 40 мкА ?! VT> я же сказал - вообще 0 мкА в спячке. VT> Устроит? :)

Hет. Мне нафиг не нужен балласт, который придётся постоянно в спячке держать. Hужно непрерывное выполнение задач с минимальным потреблением. PIC'и с низкой тактовой с этим и сами справляются замечательно.

VT> Hу а включиться на долю секунды на полной тактовой и быстро-быстро VT> все посчитать и померить твоя с 40 мкА сможет? Ась? :)

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

Георгий

Mon May 02 2005 09:29, George Shepelev wrote to Alex Kouznetsov:

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

GS> Аксиомы о хорошем стиле программирования придумал не я, моё дело GS> только научить ими грамотно пользоваться.

Это не аксиомы, это эмпирические правила, т.е. разумные гипотезы практической направленности.

GS> Кстати, тебя не очень смутила "аксиома" Брусенцова об "истинном троичном GS> RISCе"? ;-)

Это тоже гипотеза. Доказательству он посвятил свою жизнь.

AK>> При этом тебе _кажется_, что эти фитюльки в самом деле являются AK>> аксиомами, поэтому ты к ним относишься некритически.

GS> Мне достаточно, что практика убедительно подтверждает теорию. GS> Практические нужды удовлетворены, что ещё нужно?

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

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

Привет George!

RA>> хм. В своих "GSM - проводная телефония" переходах при реализации RA>> функций АТС (коммутация, формирование вызывного напряжения) я RA>> применял RA>> связку оптронов CNY и транзюков BC846.

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

Интересно - вызывной сигнал с емкостей, заранее заряжаемых от линиии, формировал? Как на все это реагирует входящая (питающая твою систему) линия?

Rifkat 03 мая 2005 года