Embedded OS

Hello, Alexander!

Пон Маp 21 2005, Alexander Torres писал к Maxim Polyanskiy по поводу "Embedded OS." >>> 35ватт - это мы еще в среде наколенщиков >>> с боша драли так сказать просто для пробы, пока прикидывали стоит >>> ли это делать - оно нафиг не рентабельно стало. AT> Учитывая, что Бош такого не делает, (и помоему никогда и не делал) - AT> твое утверждение несколько спорно :) Стыдно Саша. Первая автомобильная оптика на лампах D2S делелась имено бошем, и бош делал насколько мне извесно аж 4 модификации блоков. 2 из которых у меня в гараже дохлые валяются. Это уже потом пошли хеллы всякие и кореяки попсовые. AT> Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 WBR! Maxim Polyanskiy.

Привет George!

Monday March 21 2005 15:30, George Shepelev wrote to Kirill Frolov:

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

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

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

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

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

Hello, Dima!

Пон Маp 21 2005, Dima Orlov писал к Maxim Polyanskiy по поводу "Embedded OS." >> 3,5 квт - впечатляет, фотку бы выложили что-ли как хоть оно >> выглядит. Я наверно >> такое сделать не смогу. 35ватт - это мы еще в среде наколенщиков >> с боша драли так сказать просто для пробы, пока прикидывали стоит >> ли это делать - оно нафиг не рентабельно стало. DO> Подозреваю, что и 35ватт ты сделать не сможешь... Мы над этим проектом DO> долго работали. Да не проблема его сделать, совсем не проблема. Вернее скажем - не программная проблема. Занимались этим в году 99-м. Прошивку 68HC11 мы наглым образом с боша слили, раздизили и написали примерно то-же самое на pic. Там вобщем-то самое сложное было понять как работает мост на полевиках который напряжение разворачивает и как происходит регулировка мощности. А дальше начались банальные совкизмы - ферит хороший импортный денег стоит, полевики так вообще золотые получаются, в результате приходится ставить говно за счет увеличения размеров и числа витков... что-то намотать - чуть ли не дороже всего остального, потому как делается на каких-то невнятных заводах.., корпус герметичный алюминиевый - космические деньги, аж 10$... Hасверлить в нем дырок в нужном месте - еще $3. Вобщем себестоимость под 100$ а оно Корейское сейчас без проблем берется за $60, мало того - давно купленно и стоит в машине. А так все работает - лампочку зажигает. Кстати поджиг там не 4 киловольта был а помоему 20. От 4-х лампы с эрозией нефига не зажигаются. DO> С уважением, Дима Орлов. WBR! Maxim Polyanskiy.

MB>>>> Компенсиpовано. GS>>> Hе совсем. Для разных задач могут оказаться удобными разные GS>>> представления! KF>> Эффективен смешанный вариант. GS> Зачем? В огромной массе случаев удобен один из простейших вариантов.

Один из простейших видов сортировки -- сортировка пузырьком...

Затем, что это позволяет не перевычислять длину, когда это не нужно а с другой стороны, позволяет обрабатывать строку частично, не вычисляя длину подстроки. Думаю, тут ещё должны быть какие-либо хитрости вокруг UTF-8 (для посимвольной, а не побайтовой обработки).

KF>> И не спорь. Чисто паскалевский требует хранить длину в отдельном KF>> регистре GS> В "нулевом" элементе символьного массива, хранящего строку. Занимает GS> ровно GS> столько же места, сколько сишный "нуль-терминатор".

Hет. Одно слово -- типично 4 байта.

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

Hетрудно догадаться, что в функции вроде strtoul оно автомагически парсится.

KF>> что жутко неудобно. GS> Перевычислить одно значение всё таки гораздо проще, чем постоянно искать, GS> где кончается хвост ;)

strtok("У попа была собака...", " \t") -- перевычисляй для каждого кусочка.

KF>> Чисто сишный имеет трудности с определением длины когда это KF>> действительно нужно. GS> Чисто сишный имеет преимущество в возможности создания строк произвольной GS> длины,

"Дельфийный" тоже имеет такое преимущество (см. выше, про байт и слово).

GS> вариант". С длиной, хранящейся отдельно от самой строки, ибо в "сишной GS> строке" GS> для этого параметра места нету...

Ещё раз: в языке C строк нет, есть байтовый вектор. Принять как аксиому.

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

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

GS> Hу а трахаться с переконвертацией и последующей отладкой в режиме GS> паскаль-си GS> предоставляю мазохистам...

Это отлаживать, наверное, нужно уметь...

GS> P.S. Скунсам же советую читать H.Вирта. Там ответы на многие вопросы.

Долой авторитетов!

KF>> Эффективен смешанный вариант. И не спорь. Чисто паскалевский требует KF>> хранить длину в отдельном регистре и всё время её перевычислять, что KF>> жутко неудобно. Чисто сишный имеет трудности с определением длины когда KF>> это действительно нужно. ON> Для чисто паскалевских мгновенно срабатывают стандартные функции обработки ON> строк, поскольку им сразу понятно, что где лежит, и где заканчиватся. А в ON> сишной библитеке, каждая библиотечная функция обработки строк начинает ON> свою ON> работу с поиска концевых нулей.

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

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

Для большинства функций 0 -- сигнал к завершению разбора строки. Если функция в процессе работы до конца и не доходит, то она вычислением длины не занимается вообще. Из явно вычисляющих длину вспоминается только printf, strdup и strlen.

ON> Увы, очень даже применяют. Пример- сборка строки перед выводом на LCD. ON> Сборка ON> производится из "рассчитанной" строки в SRAM и темплейта(формата), что ON> хранится во Flash. Известно, что люди прямо в названии функции указывают ON> типы ON> памяти, с которыми будет иметь дело данная функция. Это много экономнее, ON> чем ON> битиками кодировать типы для одной универсальной и ужасно громоздкой ON> функции.

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

Сборками строк в микроконтроллере никто в трезвом уме заниматься не будет, за редкими исключениями. Ибо памяти мало. А printf, путём переопределения ряда функций (вроде посимвольного вывода) позволяет форматируемые данные непосредственно выдавать в поток.

Манипуляция битиками часто оказывается эффективной. За примерами можно ходить к keil software, там, я думаю, в компиляторах разбираются.

Пpивет, Michael!

GS>> А для AVR я могy и на ассемблеpе пpогpаммкy сделать (собственно, GS>> как pаз сейчас делаю), хоть это и не самое пpиятное занятие.

MB> Пожалей себя, бpось какy.

Для AVR писать на asm - сплошное удовольствие. По крайней мере до одного-двух килослов объектного кода.

с уважением Владислав

Пpивет, George.

Вот что George Shepelev wrote to Kirill Frolov:

GS> А для AVR я могy и на ассемблеpе пpогpаммкy сделать (собственно, GS> как pаз сейчас делаю), хоть это и не самое пpиятное занятие.

Пожалей себя, бpось какy.

Michael G. Belousoff

... ==== Пpоблемy надо pешать до того, как она появится. ====