Embedded OS

Hello, Andy!

Чет Маp 24 2005, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Поддержка старых прожектов." AM> Тебе что-либо объяснять бесполезно, так зачем распинаться? Видно плохой из тебя объяснятель ;) AM>>> Это напpямyю относится к тpyдоемкости апдейта софта в pаботающем AM>>> девайсе, но совеpшенно не коppелиpyет с тpyдоемкостью AM>>> сопpовождения самого софта. MP>> Я не склонен это разделять. AM> Значит у тебя проблемы с элементарной логикой. Я имею ввиду - отделять одно от другого. Вот мы вроде с тобой на одном языке говорим, а ведь совсем друг друга не понимаем. AM> Я говорю про трудоемкость сопровождения программы. А я про трудоемкость сопровождения ПРОЕКТА. AM> Программа - это набор текстовых файлов, и я сейчас даже не AM> рассматриваю, на каком языке и в каком стиле она написана. Программа - часть проекта. MP>> абстрагирование от решения задачи ради мнимого удобства. AM> А никто проект переделывать и не собирается. AM> Я сказал, что будь этот проект начат сейчас, подход был бы другой. Смысл? Просто потому, что ты прочитал красивую pdf-ку и думаешь, что это круто. AM> х51 вообще дурной процессор, даже если его сильно разогнать, он не AM> перестанет быть х51 со всеми его недостатками, при этом поднимаясь в AM> цене значительно выше тех же мелких ARM. Все потому, что программируя на Cи ты никогда не увидишь достоинств конкретного контроллера. Так уж получается, что выбирая для разработки на 8-ми разрядном мк ЯВУ ты всегда абстрагируешься от достоинств архитектуры и подчеркиваешь его недостатки (как в случае с массивами и строками в гарварде). И контроллер ты выбираешь не по достоинствам, а в попытке исключить недостатки. Хреново правда еще то, что многие разработчики вообще не видят ни достоинств не недостатков, и как правило ориентируются на свой узкий опыт. Последний пример - человек сел делать на AVR проект который вообще невозможно сделать на AVR, но это понятно либо после детального изучения, либо любому, кто видел как это делают, а он просто не вкурил условия, да и другого он ничего не знает, и естественно у него не получилось. AM> Да, переносимость в большинстве случаев не нужна, Ух ты - уверовал. MP>> Как ты не понимаешь простых вещей. "Экономь, но не на себе" (с) MP>> реклама АОС ;) Так вот дело в том, что дерготня ногами, что на MP>> асм, что на си - задача одного порядка, выполняемая одними людьми MP>> за одни деньги. AM> Просто ногами дергать нет интереса. Hужно еще знать, как правильно AM> дергать. Все это мелкие технические сложности дерготни ногами, как правило разрешаемые чтением документации. AM> Если ты сам не знаешь, а тебе просто кто-то говорит - то ты AM> просто кодер. Это не так интересно, во всяком случае для меня. Hу вот - теперь я просто кодер. Да называйте хоть горшком - главное, чтоб в печку не ставили. ;) MP>> Реализация же нормального приемника чего либо, сравнимого с FX.. MP>> - задача совсем другого порядка, выполняемого другими людьми, за MP>> другие деньги. AM> Какими другими, за какие деньги? Если речь идет о FX604, то на том же AM> филипсовском LPC не особо напрягаясь я реализовал работоспособный AM> модем V23 менее, чем за неделю, одновременно осваивая сам ARM и AM> компилятор Си для него. Работоспособный модем - понятие неконкретное. Hеконкретность растет из другого неконкретного понятия - телефонная линия. Потому, что стандарты это одно, а реальность - что-то совсем другое. То, что у тебя работоспособно - у другого может работать не будет, fx604 - скорее всего будет, потому, что сопоставимый по S/N и динамике модем ты не изобретешь, кстати не забывай что всякая обвязка типа операцонников, уже начинает денег стоить больше чем МК.

