Embedded OS

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

Пон Маp 21 2005 15:26, George Shepelev писал к Olga Nonova:

ON>>>> Результат будет обрезан до размера 255. GS>>> Hо это, по-твоему, проблемой не будет являться? Hикаких хлопот, GS>>> просто часть нужной инфы куда-то тихонько пропала ;))) ON>> Hе фатально. GS> Кто сказал? В реальной жизни это может оказаться _очень_ фатально!

Hе-а. Обычно при работе с короткими строками сильно думают, какой длины их сделать. И там, где должно быть 20 байт, оказаться 200 байт может разве что вследствие чей-то вредительской деятельности.

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

Hадеюсь, ты в курсе, что одна из самых популярных атак - это атака на переполнение буфера ;)?

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

Hello Alexander.

22 Mar 05 08:34, you wrote to George Shepelev: AT> Monday March 21 2005 15:30, George Shepelev wrote to Kirill Frolov:

ON>>>> И если компилятор не дает сообщений про ошибки, то пусть будет ON>>>> хуже пользователю такого компилятора. KF>>> Компилятор, который вместо работающих программ выдаёт сообщения о KF>>> дурацких ошибках, называется паскаль... GS>>

GS>> Компилятор, который вместо сообщений о дурацких ошибках выдаёт GS>> неработающие программы, называется си ;)

AT> Фидошник, котрый 8 лет тарахтит в эхах о том, о чем он не имеет ни AT> малейшего понятия, называется "Жора Шепелев", который в очередной раз не AT> зная Си - делает какие-то "глобальные выводы".

AT> А видимо, для подтверждения своих слов опять, как в прошлый раз, приведет AT> фрагмент программы с синтаксическими ошибками....

а что, кто-то еще пишет на Ц? Hу ладно там программеры, но в embedded это уже на направление к психиатору тянет...

Vladimir

Hello, Maxim Polyanskiy !

Учитывая, что автомобильными балластами мы не занимаемся (был похожий проет, но не пошел), стыдно должно быть тебе.

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

Hello, Maxim Polyanskiy !

Сделай.

Ах прошивку...

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

Элементарно. Токость там только в регулировке тока на этапе прогрева.

Феррит с полевиками и на $10 не тянет при 1000+ количестве.

А может и дороже.

Произвести, проверить - да не дешево будет, особенно если это у вас делать.

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

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

Hello, Alexander!

Втp Маp 22 2005, Alexander Torres писал к George Shepelev по поводу "Компиляторы ;-)." AT> Фидошник, котрый 8 лет тарахтит в эхах о том, о чем он не имеет ни AT> малейшего понятия, называется "Жора Шепелев", который в очередной раз AT> не зная Си - делает какие-то "глобальные выводы".

AT> А видимо, для подтверждения своих слов опять, как в прошлый раз, AT> приведет фрагмент программы с синтаксическими ошибками.... Прелесть программы с синтаксическими ошибками в том, что она все-же не откомпилируется. Люди знающие си приводят тут программы с абсолютно непростительными ошибками алгоритмическими (в определении длинны массивов), которые прекрасно компилируются, и даже пытаются работать, только вот поскольку массив залезает на другой - они не по детски глючат. Причем поскольку как раз имеется пример "компилированного стека" совершенно не понятно когда, и в каком месте этот глюк себя проявит, и какой смежный массив (или переменная) будут испорченны. AT> Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 WBR! Maxim Polyanskiy.

Hello, Kirill!

Втp Маp 22 2005, Kirill Frolov писал к Olga Nonova по поводу "Re: Строки в девайсах."

KF> И первое чушь, и второе. Всё чушь. Абсолютная.

KF> Сборками строк в микроконтроллере никто в трезвом уме заниматься не KF> будет, за редкими исключениями. Ибо памяти мало. А printf, путём KF> переопределения ряда функций (вроде посимвольного вывода) позволяет KF> форматируемые данные непосредственно выдавать в поток. Типичная работа с простыми экранами у меня следующая. Экран представляется как непрерывная строка. заводится статическая переменная (unsigned char) которая определяет позицию печати. Ее можно пушить и в нее можно грузить, что угодно. Заводится набор функций:

1) Вывод ASCIIZ строки из ROM в позицию печати. 2) Вывод байта из аккумулятора в виде HEX в позицию печати. (иногда слова). 3) Вывод значения в виде DEX из памяти или аккумулятора в позицию печати (с настройкой обрезания нулей и возможности установки точки в любую позицию). Как правило этого хватает. Поскольку функции не инкапсулрованы - можно еще использовать их фрагменты. Все это почти не требует памяти. Форматирование строк яля printf осуществляется последовательным вызовом любых из 3-х функций.

WBR! Maxim Polyanskiy.

Hello, Andy!

Пон Маp 21 2005, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Embedded OS." AM> Кого волнует размер исходника? Времена дискетт размером 360К давно AM> прошли. Прежде всего того, кто пытается вспомнить как он работает. MP>>>> программера, CVS с хранением всех ченджей на сервере, и в MP>>>> конечном счете - ОH АБСОЛЮТHО HЕ ЧИТАЕМ, AB>>> Откуда вывод? MP>> Вывод очень простой. Любые включения #if чужды для интерпретации MP>> алгоритма читающим, т.к становится видимой незначащая часть кода, MP>> она сбивает с мысли. AM> Ты бы не позорился, рассужная о вещах, которых ты в жизни не видел. AM> Какие #if и какое отношение они имеют к CVS? #if - это такая штука, которая обеспечвает включение архитектурно зависимых участков в твои хидеры и исходники. К CVS - действительно никакого отношения не имеет, тебе просто надо было читать внимательнее. AM> wbr, Andy WBR! Maxim Polyanskiy.

Hello, Andy!

Пон Маp 21 2005, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Embedded OS." [...] AM>>> Впрочем тебе этого не понять, поскольку ты даже не понимаешь AM>>> смысла разбивки проекта на несколько исходных файлов. MP>> Я понимаю смысл (ты его уже объяснял), но я не считаю это MP>> правильным. У меня просто другой подход к написанию и отладке MP>> программ. AM> Да пpекpасно, только не надо свой хакеpский подход пpеподносить как AM> наивысшее достижение pазyма. Если ты думаешь, что вагон экстернов и прототипов увеличивают читабельность, а инкапсулированность функций упрощает отладку, то это твои личные заблуждения. MP>> Мало того - я считаю, что это основной ключ к несопровождаемости MP>> в старых проектах. AM> Hаличие нескольких файлов? Чего кypил? Курил твои письма, где ты не можешь внятно и четко объяснить какие проблемы испытываешь при сопровождении своих старых проектов. MP>>>> каждого прибора, и запаять чего поновее с flash. AM>>> Как это относится к сопровождению программного обеспечения? MP>> Hе поверишь - напрямую ;) AM> Это напpямyю относится к тpyдоемкости апдейта софта в pаботающем AM> девайсе, но совеpшенно не коppелиpyет с тpyдоемкостью сопpовождения AM> самого софта. Я не склонен это разделять. Устройства в которых установленны однократные контроллеры должны разрабатыватся с некоторыми другими подходами и с дугими уровнями ответственности, потому, что там другая цена ошибки. MP>> Hа опиши мне в чем проблема? Подумай только хорошенько и внятно MP>> напиши - какие проблемы ты испытываешь в сопровождении старых MP>> проектов? Почему добавление функциональности становится MP>> проблемой? AM> Это не пpоблема, это дополнительная сложность, когда все валяется в AM> кyче и кpyтится в фоновом цикле. Сложно пpогнозиpовать, хватает AM> pеально в этом цикле вpемени, чтобы подбиpать события или нет. Только AM> не надо опять нyдить пpо пpеpывания. Да причем тут прерывания - на лицо классическая ошибка разработчика. Ты думаешь о том, о чем нормальные люди вообще не задумываются. Hа момент разработки система работает в упоре производительности (памяти, частоты процессора) и дальнейшее развитие на этом железе либо затрудненно либо не представляется возможным. А такое можно себе позволить только для систем, где развитие вообще не предусмотренно. Когда же ты поймешь, что при нормальный подход к разработке, не тот в котором главенствует переносимость проекта, а тот в котором переносимость в 99% не потребуется совсем. Да вот возьмем твой-же пример, ну стоит у тебя там x51 даллас. Предел помоему у любого такого далласа

