[Yura_K 0]

Возник вопрос, при помощи чего можно ускорить разработку программ. Представляется несколько вариантов. Во-первых, использование высокоуровневого языка - C. Но у компиляторов не слишком мощная оптимизация и все равно приходится использовать asm-е вставки. Во-вторых, использование библиотек готовых функций (возможна и для asm-а, и для C). В-третьих, возникли мысли о некой прослойке (интерфейсе) между функц. узлами uC и программой, так чтобы написание как повторяющегося кода, так и нового свести к возможному минимуму. Также возможно использование некой RTOS. Ваши мысли по сабжу?

[haker_fox 60]

Возник вопрос, при помощи чего можно ускорить разработку программ. Представляется несколько вариантов. Во-первых, использование высокоуровневого языка - C. Но у компиляторов не слишком мощная оптимизация и все равно приходится использовать asm-е вставки. Во-вторых, использование библиотек готовых функций (возможна и для asm-а, и для C). В-третьих, возникли мысли о некой прослойке (интерфейсе) между функц. узлами uC и программой, так чтобы написание как повторяющегося кода, так и нового свести к возможному минимуму. Также возможно использование некой RTOS. Ваши мысли по сабжу?

 

Гм... подавляющее большинство людей (ИМХО) использует Си-компиляторы (IAR, GCC). На счет "мощной" оптимизации... даже трудно понять, что под этим подразумевается... Современные компиляторы и так достаточно не плохо оптимизируют код. Есть конечно "глюки", но как без них ;) А вставки на ASM'е, если они так нужны, нужно просто вставлять и все. Но помнить, что они снижают портируемость кода на другие платформы.

[Andy_Mozzhevilov 0]

Возник вопрос, при помощи чего можно ускорить разработку программ. Представляется несколько вариантов. Во-первых, использование высокоуровневого языка - C. Но у компиляторов не слишком мощная оптимизация и все равно приходится использовать asm-е вставки. Во-вторых, использование библиотек готовых функций (возможна и для asm-а, и для C). В-третьих, возникли мысли о некой прослойке (интерфейсе) между функц. узлами uC и программой, так чтобы написание как повторяющегося кода, так и нового свести к возможному минимуму. Также возможно использование некой RTOS. Ваши мысли по сабжу?

 

Изучаем в порядке приоритетов:

Ц

RTOS

 

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

Далее изучаем RTOS (для AVR есть scmRTOS, автор из новосиба, здесь он тоже есть), попутно изучаем Ц++.

Ну и драйвера пишем при необходимости, с возможностью повторного использования кода), осваиваем системы контроля версий типа CVS и подобных, чтобы легче было сопровождать проекты, и понеслась душа в рай :)

[Bill 0]

Но у компиляторов не слишком мощная оптимизация и все равно приходится использовать asm-е вставки. Во-вторых, использование библиотек готовых функций (возможна и для asm-а, и для C). В-третьих, возникли мысли о некой прослойке (интерфейсе) между функц. узлами uC и программой, так чтобы написание как повторяющегося кода, так и нового свести к возможному минимуму. Также возможно использование некой RTOS. Ваши мысли по сабжу?

Насчет возможностей оптимизации в компиляторах, я думаю, Вы несколько заблуждаетесь. Ручная оптимизация кода, сгенерированного компилятором, позволит сократить программу примерно на 10%, не более. Все зависит от того, как именно написана программа. Использование ассемблерных вставок практического эффекта не дает, поскольку эти вставки ограничивают возможности компилятора оптимизировать программу. Если все же требуется "выжать" из программы десяток байт или пяток микросекунд, то тогда лучше написать соответствующую функцию целиком на ассемблере и выделить ее в отдельный модуль.

Насчет библиотек функций Вы правильно заметили. Именно использование библиотечных функций и дает возможность ускорить разработку программы. Возможно странслировать интерфейсные функции и также поместить их в библиотеку. Кстати, здесь возможности ассемблера (+ линкера) гораздо шире, чем у компилятора. Ассемблер позволяет определять глобальные символы на уровне порта или даже бита, без необходимости использования заголовочных файлов. Странслировав такой модуль один раз и поместив его в библиотеку, далее можно просто про него забыть. Единственно, что нужно будет потом сделать, это присвоить портам или битам конкретные значения, которые могут изменяться от проекта к проекту.

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