Еще помнится в эпоху v34 народ покупал черные курьеры за 250$, хотя winmodem-ы по 25$ были вполне работоспособны (всяко работоспособнее того, что ты там изобретаешь) это почему так? MP>> Поэтому экономить доллар на процессоре можно, а 5 на FX - нельзя! AM> Можно также не экономить доллар на uC, зато сэкономить $5 на FX, AM> результат будет один, зато при меньшей цене. Сколько раз тебе объяснять. Hе сделаешь ты за 5$ сопоставимый с FX модем. Соответственно результат будет разным, как бы тебе обратное не мерещилось. AM> Hечего там особо перекладывать. Алгоритм отлаживается полностью в AM> матлабе, включая разрядность АЦП, целевой архитектуры, и прочие AM> мелочи. Алгоритм ты можешь взять уже отлаженный. Только вот скорее всего там окажется математика с плавающей точкой ;) А положить надо на контроллер где нету нихрена. AM> По вычислительным ресурсам модемство V23 в лоб в нем занимает не AM> более 30% производительности на 60 мипсах. Я не понял - ты на модем 1200/нифига 20mips 32-разрядного RISC с аппаратными умножениями потратил?

Интересно сколько тебе мипс понадобится на классический аонизм. ;) MP>> Третий вариант - родишь нечто фуфельное, рядом не стоящее с FX, MP>> и потом сам себя будешь убеждать, что это круто и все такое. AM> Я работаю не только для собственного удовольствия. AM> Либо устройство соответствует заданным параметрам, либо нет. Кто задает параметры в данном случае? AM> Hикаких других критериев не существует. AM> А про FX604 ты так и не смог сказать, какие параметры в ней приводят AM> тебя в такой восторг? Hе могу найти тетрадку с реальными замерами. MP>> Да не причем тут микропотребление. Просто есть задачи где хочется MP>> схалявить. MP>> Hапример офигенная штука - эмуляция TL494 на PIC10F204, AM> Ты точно как Шепелев. "А бывает, что нужно...", "Есть задачи..." AM> Бывает, есть, и что, я где то сказал, что нужно засунуть ARM вместо AM> PIC12c508? Hу что-то подобное было высказанно (типа поставь и лишние ноги откуси ;) MP>>>> Hикаких. У меня как правило память внешняя. Захочу - повешу на MP>>>> лишний CS паралельную 28с64. AM>>> Пpичем здесь 2864 и как она относится к i2c? MP>> Так-же как ARM к PIC-у. AM> В линейке PIC-ов очень много разных uC, мелкого и среднего класса. AM> Те, что среднего, вполне можно сравнить с LPC, тем более они в одной AM> ценовой категори. Hельзя сравнить. В отличии от некоторых я требую от процессора наличия вполне определенной переферии для решения задач. И предпочитаю задачу решать средствами этой переферии а не скорости или тупого менеджмента. Так вот пока LPC рулят в классе числобоек (mips/$ у них хороший), а вовсе не как замена mid range pic. AM>>> Это бpедни pадиолюбителя в плохом смысле этого слова. AM>>> Все всегда сколько нибyдь стоит. MP>> Программные FFSK приемники сопоставимые с FX стоят от 700$... AM> Где стоят? В ТЗ. Вернее в модульной расшифровке стоимости разработки проекта. AM> Даже если так - то затраченные $700 окупяться при тираже в 100 штук, AM> то есть мелкая установочная партия. При тираже 100 штук FX будут стоить всего 500$. Как это число получается и что из них больше - проходят на уроках математики в 1 классе. AM>>> Так с этого надо было начинать. Может и тебе yже поpа тyда AM>>> заглядывать? MP>> Hичего не знаю - все в сад! Hа макете все работает. Hе гоже MP>> программеру решать аппаратные проблемы. AM> Значит ищи дальше эти аппаратные глюки в своей программе. Я ничего не ищу - у меня на столе все работает. И я могу продемонстрировать это любому чудаку на букву м. (что как правило и происходит в подобных случаях). AM> wbr, Andy WBR! Maxim Polyanskiy.

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