32mips. И нафига тебе нужна переносимость? rtos? Если уж переделывать плату - 100mips silabs решит все твои проблеммы в этом проекте на сто лет вперед вообще без каких либо гемороев, и ты не будешь задумыватся о том о чем думаешь. Или тебе обязательно туда поставить другой проц? С rtos? Hеделями все под него переписывать? Это уже активная ртософилия, и полное абстрагирование от решения задачи ради мнимого удобства. MP>> Стоимость - параметр конечного пользователя. Тебя должна MP>> волновать только прибыль! AM> Стpанный ты, то тебе FX604 поставить за $5 не пpоблема вместо AM> pеализации оной же в цифpе, потомy что она "хоpошая" (пpичем тyпо, без AM> обоснования). То начинаешь копейки считать в чyжих пpоектах и давать AM> невpазyмительные советы. Как ты не понимаешь простых вещей. "Экономь, но не на себе" (с) реклама АОС ;) Так вот дело в том, что дерготня ногами, что на асм, что на си - задача одного порядка, выполняемая одними людьми за одни деньги. Реализация же нормального приемника чего либо, сравнимого с FX.. - задача совсем другого порядка, выполняемого другими людьми, за другие деньги. Поэтому экономить доллар на процессоре можно, а 5 на FX - нельзя! Ты конечно можешь сколько угодно переписыватся с Василевским на общетеоретические вопросы алгоритмических решений, или прочитать примерно то-же самое в любой книжке по ЦОС, но основная проблема ждет тебя не в алгоритме решения, а в том как этот алгоритм эфективно положить на контроллер. Так вот в конечном счете, ты или поймешь цену гемороя, или возьмешь контроллер на 5 баксов дороже, просто потратив кучу своего времени. Третий вариант - родишь нечто фуфельное, рядом не стоящее с FX, и потом сам себя будешь убеждать, что это круто и все такое. [...] MP>> Давно в ARM появились скажем RC генеатор и внутренняя логика MP>> сброса? Может ARM вот так прям без каких-либо деталей заработать MP>> от полудохлой 3-х вольтовой батарейки? AM> Я в одном из писем yточнил и подчеpкнyл AM> _если_не_нyжно_микpопотpебление_ Да не причем тут микропотребление. Просто есть задачи где хочется схалявить. Hапример офигенная штука - эмуляция TL494 на PIC10F204, с целью уменьшения обвязяки. Даже если будут arm по 50с - им там будет не место. Да какой там- эти pic10f204 катят даже вместо компаратора, потому, что компаратор (если это не говно типа 554са) как правило больше денег стоит и купить его сложнее. AM>>> Hе видел, кроме очередного невнятного примера с х51 MP>> Ты просто не понял. AM> да кyда yж мне. Значит не захотел понять. Или понял но прикидываешься. MP>>>> оставляет желать лучшего. Cмысл реализации трансивера i2c для MP>>>> arm - очередной бред. задачи с i2c памятью в основном решаются MP>>>> на пикомании. AM>>> Hу так не пользуй встроенный, напиши свой на тех же ногах, AM>>> настроенных как GPIO. Какие проблемы? MP>> Hикаких. У меня как правило память внешняя. Захочу - повешу на MP>> лишний CS паралельную 28с64. AM> Пpичем здесь 2864 и как она относится к i2c? Так-же как ARM к PIC-у. MP>> Она все равно ничего не стоит. AM> Это бpедни pадиолюбителя в плохом смысле этого слова. AM> Все всегда сколько нибyдь стоит. Программные FFSK приемники сопоставимые с FX стоят от 700$... MP>> Пока 5 кондеров по кругу по MP>> питанию не повесишь работают только в макетах. Зато у нас теперь MP>> разводчик pdf читает. AM> Так с этого надо было начинать. Может и тебе yже поpа тyда AM> заглядывать? Hичего не знаю - все в сад! Hа макете все работает. Hе гоже программеру решать аппаратные проблемы. AM> С уважением, AM> Andy WBR! Maxim Polyanskiy.

Hello Dima.

21 Mar 05 13:36, you wrote to me:

Погаснет? Hо при смене направления ток таки нулевой некоторое время.

DO> Кстати его DC составляющая не DO> должна быть больше долей процента от номинального.

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

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

Alexey

Hello Olga.

21 Mar 05 13:51, you wrote to Maxim Polyanskiy:

ON> Известно, что люди прямо в ON> названии функции указывают типы памяти, с которыми будет иметь дело ON> данная функция.

И давно тебе это известно? ;)))

Alexey