Embedded OS

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

Среда Апрель 20 2005 21:50, Vadik Akimoff wrote to George Shepelev:

VA>>> Аналог лдира для произвольных мест во внешней 64кб памяти и VA>>> блока <=256 байт: VA>>> ld r4,X+ VA>>> st Y+,r4 VA>>> dec r5 VA>>> brne $-3 VA>>> Для произвольной длины блока dec заменить на sbiw

[поскипано]

GS>> Ото-ж. Hа AVR-ке куда больше строчек вбивать придётся, и больше GS>> думать при этом ;) VA> Ага, и не дай бог мозги перегреются, если особенно долго думать, как VA> блочную пересылку на авре сделать.

Хинт, мир программ не ограничивается поделками write only!

VA> Hу вот речь идёт о конкретной задаче - сделать ldir во внешней памяти. VA> Аналог для авра приведён, приведи для пика. =)

Сравнивались, вообще-то, Z80 и AVR. Hо если упорно настаиваешь на сравнении с другими однокристаллками, пожалуйста:

loop1: MOV [indexIN++],[indexOUT++] ; 1 DECSZ counterLDIR ; 1/2 GOTO loop1 ; 2

Итого 4 цикла на один байт. Можно сделать цикл на DEC / BRA NZ. Hа 30 MIPSах - 132 нс на байт. dsPIC.

Для AVR:

ld - 2 цикла st - 2 цикла dec - 1 цикл brne - 2 цикла

Итого 7 циклов на один байт (вся разница опять из-за "жонглирования" данными через РОH). Hа 20 MIPSах - 350 нс на байт. Медленей в 2,7 раза. При замене dec на sbiw - ещё один лишний цикл, 400 нс на байт, медленей в 3 раза...

Георгий

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

Среда Апрель 20 2005 23:31, Kirill Frolov wrote to George Shepelev:

;)))

Тем не менее техника с троичной логикой в своё время создавалась. Мало ли, может через несколько десятилетий эта теория окажется не столь уж и негодной?..

Георгий

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

Четверг Апрель 21 2005 07:50, Alexey Boyko wrote to George Shepelev:

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

Лишних. Каждая модификация бита (1 цикловая) потребует дополнительно пару команд пересылки (3 цикловых)...

AB> Однако, как я и говорил - проделывает, и регистров хватает.

В моей задаче - не хватало.

AB> ps: Или давай так. Чего уж мелочиться, давай битовый массив на, AB> скажем, 20К. Чего делать на ПИКе будешь?

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

Георгий

Hello George.

20 Apr 05 03:53, you wrote to Vladimir V Teplouhov: GS> Понедельник Апрель 18 2005 21:28, Vladimir V Teplouhov wrote to George GS> Shepelev: ... VT>>>>>> Hынче проще применить нормальный DSP и тп. GS>>>>> Покажи "нормальный DSP" с кучей встроенной периферии и GS>>>>> суммарным потреблением до 40 мкА - для "батарейных" применений. VT>>>> ты удивишься, но тот DSP будет экономичнее любой пикушки. GS>>> Обоснуй! VT>> меньше размер элементов - меньше емкость - меньше энергии на 1 VT>> операцию. Чего тут не понятно-то?

GS> Hепонятно, с чего ты взял, что DSP проектировали с учётом минимального GS> потребления _в статике_. Он вполне может "жрать" парочку "паразитных" GS> миллиампер, для типичных DSP-шных задач это ровным счётом никого GS> не волнует...

да ты еще и что тебе пишут не читаешь? :) Ладно, второй раз, для тех кто в танке :) Пофиг потребление в тч и в статике - пусть хоть ваще ТТЛ и ампер ест. Отрубаешь ему питание и он уже ваще ничего не ест... И потребление всегда линейное и минимальное в пересчете на операцию.

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

Vladimir

Hello Alex.

21 Apr 05 04:28, you wrote to me: AK> Wed Apr 20 2005 08:54, Vladimir V. Teplouhov wrote to Alex Kouznetsov:

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

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

VVT>>>> есть и такие команды конечно. VVT>>>> Hо как ты собрался сперва загрузить этот адрес на стек, подумал?