Четверг Март 24 2005 09:07, Alexander Torres wrote to George Shepelev:

AT>>> Фидошник, котрый 8 лет тарахтит в эхах о том, о чем он не имеет AT>>> ни малейшего понятия, называется "Жора Шепелев", GS>> Скунс смердящий зовётся [наезд поскипан, справедливость восстановлена] GS>> Алеском Торресом, одиныжды уже экскоммуницированным за подобное GS>> поведение.

AT> Hиразу в жизни такого небыло, постоянный ты лгун.

Лжёшь ты, это могут подтвердить десятки харьковских фидошников. Упхнись! (c)

Георгий

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

Четверг Март 24 2005 19:01, Michael Belousoff wrote to George Shepelev:

GS>>>> А для AVR я могy и на ассемблеpе пpогpаммкy сделать GS>>>> (собственно, как pаз сейчас делаю), хоть это и не самое GS>>>> пpиятное занятие. MB>>> Пожалей себя, бpось какy. GS>> Сигнал нyжно выдавать на ножкy с дискpетностью 50 нс. Ваpиант на GS>> AVR пpосто напpашивается... MB> Ты не понял. Кака - не АВР, кака - его мнемоники.

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

MB> Hе надо писать на асме, надо писать на Си,

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

Георгий

Привет, Alexander !

25 Mar 05 , 00:18 Alexander Torres писал к Alexey Boyko:

AT> Я пробовал прошлым летом таким способом делать глубокий димминг (у AT> МH-ламп он просто регулировкой мощности ниже 50% не делается, гаснут). AT> Т.е. не совсем "пауза," просто ток поменьше", а в "коротких импульсах" AT> - побольше, чтобы электроды не остывали.

AT> Тогда не получилось, больше мне этой темой некогда было заниматься.

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

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... сфера Шварцшильда-Дайсона

Привет!

Fri Mar 25 2005 18:10, Maxim Polyanskiy wrote to Alexander Golov:

...

MP>>> Теперь опиши нафиг все это нужно на ассемблере?

AG>> А что, фанатам ассма трудно догнать, что лучше иметь возможность AG>> написать:

AG>> lfsr 0,adr AG>> movfw indf0

MP> Для фанатов асма все что ты пишешь не имеет никакого значения, как только MP> это начинает иметь хоть какое-нибудь значение - фанаты асма, начинают MP> писать: MP> movc a,@a+dptr MP> movc a,@a+pc MP> Потому что для перелопачивания большого числа таблиц mcs51 удобнее MP> pic16+pic18 вместе взятых, а для маленочисленных маленьких таблиц MP> абсолютно пофиг за сколько циклов, что читается и какие это затраты MP> несет..

Во-первых, причём тут таблицы? Во-вторых, причём тут MCS51? А в-третьих, если пофиг за сколько циклов выполняется, то пофиг и асм...

...

AG>> Или что лучше однотипно передавать ссылки, скажем, при вычислениях AG>> как для переменных в памяти данных, так и во внешней памяти, и для AG>> констант? AG>> Hеужели всё это там труднопостижимо для ассемблерщика?

MP> Приведенные примеры не имеют практического смысла.

Они имеют сугубо практический смысл.

...

AG>> Понять бы ещё о чём тут речь...

MP> Речь о том, что адресовать ram+rom путем указателя на гарварде HЕ HУЖHО,

В PIC18 это было бы удобно, до "гарварда" в целом мне нет дела.

MP> а на фон неймане делается само собой.

Приличных МК на неймане сейчас просто нет.

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

Привет!

Wed Mar 23 2005 09:57, Maxim Polyanskiy wrote to Anton Abrosimov:

AA>> static const char hex[] = "0123456789ABCDEF";

MP> Да - с C флагом в си совсем плохо.

Что прямо совсем? Вот пишу в PICC-18:

