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

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

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

после изучения Ц скорее всего придет понимание, что асм-вставки не нужны в таких количествах, как виделось изначально.
Далее изучаем RTOS (для AVR есть scmRTOS, автор из новосиба, здесь он тоже есть), попутно изучаем Ц++.
Ну и драйвера пишем при необходимости, с возможностью повторного использования кода), осваиваем системы контроля версий типа CVS и подобных, чтобы легче было сопровождать проекты, и понеслась душа в рай

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

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


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

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

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


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

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

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

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

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

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

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

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

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

Как вариант можешь глянуть на Форт (Forth ) не фортран.
Основная ссылка forth.org.ru или посмотри мои топики по нему для начала.

В том-то и вопрос - для чего именно нужна программа? Одно дело, если устройство мелкосерийное или даже единичное. Тут зарплата программиста имеет большой вес. Тут контроллер можно и помощнее (и стало быть, подороже) взять. Тогда из программы не нужно будет выжимать ни байтов, ни микросекунд. Зато изделие будет разработано и выпущено в кратчайшие сроки.
Другое дело, если устройство идет массовым тиражом. Тогда зарплата программиста уже не имеет решающего значения. Больший вес будут иметь аппаратурные затраты. Тогда контроллер придется взять подешевле и, стало быть, попроще. Тогда с программкой придется повозиться, и выжать из все, что только можно. Может быть, в данном случае, и микроконтроллер будет взят ранее незнакомый. Тогда придется и его освоить. А это тоже время и, соответственно, деньги. Но эти затраты все равно окупятся за счет массового производства.
Какой инструмент в каждом случае использовать определяет программист. Самый лучший инструмент тот, которым программист владеет в наибольшей степени. Плохую, нечитаемую, трудно модифицируемую, быстро забываемую программу можно с одинаковым успехом написать как на Си, так и на ассемблере. Было бы желание, точнее, нежелание писать хорошо.

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

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

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

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

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

А разве желая второе мы предполагаем не первое? Продукт требуемого качества за требуемое время.


А я это не про Bас а про всем известную столетнюю войну.



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

Вот одна маленькая книжка по сабжу - мне она в одно время показалась интересной но возможно я и ошибаюсь .
http://rapidshare.de/files/20392771/How_th...ftware.rar.html

Спасибо за ссылку.

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

вплотную столкнулся однажды с тем, что написав программу на Си, мог обрабатывать два канала (4 простых цифровых фильтра на каждом одновременно), а переписав обработчики прерываний на ассемблере, смог обрабатывать одновременно уже 4 канала !

Если знать особенности генерации кода компилятором и не делать сущностей сверх необходимых, то код на С мало уступает ассемблеру.
Накладные расходы ведь следствие лишних вызовов функций, запихивания в стек лишних переменных, сохранения неактуального контекста.

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

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

Тема данного топика интересна и возможно есть хорошее обсуждение в других топиках.

Не затевая "религиозных войн" Сформулирую свои критерии быстрой разработки софта

1. Интерактивная среда работы с отлаживаемым железом с минимальным откликом по
проверке работоспособности кода или его части.

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

3. Знание и использование "минимально" необходимого базиса работы с контроллером,
с "продвинутым" инструментарием.

4. Иметь возможность вместе с "эволюционированием" понимания предметной области
и способов решения задач в ней подстраивать используемый инструментарий разработки.

....

В моём случае выбран для использования Форт (Forth) язык, как наиболее адекватный
перчисленным требованиям.

P.S. Появился ещё один вариант Форта для AVR на базе Форта SPF4 пригодный для использования
как в Linux так и Windows и автор планирует его дальше развивать.
Ссылка http://www.fforum.winglion.ru/viewtopic.ph...;p=33581#p33581
Ссылки на другие Форт системы можно найти на данном форуме в разделе про микроконтроллеры.

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

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

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

Отсюда:
http://betterembsw.blogspot.com/2011/05/es...e-handouts.html



С форума avrfreaks.net:

даже и не знаю, что можно возразить... с одной стороны, сколько себя помню, всегда шла речь об интенсивном использовании имеющихся ресурсов, т.е. максимального извлечения из них всего, что можно, а не экстенсивным, т.е. просто увеличением объема слабовыжатых ресурсов. это было всегда: от посевных площадей (всегда считали центнеры с га) до нефти и газа (в пользу идет все - от мазута до легчайшего CH4). с другой стороны, практика последних лет убеждает, что на самом деле все наоборот: вместо того, чтобы сделать что-то (с усилиями) на меньшем, правильнее сделать то же самое на бОльшем (но без усилий). правда, этот экстенсивный путь в основном прижился в электронике, благодаря чему последние годы производители просто из кожи вон лезут для того, чтобы хоть чем-то "нагрузить" разросшиеся непомерно возможности, например, возьмите ОС: 90% возможностей остались на уровне 20-летней давности, но их реализация обвешана 32-битной 3D-графикой... оборочки стали весить больше платья...

извините за оффтоп - наболело...

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

Да, проблема бывает.
Какая периферия вам нужна? Какой AVR вы применяли/применяете, который имеет эту периферию?
Смотрели семейство контроллеров Gecko фирмы EnergyMicro? А ATxmega?

И это перед кем же такие задачи ставятся?
Не помню ни одного заказчика (мы здесь говорим об электронике), которому было бы не по барабану какие "ресурсы" имеет то или иное инженерское решение поставленной задачи. Это разработчики обычно изголяются по бедности, чтобы из минимума выжать максимум в надежде максимально сэкономить на комплектующих. Сейчас уже другие времена и 80% запас ресурсов никого не волнует. Сейчас основной параметр эффективности - это не мегагерцы, не мегабайты и не количество лишних ножек, это time to market, что бы там не говорили апологеты ассемблерных вставок.