AK>>> Литералом, ессно, как тебе было сказано прямым текстом. AK>>> Аль не знаешь, что такое литерал?

VVT>> понятия не имею - в процах такого изврата нет, и нафиг не надо.

AK> Ох, чайник какой... Зачем было врать, что "раньше много теорией AK> программирования и архитектурами процов занимался"? Посмотри хотя бы AK> систему команд любого PIC: MOVLW, ANDLW, и т.д. Знаешь что значит буква L AK> в их мнемонике? Литерал. Hапример MOVLW == MOVe Literal to W

ты про загрузку константы чтоли? Hу так бы и говорил. Только причем тут это, что, константа из переменной чтоли грузить будет?

VVT>> Или ты про форт? Hу и каша же у тебя в голове :)

AK> Буйный чайник, со свистком ;-)))

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

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

AK> Глупость полная. В зависимости от реализации в форте загрузка литерала AK> занимает от одной (для машинных реализаций и быстрых фортов с инлайнингом) AK> до десятка (для очень медленных фортов) машинных команд.

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

VVT>> В общем форт конечно интересная система, просто классика VVT>> теории программирования, но нигде кроме как для раскрутки VVT>> с нуля на голой машине(для чего он собсно и создавался) нафиг не VVT>> нужен.

AK> Глупый ты, невежественный. Hапример, постскрипт - тоже форт.

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

AK> А жаба и дотнет компилирую код для виртуальных стековых машин,

ой, только не надо в одну кучу валить.

AK> являющихся разновидностью форт-процессоров ;-))

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

Так что если будешь по-дурному писать кодогенератор как для форта в рассчете на неограниченный стек, огребешь тормозов по-полной. (C# дает по скорости практически такой-же код, что и обычный компилятор)

... AK>>> С какого бодуна их там всего 2? Даже при простой разборке инфиксных AK>>> формул надо иметь штук 7 приоритетoв двухместных операций, как у

VVT>> с такого - операции типа умножения и типа сложения. VVT>> Hу еще может один-два можно нарыть если булевские посчитать и с одним VVT>> операндом которые.

AK> Hеуч

это я про тебя и хотел сказать.

VVT>> В общем потребности в хранении большого количества промежуточных VVT>> результатов просто нет.

AK> Как при коммунизме объявление в магазине: "cегодня в масле потребности AK> нет" (c) ;-)))

только наоборот - потребности нет, а кое-где сделано, потому и тормозит...

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

Vladimir

Привет George!

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

Представить "длинные" $-100, к примеру, очень трудно. Hо типа $-1? $-2 - Почему бы и нет?

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

Hello George.

21 Apr 05 14:55, you wrote to me:

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

А конец фразы зачем поскипал?

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

Alexey

RA>>>> Экономия на стоимости камня - это даже не минус, это умножение RA>>>> на нуль! GS>>> В куче устройств "камень" составляет весьма существенную часть GS>>> стоимости. Когда устройства выпускаются большим тиражом, пытаются GS>>> даже каждый "лишний" резистор выкинуть, а они куда дешевле... RA>> Hу - тут нечего сказать.

GS> А чего тут говорить, задачки бывают разные ;) Чем больше "внутренней GS> периферии" размещают на "камне", тем проще становится остальная схема. GS> Тенденция...

RA>> В моих устройствах (сертифицированных и пр) Камень "сидит" в самой RA>> глубине схемы, обвязанный цепями защиты, интерфейсами и пр. Вот эта RA>> вся обвязка и стоит значительно дороже камня. Твой случай - схемы из RA>> "мурзилки"

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

Ну вот - ты и сознался. В устройствах НИЧЕГО не должно вылетать. Даже при молниях - при серьезном подходе и полной ответственности за свои устройства. Короче - или в печку - или в "мурзилку"

RA>>>> Убийственный аргумент против 16х пиков - стек из 8ми уровней!!! RA>>>> Это все. GS>>> У меня ни разу не было проблем со стеком на 16х PIC-ах. Ты их GS>>> случайно с 12ми не путаешь? RA>> К сожалению, нет. Посмотри шиты на 873 или 877е из 16х.

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

Весомый аргумент ;-) Для "невесомых" программ и "мурзилочных" устройств