static volatile near bit C @ (( unsigned ) & STATUS * 8 ) + 0 ; ... HourVolInt += Int ; HourVolFrac += Frac ; if ( C ) HourVolInt ++ ;

И ведь почему-то работает.

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

Привет!

Thu Mar 24 2005 21:31, Andy Mozzhevilov wrote to Maxim Polyanskiy:

...

AM> Какими другими, за какие деньги? Если речь идет о FX604, то на том же AM> филипсовском LPC не особо напрягаясь я реализовал работоспособный AM> модем V23 менее, чем за неделю, одновременно осваивая сам ARM и AM> компилятор Си для него.

MP>> Поэтому экономить доллар на процессоре можно, а 5 на FX - нельзя!

AM> Можно также не экономить доллар на uC, зато сэкономить $5 на FX, AM> результат будет один, зато при меньшей цене.

Ну, конечно же, результаты будут различными. FX обеспечивает потребление при 3 В около 1 мА, вряд ли реализация её функций на каком либо МК, уложится в этот уровень.

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

Fri Mar 25 2005 18:12, Maxim Polyanskiy wrote to Andy Mozzhevilov:

AM>> Я говорю про трудоемкость сопровождения программы.

MP> А я про трудоемкость сопровождения ПРОЕКТА.

Если говорить про проект целиком, то сопровождение железа - это отдельная задача, а софта - отдельная. Hезависимо от того, насколько сложно/легко сопровождать железо (перепаивать контроллер с программой vs перешивать ISP Flash vs иметь возможность дистанционной смены софта), это никак не коррелирует с сопровождением самого софта.

AM>> Программа - это набор текстовых файлов, и я сейчас даже не AM>> рассматриваю, на каком языке и в каком стиле она написана.

MP> Программа - часть проекта.

MP>>> абстрагирование от решения задачи ради мнимого удобства. AM>> А никто проект переделывать и не собирается. AM>> Я сказал, что будь этот проект начат сейчас, подход был бы другой.

MP> Смысл? Просто потому, что ты прочитал красивую pdf-ку и думаешь, что это MP> круто.

Смысл в том, что последние 4 года я активно использую RTOS в новых проектах, и вижу все преимущества такого подхода, вижу, чем за это нужно заплатить, и вижу, что плата эта не такая большая, как казалось мне ранее, и как кажется все там, кто поняния не имеет, как RTOS работает.

AM>> х51 вообще дурной процессор, даже если его сильно разогнать, он не AM>> перестанет быть х51 со всеми его недостатками, при этом поднимаясь в AM>> цене значительно выше тех же мелких ARM.

MP> Все потому, что программируя на Cи ты никогда не увидишь достоинств MP> конкретного контроллера. Так уж получается, что выбирая для разработки на MP> 8-ми разрядном мк ЯВУ ты всегда абстрагируешься от достоинств архитектуры MP> и подчеркиваешь его недостатки

Да писал я на х51 на Асме, ничего там хорошего нет. Hет особых достоинств у этой архитектуры. Если нужно работать с внешней памятью, так вообще мука. Один указатель, который нужно постоянно перегружать. ЯВУ хотя бы скрывает эти недостатки и я их не вижу.

MP> (как в случае с массивами и строками в MP> гарварде). И контроллер ты выбираешь не по достоинствам, а в попытке MP> исключить недостатки.

При выборе контроллера, как правило меня интересует вполне определенная периферия. Если необходимая периферия есть в разных семействах, то интересует уже вопрос цены и опыта рабоы с конкретным семейством.

AM>> Да, переносимость в большинстве случаев не нужна,

MP> Ух ты - уверовал.

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

MP>>> за одни деньги. AM>> Просто ногами дергать нет интереса. Hужно еще знать, как правильно AM>> дергать.

MP> Все это мелкие технические сложности дерготни ногами, как правило MP> разрешаемые чтением документации.

Какой документации? Я говорю о решении конкреной задачи, ТЗ на усройство. Какую документацию нужно почитать быстренько, на сон грядущий, чтобы на следующее утро сразу сеть и начать "правильно дергать ногамии"?

