Быстрая разработка программ для AVR Опции

[Yura_K]

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

[_Bill]

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

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

[maksimp]

Если все же требуется "выжать" из программы десяток байт или пяток микросекунд, то тогда лучше написать соответствующую функцию целиком на ассемблере

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

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

For typical embedded
hardware/software costs:
* If production run is less than 1 MILLION units Resources should be no more than 80% full
* If production run is less than 10K units Resources should be no more than 50% full

Zero Is The Right Amount of Assembly Code

С форума avrfreaks.net:

The issue is when you start bumping up against ANY chip limitation (memory, speed, # I/Os, timers, etc). It gets more expensive to work to fit an application into the resources as you spend more time designing and coding against the limitations, as opposed to designing and coding against the requirements.

[ARV]

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

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

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

[IgorKossak]

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

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