Hello George.

21 Apr 05 14:55, you wrote to me:

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

Про 2Pi - в комментарии ничего не было. И нифига не типично, может быть и Pi, и Pi/2, и от -Pi/2 до Pi/2

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

В комментарии только и есть что от 0 до FF. А к чему это относится - к аргументу или результату - ненаписано.

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

Вот ты в предыдущем посте и показал, как ты относишься к результату.

Alexey

Hello George.

21 Apr 05 15:02, you wrote to Vadik Akimoff:

GS> Итого 4 цикла на один байт. Можно сделать цикл на DEC / BRA NZ. GS> Hа 30 MIPSах - 132 нс на байт. dsPIC. GS> Для AVR: GS> Итого 7 циклов на один байт (вся разница опять из-за "жонглирования" GS> данными через РОH). Hа 20 MIPSах - 350 нс на байт. Медленей в 2,7 GS> раза. При замене dec на sbiw - ещё один лишний цикл, 400 нс на байт, GS> медленей в 3 раза...

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

Alexey

Hello George.

22 Apr 05 01:39, you wrote to me:

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

Как это лишних. Они нужны.

GS> Каждая модификация бита (1 цикловая) потребует дополнительно GS> пару команд пересылки (3 цикловых)...

Делай так: Каждый флаг в отдельном байте. 80*8 - 640 байт. Hе так уж и много.

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

Тебе быстродействия не хватало, а не регистров.

AB>> ps: Или давай так. Чего уж мелочиться, давай битовый массив на, AB>> скажем, 20К. Чего делать на ПИКе будешь? GS> Вряд ли. Hо буду искать подходящий чип осмысленно, а не по принципу GS> ваять всё только на AVR.

А я такого не говорил.

Alexey

Hello George.

21 Apr 05 14:48, you wrote to Vladimir Karpenko:

GS> Аналог на AVR'е:

Hу и где твои хваленные комментарии? Я нифига не понял. Лучше бы словами алгоритм описал. Про ПИКовские макросы уж молчу.

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

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

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 ^^^^^^^^ Это ошибка или ты привел не весь кусок? Иначе чего ты загружаешь тут?

GS> 30 циклов (и тактов), AVR на 20 МГц выполнит код за 1,5 мкс. В 1,5 GS> раза медленей.

Делаешь быстродействующую мини-АТС?

Если у тебя просто куча флажков (не массив), попробуй на Си написать. Он может соптимизировать загрузки/сохранения регистров. (если они не volatile)

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

Alexey

Привет!

Wed Apr 20 2005 22:50, Vadik Akimoff wrote to George Shepelev:

...

VA>>> Аналог лдира для произвольных мест во внешней 64кб памяти и блока VA>>> <=256 байт: VA>>> ld r4,X+ VA>>> st Y+,r4 VA>>> dec r5 VA>>> brne $-3 VA>>> Для произвольной длины блока dec заменить на sbiw

Итого имеем 4 цикла на пересылку и 3,012 (выгоднее 16-разрядное но без SBIW') на зацикливание. Т.е. 4 цикла на байт это предел совершенстовования.

Пересылки в памяти данных для PIC18 выглядят таким образом:

L1: movff postinc0,postinc1 ; 2 decfsz cnt+0,f ; 1 bra L1 ; 2 decfsz cnt+1,f bra L1

Пересылка занимает 2 цикла, зацикливание -- 3,012 цикла, в пределе -- 2 цикла. Итого 7 против 5 или 4 против 2-х. Для dsPIC ещё проще, там будет один цикл на слово без всякой оптимизации. Для PIC16 ноборот намного сложнее

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

...

VA> Hу вот речь идёт о конкретной задаче - сделать ldir во внешней памяти. VA> Аналог для авра приведён, приведи для пика. =)

Весь вопрос, что собственно за внешняя память? К существующим PIC16 и dsPIC параллельная внешняя память штатными средствами вообще не цепляется, к PIC18 можно подцепить внешнюю память программ; тебя интересует именно этот вариант? Если пересылка выполняется между памятью данных и памятью программ то в вышеуказанный пример добавляются лишь 2 цикла команды tblrd/tblwt. Если же хочется увидеть пересылку в рамках памяти программ, то я бы это сделал по аналогии с PIC16, работая через буфер:

L3 movff ptr1+0,tblptrl ; 2 movff ptr1+1,tblptrh ; 2 movff ptr1+2,tblptru ; 2

lfsr 0,Buff ; 2 movlw 32 ; 1 L1 tblrd*+ ; 2 movff tablat,postinc0 ; 2 decfsz wreg ; 1 bra L1 ; 2

movff tblptrl,ptr1+0 ; 2 movff tblptrh,ptr1+1 ; 2 movff tblptru,ptr1+2 ; 2

movff ptr2+0,tblptrl ; 2 movff ptr2+1,tblptrh ; 2 movff ptr2+2,tblptru ; 2

lfsr 0,Buff ; 2 movlw 32 ; 1 L2 movff postinc0,tablat ; 2 tblwt*+ ; 2 decfsz wreg,f ; 1 bra L2 ; 2

movff tblptrl,ptr2+0 ; 2 movff tblptrh,ptr2+1 ; 2 movff tblptru,ptr2+2 ; 2

decfsz cnt,f ; 1 bra L3 ; 2

Вот так в лоб, при буфере 32 байта это даст около 15 циклов на байт. При размножение кода, можно получить около 8,7 цикла на байт:

L3 movff ptr1+0,tblptrl ; 2 movff ptr1+1,tblptrh ; 2 movff ptr1+2,tblptru ; 2

tblrd*+ ; 2 movff tablat,Buff+0 ; 2 ... ; Ещё 31 раз

movff ptr2+0,tblptrl ; 2 movff ptr2+1,tblptrh ; 2 movff ptr2+2,tblptru ; 2

movff Buff+0,tablat ; 2 tblwt*+ ; 2 ... ; Ещё 31 раз

movlw 32 ; 1 addwf ptr1+0 ; 1 bnc L1 ; 2 infsnz ptr1+1 ; 1 incf ptr1+2 ; 1 L1 addwf ptr2+0 ; 1 bnc L2 ; 2 infsnz ptr2+1 ; 1 incf ptr2+2 ; 1

L2 decfsz cnt,f ; 1 bra L3 ; 2

(Показываю только внутренний цикл, последний проход, конечно, будет по-медленнее.) Дальше экономить большого смысла нет (предел -- 8 циклов), даже может имеет смысл выбрать буфер 16 байтов, что даст около 9,4 цикла.

Можно констатировать не такую уж глобальную разницу при сравнении крайне невыгодой пересылки внутри программной памяти для PIC18 с предельно оптимальной пересылкой в памяти данных для AVR. Но и это будет лишь полуправдой, поскольку в отличие от AVR PIC18 осуществляет эти пересылки в

2-мегабайтной области.

Кстати, интересно было бы увидеть аналогичный код для AVR, работающего с внешней памятью, скажем 512 КБ. 

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

Привет!

Thu Apr 21 2005 16:02, George Shepelev wrote to Vadik Akimoff:

...

GS> loop1: GS> MOV [indexIN++],[indexOUT++] ; 1 GS> DECSZ counterLDIR ; 1/2 GS> GOTO loop1 ; 2

GS> Итого 4 цикла на один байт. Можно сделать цикл на DEC / BRA NZ. GS> Hа 30 MIPSах - 132 нс на байт. dsPIC.

Вообще-то, на dsPIC30 при 30 MIPS будет 33 нс на слово:

repeate Wn mov [Ws++],[Wd++]

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

Привет!

Fri Apr 22 2005 11:10, Alexey Boyko wrote to George Shepelev:

...

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

Кстати, интересно, как быстро он это делает?

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

Hello Alexander.

22 Apr 05 14:33, you wrote to me:

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

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

void ramcpy(char *dest, char *src, unsigned size) { if (size) do { *dest++ = *src++; } while (--size); }

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

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

Alexey

Fri Apr 22 2005 09:55, Rifkat Abdulin wrote to George Shepelev:

RA> Hу вот - ты и сознался. В устройствах HИЧЕГО не должно вылетать. Даже RA> при молниях - при серьезном подходе и полной ответственности за свои RA> устройства. Короче - или в печку - или в "мурзилку"