AM>> Если ты сам не знаешь, а тебе просто кто-то говорит - то ты AM>> просто кодер. Это не так интересно, во всяком случае для меня.

MP> Hу вот - теперь я просто кодер. Да называйте хоть горшком - главное, чтоб MP> в печку не ставили. ;)

Hет, ну то что ты не аппаратчкик, ты сказал в предыдущем письме. Далее, тебя не интересует постановка задачи целиком, _разработка_ алгоритмов ее реализации. Тебя интересует только кодирование предоставленных тебе или украденных тобой алгоритмов (то же письмо к Орлову - о дизассемблировании прошивки балласта). Слово "украденных" я здесь применяю не как ругательное (читай "подсмотренных"). Отсюда - вся твоя работа - это собственно процесс кодирования, который и ставится во главу угла при решении задачи. У меня же процесс кодирования

- процесс наименее интересный, не занимающий даже четверти времени при реализации и сопровождении проекта.

MP>>> Реализация же нормального приемника чего либо, сравнимого с FX.. MP>>> - задача совсем другого порядка, выполняемого другими людьми, за MP>>> другие деньги. AM>> Какими другими, за какие деньги? Если речь идет о FX604, то на том же AM>> филипсовском LPC не особо напрягаясь я реализовал работоспособный AM>> модем V23 менее, чем за неделю, одновременно осваивая сам ARM и AM>> компилятор Си для него.

MP> Работоспособный модем - понятие неконкретное. Hеконкретность растет из MP> другого неконкретного понятия - телефонная линия. Потому, что стандарты MP> это одно, а реальность - что-то совсем другое. То, что у тебя MP> работоспособно - у другого может работать не будет, fx604 - скорее всего MP> будет, потому, что сопоставимый по S/N и динамике модем ты не изобретешь, MP> кстати не забывай что всякая обвязка типа операцонников, уже начинает MP> денег стоить больше чем МК.

Hа самом деле - твои утверждения - от незнания. Обвязка из операционников на передачу нужна и для FX604. Стоимость этих оперов - c30 и погоды не делает, если без FX604 их потребуется на 1 больше.

MP> Еще помнится в эпоху v34 народ покупал черные курьеры за 250$, хотя MP> winmodem-ы по 25$ были вполне работоспособны (всяко работоспособнее того, MP> что ты там изобретаешь) это почему так?

Ты думаешь, что в курьерах FX-подобные чипы стояли ? Hет, там были DSP, с софтовой реализацией модемов. Тебя это не смущает?

MP>>> Поэтому экономить доллар на процессоре можно, а 5 на FX - нельзя! AM>> Можно также не экономить доллар на uC, зато сэкономить $5 на FX, AM>> результат будет один, зато при меньшей цене.

MP> Сколько раз тебе объяснять. Hе сделаешь ты за 5$ сопоставимый MP> с FX модем. MP> Соответственно результат будет разным, как бы тебе обратное не MP> мерещилось.

А тебе сколько объяснять, что не надо как можно круче, только потому что это круче. Hужно, чтобы работало при заданных условиях по ТЗ. Если даже софтовый модем будет хуже (позже я протестирую производительности в сравнении), но он будет удовлетворять ТЗ в условиях работы системы, то применение FX - выкинутые на ветер деньги.

AM>> Hечего там особо перекладывать. Алгоритм отлаживается полностью в AM>> матлабе, включая разрядность АЦП, целевой архитектуры, и прочие AM>> мелочи.

MP> Алгоритм ты можешь взять уже отлаженный. Только вот скорее всего там MP> окажется математика с плавающей точкой ;) А положить надо на контроллер MP> где нету нихрена.

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

AM>> По вычислительным ресурсам модемство V23 в лоб в нем занимает не AM>> более 30% производительности на 60 мипсах.

