Решил посмотреть CW.
Возник вопрос. засунуть функцию в рам получается - достаточно объявить ее с атрибутом секции .fast, но из нее вызываются библиотечные вызовы и весь шик пропадает. Можно ли еще линкеру сказать и библовые функции готовит в рам.

И че? никто не знает как? или никто не знает что так нельзя сделат?
в кросворке как это сделать я придумал, придумал как ручками наприкрутить к .fast

И?
GCC статическая либа - есть набор объектников. В каждом объектнике описано какоето количество секций, с их именами и данными....
Имена секций в либе видимо не поменять.... Код либ в сегменте типа ".text"...

И каков Ваш метод? Исправить линкерный скрипт так что .text будет по сути как .fast, а свои исходника компилять в какойнить .my_text?

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

А из чего в кроссворксе пересобираются либы? Где исходники-то?

[offtopic]

китаец?
[/offtopic]

я libgcc и libm пересобирал, в которых определены элементарные операции (меня интеремовали операции +-/* для флоатов ) и мат функции из libm, после этого можно с посощю ar вкрутить свой собранный код к кросворковскую либу, либо линкеру сказать линковать свои объектники раньше кросворковских - в ld линкует переднюю встреченную версию функции из либов не ругаясь на то что их может быть много в разных либах с которыми линкуется elf.
Таким образом я запустил все медленные функции из флэша, а все что в рабочих циклах (вычисления прилагухи на флоатах), прерывания из озу.
Да тут вариантов мульон! поразному можно сделать. Главно а) научится работать с атрибутами функций и данных в GCC, б) научится работать с ar при cборке либ в) научится работать с ld при сборке сделанного в предыдущих пунктах + разобратся с написание скриптов линкера (я к своему стыду только недавно с этим разобрался практически, раньше както все знал как работает но не возникала необходимость "тюнинга", под AVR вообще не разу в скрипт не заглядывал... )

Я из IARа в CW перхожу... Считаю удобнее среду. Столкнулся с дефицитом документации по нему. Опытные товарищи щеголяют атрибутами в стиле а-ля Java.
Никто не даст ссылочку на доку для всех этих нюансов? Примеры... Настройки
Буду благодарен за любую информацию!
Спасибо!

И всётаки прерывания IRQ в Crossworcs отрабатываются неправильно. Даже с заплаткой klena.
Беру LPC2106, разрешаю прерывания от UART0, UART1, TIMER0. Правильно отрабатывает только TIMER0(с заплаткой klena). Без заплатки вообще прерываний нет. Использовал Crossworcs 1.4, 1.6, 1.7.
Компиляция этого же проекта в ICCV7ARM(Imagecraft) и KEIL приводит к правильному результату.

Кстати. Кто-нибудь проверял в Crossworcs опцию
#pragma pack(1)
для выравнивания структур на границу байта?

1. Стоп!!! приводим С-код, ассемблерный выход компиллера этого кода (тоесть код обработчиков прерываний которые у вас не работают), версию компиллера. Далее смотрим и возможно изумляемся. У меня все работает, наверно и у Вас должно заработать.

2. Делаю так для выравнивания на 1 байт:

Насчёт выравниваний могу посоветовать:
typedef struct {
int var1;
int var2;
short var3 __attribute__ ((packed));
short var4 __attribute__ ((packed));
char var5;
}my_type;

my_type myVar;
Если хочется быстрой работы программы и малого размера кода - писать (__attribute__ ((packed))) для всей структуры не надо! Так как при этом она кладётся без выравнивания и загрузка 2 и 4 байтных переменных происходит побайтно.
Я лично выравнивание в структурах контролирую сам. Атрибут packed пишу только напротив short. Такой код правильно компилируется (int грузится ldr, short - ldrh, char - ldrb) и нормально стыкуется с ассемблерными функциями.
Ну а если ресурсы МК безграничны в рамках данного приложения, то пишем либо packed для всей структуры (тогда она кладётся без выравнивания), либо не пишем пакет вовсе (тогда char и short имеют размер 4 байта)
Напротив char писать packed - не надо! (По крайней мере в последних CrossWorks (1.6).

Кстати у меня имеется корыстный вопросик. Лекарство для CrossWorks 1.7 не подкинете?!?