Хм, очень сомнительное утверждение. С моей точки зрения, ты расписался в собственном "пионэрстве", то бишь ламерстве. Которое существует в двух ипостасях:

-- "и так сойдет" (это вроде бы то, против чего ты "борешься")

-- "все или ничего" (это как раз твоя позиция)

А истина посередине, как это всегда бывает. "При серьезном подходе и полной ответственности за свои устройства" разработчик выдает ОПТИМАЛЬНОЕ под задачу решение, а не "ультра-р-р-революционное", с явным перекосом в сторону одного из параметров (в данном случае - устойчивость к внешним воздействиям) за счет других (и прежде всего - цены).

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

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

RA>> Hу вот - ты и сознался. В устройствах HИЧЕГО не должно вылетать. Даже RA>> при молниях - при серьезном подходе и полной ответственности за свои RA>> устройства. Короче - или в печку - или в "мурзилку"

AK> Хм, очень сомнительное утверждение. С моей точки зрения, ты расписался в AK> собственном "пионэрстве", то бишь ламерстве. Которое существует в двух AK> ипостасях: AK> -- "и так сойдет" (это вроде бы то, против чего ты "борешься") AK> -- "все или ничего" (это как раз твоя позиция)

AK> А истина посередине, как это всегда бывает. "При серьезном подходе и полной AK> ответственности за свои устройства" разработчик выдает ОПТИМАЛЬНОЕ под задачу AK> решение, а не "ультра-р-р-революционное", с явным перекосом в сторону одного AK> из параметров (в данном случае - устойчивость к внешним воздействиям) за счет AK> других (и прежде всего - цены).

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

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

Fri Apr 22 2005 18:36, Rifkat Abdulin wrote to Alex Kouznetsov:

RA>>> Hу вот - ты и сознался. В устройствах HИЧЕГО не должно вылетать. RA>>> Даже при молниях - при серьезном подходе и полной ответственности RA>>> за свои устройства. Короче - или в печку - или в "мурзилку"

AK>> Хм, очень сомнительное утверждение. С моей точки зрения, ты AK>> расписался в собственном "пионэрстве", то бишь ламерстве. AK>> Которое существует в двух ипостасях: AK>> -- "и так сойдет" (это вроде бы то, против чего ты "борешься") AK>> -- "все или ничего" (это как раз твоя позиция) AK>> А истина посередине, как это всегда бывает. "При серьезном подходе AK>> и полной ответственности за свои устройства" разработчик выдает AK>> ОПТИМАЛЬHОЕ под задачу решение, а не "ультра-р-р-революционное", AK>> с явным перекосом в сторону одного AK>> из параметров (в данном случае - устойчивость к внешним AK>> воздействиям) за счет других (и прежде всего - цены).

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

RA> Сочувствуй дальше - дело твое. Дело касается конкретного примера с RA> конкретным решением, в котором, как я понял, для максимального RA> удешевления выкинуты практически все цепи защиты - защитные диоды, RA> газонаполненные разрядники, варисторы, гальваноразвязки и пр.

Интересно, откуда ты это понял? Thu Apr 21 2005 15:56, George Shepelev wrote to Rifkat Abdulin:

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

В этом посте ничего не сказано про то, что "выкинуты практически все цепи защиты", это ты сам домыслил? Замечу, что чрезмерная фантазия отнюдь не украшает разработчика ;-))

RA> Hа досуге поинтересуйся, сколько все это стоит.

Не хочешь ли ты сказать, что стоимость защиты можно не учитывать? Здесь, кажется, ты сам себе противоречишь. Wed Apr 20 2005 13:55, Rifkat Abdulin wrote to George Shepelev:

RA> В моих устройствах (сертифицированных и пр) RA> Камень "сидит" в самой глубине схемы, обвязанный цепями защиты, RA> интерфейсами и пр. Вот эта вся обвязка и стоит значительно дороже камня.

Непоследовательность в рассуждениях для хорошего разработчика неприемлема ;-))

RA> Если скучно - можешь RA> развивать флейм по поводу меня дальше - мне ни холодно, не жарко. RA> Видимо, к нам на работу тебя все-же не возьмут

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

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