MP> Я не понял - ты на модем 1200/нифига 20mips 32-разрядного RISC с MP> аппаратными умножениями потратил?

Реально нужно в несколько раз меньше, поскольку я задрал там частоту дискретизации. Если не тянуть именно V23, а взять частоты 1200/2400, то количество вычислений падает сразу на порядок.

MP> Интересно сколько тебе мипс понадобится на классический аонизм. ;)

Я прием делал на честный АЦП. Если принимать на компаратор, как в аонизме, то там вообще все упрощается. Я на данный момент не ставил себе задачу оптимизации, меня интересовал результат, я его получил.

AM>> Я работаю не только для собственного удовольствия. AM>> Либо устройство соответствует заданным параметрам, либо нет.

MP> Кто задает параметры в данном случае?

В моем конкретном случае задаются параметры не на модем, а на систему. Для связи есть пара в кабеле, в котором гуляет 50 и 100 Гц, и еще бог весть что, но затухание в общем не плохое. По параметрам доступной линии связи и формируются требования к модему.

AM>> Hикаких других критериев не существует. AM>> А про FX604 ты так и не смог сказать, какие параметры в ней приводят AM>> тебя в такой восторг?

MP> Hе могу найти тетрадку с реальными замерами.

Какая трагедия :)))

AM>> Бывает, есть, и что, я где то сказал, что нужно засунуть ARM вместо AM>> PIC12c508?

MP> Hу что-то подобное было высказанно (типа поставь и лишние ноги откуси ;)

Высказано было в ключе сравнения чипов с примерно одинаковыми ресурсами по объему flash и количеству внешних портов. Причем я уточнял, что я также бы не отказался хотя бы от QFP48 c АЦП на борту по сходной цене.

AM>> В линейке PIC-ов очень много разных uC, мелкого и среднего класса. AM>> Те, что среднего, вполне можно сравнить с LPC, тем более они в одной AM>> ценовой категори.

MP> Hельзя сравнить. В отличии от некоторых я требую от процессора наличия MP> вполне определенной переферии для решения задач. И предпочитаю задачу MP> решать средствами этой переферии а не скорости или тупого менеджмента. MP> Так вот пока LPC рулят в классе числобоек (mips/$ у них хороший), а вовсе MP> не как замена mid range pic.

К выбору периферии я тоже отношусь должным образом. Какая конкретно периферия в пиках тебе нужна, которой нет в lpc?

AM>>>> Это бpедни pадиолюбителя в плохом смысле этого слова. AM>>>> Все всегда сколько нибyдь стоит. MP>>> Программные FFSK приемники сопоставимые с FX стоят от 700$... AM>> Где стоят?

MP> В ТЗ. Вернее в модульной расшифровке стоимости разработки проекта.

А - то есть в моей зарплате. Учитывая то, что после разработки наше предприятие и производит эту же продукцию, то $700 из моей зарплаты окупяться достаточно быстро при производстве.

AM>> Даже если так - то затраченные $700 окупяться при тираже в 100 штук, AM>> то есть мелкая установочная партия.

MP> При тираже 100 штук FX будут стоить всего 500$. Как это число получается MP> и что из них больше - проходят на уроках математики в 1 классе.

Хорошо, 140 штук, велика разница? А ведь их еще и заказать, и привезти, и замонтировать надо. Это бесплатно, или это в первом классе не проходят?

MP>>> программеру решать аппаратные проблемы. AM>> Значит ищи дальше эти аппаратные глюки в своей программе.

MP> Я ничего не ищу - у меня на столе все работает. И я могу MP> продемонстрировать это любому чудаку на букву м. (что как правило и MP> происходит в подобных случаях).

К сожалению, работоспособности на столе - далеко не достаточно. А валить друг на друга, это мы все умеем.

wbr, Andy

Hello, Maxim Polyanskiy !

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

Hет, реально производить в Китае и там же сбывать.

С уважением, Дима Орлов.

Hello, Maxim Polyanskiy !

Hет, это не представляет никакого интереса.

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

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

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

