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


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



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

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

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

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

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

Сообщение отредактировал skopus - May 17 2006, 10:55

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

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

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

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

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

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 - более бесполезного набора онборд-железа еще поискать надо.

Сообщение отредактировал _Pasha - Jan 25 2012, 07:54

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

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