Embedded OS

Hello Dima.

18 Mar 05 23:05, you wrote to Olga Nonova:

DO> Изюминка в процедуре зажигания и разогрева лампы.

А кстати, что дает ваша изюминка, чего не дают всякие контроллеры от IRF?

Еще: Какой ток для лампы важнее средний или максимальный? То есть можно ли регулировать ток в лампе ШИМ-ом? А в нити накала?

Alexey

Hello Dmitri.

19 Mar 05 11:43, you wrote to me:

DL> Hу и кто в здравом уме так напишет?

Пример был абстрактный. Призваный показать, что и в паскале не все гладко.

DL> var DL> a,b,s: string; DL> begin DL> a := 'Hello World'; DL> b := 'Good bye World'; DL> s := a + b; DL> end;

DL> A, b, s - размером до 2G.

И на паскале, а не на дельфи.

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

Alexey

Здравствуйте, Уважаемый Dima!

Fri Mar 18 2005 23:05, Dima Orlov wrote to Olga Nonova:

DO> Если ты думаешь, что несколько функций для работы со строками - это все DO> библиотеки, то это твои личные трудности.

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

DO> Привычка тут на предпоследнем месте. И когда Атмел пообщал сделать DO> дешевый контроллер, да еще и ориентированный в точности на наши задачи, я DO> быстренько освоил средства разработки под него и перенес бОльшую часть DO> программных блоков и подготовил обрамление для нужного нам железа DO> (таймеры, uart, PWM, ADC) на 8515 и какой-то Меге. Однако где-то на фазе DO> preliminary datasheet Атмел скис, обещанные через месяц сэмплы не DO> появились и через год, обещанные цены тоже стали вызывать удивление у их DO> представителей, короче не сложилось.

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

DO> Способные же конкурировать с DO> микрочиповскими универсальные кристаллы Атмел не может нам предложить не DO> то что по ценам, оправдывающим затраты на переделку плат и испытания, но DO> и просто ниже микрочиповских. Да, по соотношению возможности/цена они DO> может в чем-то у Микрочипа и выигрывают, но когда половина этих DO> возможностей не нужна - это чистый расход. Да еще эти постоянно слышимые DO> слова что то EEPROM слетел, то сам flash, то им супервизор необходим (еще DO> деньги и место)... Вроде все это потом не находит документального DO> подтверждения, но "ложки нашлись, а осадок остался".

Я понимаю Вашу позицию производственника крупных серий дешевой продукции. Действительно, главная забота там- отжать копейки в себестоимости. Удобства, скорость программирования и отладки софта- на последнем месте в ряду приоритетов. Самостоятельное переписывание стандартных библиотек здесь тоже считается нормальным, лишь бы отжать копейку из себестоимости. Даже с абсолютно ублюдочной системой команд PIC-ов вполне можно смириться ради производственной экономии. Я все это прекрасно понимаю, и нисколечки не осуждаю. Однако, есть и другой мир ембеда. Это мир достаточно уникальных прборов стоимостью в единицы $K и серийностью, ограниченной десятками, максимум сотнями штук. Главным требованием здесь является гибкость модификации, достаточный запас вычислительных ресурсов, и конечно же - скорость выполнения индивидуальных заказов. Hа первый план сразу выходит надежность технических решений и библиотек. Вот почему я столько внимания уделяю вопросам надежности и скорости отладки прилодений. Вопросы отжать копейку- не волнуют.

DO> PIC - никаких. А вот что там делает программа мы тебе не расскажем, это DO> много денег стоит.

Hаверное Вы хотели сказать, что не позволите мне заглянуть в исходники?

DO> Изюминка в процедуре зажигания и разогрева лампы.

Иными словами, в реализации физики процесса, а совсем не в С-компиляторе, на котором писалась программа управления? Кроме того, изюминка обязательно должна быть в цепях сопряжения с высковольтными элементами и с формированием питания для PIC.

Всего Вам Хорошего Ольга

Hello, Alexey Boyko !

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

Действующий.

В нити накала - можно. В лампе - нет.

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

Hello, Olga Nonova !

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

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

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

Сомневаюсь.

Отнюдь. В частности поэтому - никакого ассемблера. Время - один из самых критичных параметров. Мы постоянно куда-то не успеваем.

Hикто не переписывает стандартные библиотеки. Просто если мне нужно вывести положительное целое число в терминал, я пишу функцию вроде вот такой:

/* without lead zero */ void printi(unsigned int i) { unsigned int d = 10000U; char c; char zf=0; if (i != 0) {do { c = i/d+'0'; if (zf |= c != '0') putch(c); i %= d; d /= 10; } while (d > 0); } else putch('0'); }

А не использую стандартный printf, который у меня полпзу и две трети озу отожрет. Hе знаю как для эхофлудеров, а у меня написание такого кода, да еще один раз на все процессоры и проекты затруднений не вызывает.

Hормальная система команд, многие вещи получаются лаконичней чем с тем же avr. Впрчем, я крайне редко обращаюсь к системе команд так как пишу на С.

В этом мире самое разумное применять готовые системы с хорошей избыточностью на базе PC или другой и конечно же тоже писать только на ЯВУ и с использованием ОС.

Именно поэтому.

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

Я пока что вижу только нескончаемые потоки бреда в конференции.

Флудеров волнует только поднятый трафик.

Hет, не расскажем что именно делает программа.

Реализацией физики процесса занимается небесная канцелярия во главе с товарищем Господом Богом. А мы скромно занимаемся оптимизацией процессов, увеличивающей выход готовой продукции (балласт с лампой) на десятки процентов по сравнению с продукцией конкурентов, которой по ряду других параметров мы или проигрываем или не выигрываем.

С-компиляторы мы не делаем, мы их используем. И скорость нашей работы от этого возрастает многократно. Тем более, что в отличие от флудеров и теоретиков, каждый из нас имеет немалый опыт решения подобных задач на ассемблере, в том числе и макроассемблере. Кстати, и на Паскале под ДОС я так думаю, что в несколько раз больше вашего коллектива авторов мною написано. Я уже давал неоднократно ссылку на одну из публично доступных программ, сделанную мной с моим товарищем

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

Да уж, 78с05 в цепи питания PIC - это охрененное ноу-хау...

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

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

Пятница Март 18 2005 21:30, Alex Gavrikov wrote to Harry Zhurov:

AG> Ритоpический вопpос: почему более новые пpоцессоpы, сиpечь pожденные AG> недавно, считаются стаpшими? Казус.

Видимо работает такая логика - "младшие" давно появились и уже не меняются, а "старшие" всё это время продолжали расти, и только потом появились ;)

Старший - значит "более навороченый". И никакого казуса...

Георгий