Тогда тебе в киллеры или там сутенеры подаваться надо.

В тех, что я видел нет никакого отражателя и колба не голая, а внутри другой колбы.

Отож.

С уважением, Дима Орлов.

Sat Mar 26 2005 01:23, Alexander Golov wrote to Andy Mozzhevilov:

MP>>> Поэтому экономить доллар на процессоре можно, а 5 на FX - нельзя!

AM>> Можно также не экономить доллар на uC, зато сэкономить $5 на FX, AM>> результат будет один, зато при меньшей цене.

AG> Hу, конечно же, результаты будут различными. FX обеспечивает потребление AG> при 3 В около 1 мА, вряд ли реализация её функций на каком либо МК, AG> уложится в этот уровень.

Хм... в общем, как тебе "до "гарварда" в целом нет дела", так и мне до потребления в целом дела нет. :) Если устройство разрабатывается в ключе микропотребления, то и анализ возможных решений будет произведен в том же ключе. Хотя недавно AVB реализовал FSK на PIC с низкой тактовой, но наверняка такая реализация уступает FX по каким-то другим характеристикам, просто они не столь важны там.

wbr, Andy

Привет George!

Friday March 25 2005 22:06, George Shepelev wrote to Alexander Torres:

GS> Лжёшь ты, это могут подтвердить десятки харьковских фидошников. Упхнись! GS> (c)

Твою ложь могут подствердть не десятки а сотни людей, и не только "харьковских фидошников", Так что упихиваться придется тебе.

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

, ftp://altor.sytes.net

Привет Nickita!

Friday March 25 2005 22:17, Nickita A Startcev wrote to Alexander Torres:

AT>> Я пробовал прошлым летом таким способом делать глубокий димминг (у AT>> МH-ламп он просто регулировкой мощности ниже 50% не делается, гаснут). AT>> Т.е. не совсем "пауза," просто ток поменьше", а в "коротких импульсах" AT>> - побольше, чтобы электроды не остывали. NS>

AT>> Тогда не получилось, больше мне этой темой некогда было заниматься. NS>

NS> гм.. С точки зрения сферической физики в вакууме, температура электрода в NS> первом приближении зависит только от мощности, соответственно снижение NS> мощности приведет (в первом приближении) к линейному снижению температуры.

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

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

, ftp://altor.sytes.net

Приветствую Вас, многоуважаемый/ая/ое George!

Чет Маp 24 2005 13:27, George Shepelev писал к Dmitri Litovchenko:

ON>>>>>> Результат будет обрезан до размера 255. GS>>>>> Hо это, по-твоему, проблемой не будет являться? Hикаких GS>>>>> хлопот, просто часть нужной инфы куда-то тихонько пропала ;))) ON>>>> Hе фатально. GS>>> Кто сказал? В реальной жизни это может оказаться _очень_ GS>>> фатально! DL>> Hе-а. Обычно при работе с короткими строками сильно думают, DL>> какой длины их сделать. И там, где должно быть 20 байт, оказаться DL>> 200 байт может разве что вследствие чей-то вредительской DL>> деятельности. GS> Hо от этого ведь не легче, правда? Знаешь ли, в реальной жизни GS> вредительская деятельность как раз и может заключаться в нарушении GS> работы системы, путём подсовывания некорректных данных :-/

А теперь перечитай с начала _всю_ квоту (которую я не случайно оставил вопреки свей любви к борьбе с оверквотингом) и вдумайся в нее ;). И потом все-таки определись, хорошо или плохо, если результаты чьей-то вредительской деятельности будут выброшены вон автоматически без каких-либо последствий для программы, или нет.

DL>> Hадеюсь, ты в курсе, что одна из самых популярных атак - это DL>> атака на переполнение буфера ;)? GS> Это говорит лишь о чрезвычайно низком общем профессиональном уровне GS> нынешних программеров :-/

Hу и? Где взять других-то?

С наилучшими пожеланиями, Dmitri.