[Yura_K 0]

"выжать" из программы десяток байт или пяток микросекунд

Именно так иногда и приходится делать :)

Использование библиотечных функций

Использование RTOS

Так вот на чем остановиться (в смысле библиотеки или RTOS). Просто для меня собственно это уже не очень важно. Средние по сложности программы (до 4 кБ) я могу и на asm-е делать, если побольше то конечно на C. Но вот из-за большой текучести кадров появляются люди у которых опыта работы с uC почти нет (только закончили ВУЗ), а включаться в работу надо сразу.

[eci 0]

"выжать" из программы десяток байт или пяток микросекунд

Именно так иногда и приходится делать :)

Использование библиотечных функций

Использование RTOS

Так вот на чем остановиться (в смысле библиотеки или RTOS). Просто для меня собственно это уже не очень важно. Средние по сложности программы (до 4 кБ) я могу и на asm-е делать, если побольше то конечно на C. Но вот из-за большой текучести кадров появляются люди у которых опыта работы с uC почти нет (только закончили ВУЗ), а включаться в работу надо сразу.

Посмотри http://algrom.net/russian.html. Очень удобная среда разработки и при всем прочем это assm в чистом виде. Не надо ни каких оптимизаций.

Изменено 11 мая, 2006 пользователем eci

[haker_fox 60]

"выжать" из программы десяток байт или пяток микросекунд

Именно так иногда и приходится делать :)

Использование библиотечных функций

Использование RTOS

Так вот на чем остановиться (в смысле библиотеки или RTOS). Просто для меня собственно это уже не очень важно. Средние по сложности программы (до 4 кБ) я могу и на asm-е делать, если побольше то конечно на C. Но вот из-за большой текучести кадров появляются люди у которых опыта работы с uC почти нет (только закончили ВУЗ), а включаться в работу надо сразу.

Посмотри http://algrom.net/russian.html. Очень удобная среда разработки и при всем прочем это assm в чистом виде.

На счет этого инструмента много чего хорошего сказано здесь

 

Не надо ни каких оптимизаций.

Как это не надо? Если пишешь на чистом ассемблере, это еще не значит, что код оптимальный.

[*SERG 0]

Вообще не понимаю..........не оптимальный код.......не оптимальный код..........

Найдут несколько абсурдных строчек в -надцати Кбайтном коде написанном на Си и всё...............код у них не оптимальный....

Даг возьми и напиши ПОЛНОСТЬЮ (большую) одну и ту же задачу на асме, а потом её же на Си и там уже посмотрим у кого оптимальней получиться:)

Ну а если скорость нужна то пользуйся асм вставками

 

О, привет ЗЕМЛЯКАМ :)

[haker_fox 60]

Вообще не понимаю..........не оптимальный код.......не оптимальный код..........

Найдут несколько абсурдных строчек в -надцати Кбайтном коде написанном на Си и всё...............код у них не оптимальный....

Даг возьми и напиши ПОЛНОСТЬЮ (большую) одну и ту же задачу на асме, а потом её же на Си и там уже посмотрим у кого оптимальней получиться:)

Ну а если скорость нужна то пользуйся асм вставками

 

О, привет ЗЕМЛЯКАМ :)

 

Подобную мысль уже сказал уважаемый _Bill.

 

Мне кажется, кто говорит о слабой оптимизации компиляторов с Си - тот просто не использовал их. И не сравнивал листинги, сгенерированные компиляторами, с ручным кодированием.

[sK0T 0]

Мне кажется, кто говорит о слабой оптимизации компиляторов с Си - тот просто не использовал их. И не сравнивал листинги, сгенерированные компиляторами, с ручным кодированием.

 

Оптимальный код, не оптимальный код…

 

Надо просто посчитать — что дешевле: время программиста или неоптимальность кода да и всё. Или может быть вообще отказаться от микроконтроллеров и сделать на рассыпной логике или ПЛИС, раз микросекунды выжимать надо?

 

Оптимизация никогда не бывает просто так. Если один программист на асме напишет «оптимальный» код за два месяца, а другой на Си за неделю, но при компиляции он будет «не оптимальный», то второй код ЛУЧШЕ. Так как программист получил зарплату в четверть месяца за него, а не за два.

 

Плюс такое ещё соображение. Неоднакратно наблюдал, как программеры (под PIC) на асме через полтора года не могли разобраться в своём исходнике. Программы на Си всё-таки поддерживать легче (писать одинакого, что на асм, что на Си).

[Kopa 0]

Возник вопрос, при помощи чего можно ускорить разработку программ. Представляется несколько вариантов. Во-первых, использование высокоуровневого языка - C. Но у компиляторов не слишком мощная оптимизация и все равно приходится использовать asm-е вставки. Во-вторых, использование библиотек готовых функций (возможна и для asm-а, и для C). В-третьих, возникли мысли о некой прослойке (интерфейсе) между функц. узлами uC и программой, так чтобы написание как повторяющегося кода, так и нового свести к возможному минимуму. Также возможно использование некой RTOS. Ваши мысли по сабжу?

Как вариант можешь глянуть на Форт (Forth ) не фортран.

Основная ссылка forth.org.ru или посмотри мои топики по нему для начала.

[Bill 0]

Оптимальный код, не оптимальный код…

 

Надо просто посчитать — что дешевле: время программиста или неоптимальность кода да и всё. Или может быть вообще отказаться от микроконтроллеров и сделать на рассыпной логике или ПЛИС, раз микросекунды выжимать надо?

 

Оптимизация никогда не бывает просто так. Если один программист на асме напишет «оптимальный» код за два месяца, а другой на Си за неделю, но при компиляции он будет «не оптимальный», то второй код ЛУЧШЕ. Так как программист получил зарплату в четверть месяца за него, а не за два.

 

Плюс такое ещё соображение. Неоднакратно наблюдал, как программеры (под PIC) на асме через полтора года не могли разобраться в своём исходнике. Программы на Си всё-таки поддерживать легче (писать одинакого, что на асм, что на Си).

В том-то и вопрос - для чего именно нужна программа? Одно дело, если устройство мелкосерийное или даже единичное. Тут зарплата программиста имеет большой вес. Тут контроллер можно и помощнее (и стало быть, подороже) взять. Тогда из программы не нужно будет выжимать ни байтов, ни микросекунд. Зато изделие будет разработано и выпущено в кратчайшие сроки.

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

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

[Yura_K 0]

2*SERG Привет взаимно!

В принципе я согласен по поводу удобства языка C с точки зрения последующей сопровождаемости программ. Просто в асме я контролирую каждую стрчку кода, а в C это делает компилятор. Комплекс у меня перед "компутерным интеллектом" :) (то же по поводу "Algorithm Builder").

А что вы думаете по поводу реализации частей операционки. Скажем, только системы ввода/вывода, без планировщика и т.д.

Изменено 11 мая, 2006 пользователем Yura_K

[_artem_ 0]

ИМХО, в больших (начиная с нескольких десятков КБ) сложных программах быстрота дизайна в той же мере если не больше зависит от правильно спроектированной архитектуры будушей программы как и от применяемого средства программирования . Будет ли это псевдокод или графическое описание системы подсистемы и ее отдельных блоков - сделанное правильно , очень облегчит перенос лигики в код.

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

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

Использование rtos зависит от функции - есть много задач где она просто необходима а есть и те где от нее никакого толка.

Думаю что все зависит от требований на конкретный проект - инженер должен владеь этими тулами (ассемблер

с с++ rtos билиотеки ....) чтобы мог потом выбрать самый оптимальный подход к решению задачи, а наличие религиозный войн на поприше человеческих привычек свидетельствует об обратном положении дел у некоторых представителей данной профессии.

[Yura_K 0]

интуитивное написание программы , убыстрение процесса которого озадачило автора этой темы на ее создание

Нет, не убыстрение интуитивного создания программы, а убыстрение процесса обучения написанию программ.

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

Я конечно изивиняюсь, но никаких религиозных войн, тем более на поприще человеческих привычек я вести не собираюсь. Вообще-то целью было выяснить, что какой инструмент удобнее для человека только начавшего писать программы под AVR + ускорение процесса обучения. Могу сделать следующий вывод по приведенным постам: быстрее всего начать на С.

все зависит от требований на конкретный проект - инженер должен владеть этими тулами

Это не поддается сомнению! Если Вы думаете, что делая упор на asm я понятия не имею о С и т.д., то зря...