В архив положил gcc-4.1.2 от 20060811 binutils-2.17 и newlibc-1.14.0
Также выложил его обрезанную версию до пакета для обновления gcc для CrossWorks. Просто преписать в дерикторию ..\gcc.
Попробывал на LPC2103, работает, контроллер не жалуется. Визуально без приборов обнаружил что под кросс-ворком 4.1.2 работает бысрее (компилирует) раза в полтора, но это не важное.

Кто работает с GNU tools chain или хочет поэксперемтировать заходите берите.
http://www.klen.org/Projects/Embeded-gnu-t...last_build.html

newlibc весьма печальный вариант для cpu с малым обьемом ОЗУ (чего только стоят ctype/printf/scanf реализации). как бы dietlibc заточить под это дело - может кто патчи встречал ? Сам пока временно натырил файлов оттуда - похоже что diet в основном заточен под x86, остальные платформы в альфа стадии ;(

А это чего? Я и не слыхивал о dietlibc.Только не понятно почему Newlib печальный, ну тогда они все что расписаны на C есть печальные. Для AVR avr-libc написана 80% на асме и чесно говоря во многих местах имеет ограничения.
Если есть исходники на С, могу поробывать собрать под ARM. Там много придется перепиливать?

Три года активно занимаюсь разработкой устройств на микроконтроллерах но ни разу printf и рядом функции которые не использовал. Один раз в начале попробывал .... понял что это гранаты не нашей системы .
Так что в моей канторе разработчики printf/.... и не разу не использовали . Наверно специфика наших задач .

Кстате недавече как месяц назад взял обучательную LPC-H2103 от Olimex, решелил так сказать на армы пересесть, так вот пробывал c printf, ничего страшного, в 32к флеша и 8к рамы влез FreeRTOS, целевой код, и printf и scanf которые на UART работали. Меня все устраивало кроме скорости реакции системки, поэтому было сделано как обычно- сам принимаешь сам обрабатываешь...без чужих функций. Такчто наверно printf можно без печали использовать даже на маленьких армах, но только если скорость не нужна, например на LCD выводить или еще какое управление медленным устройством.

Сообщение отредактировал klen - Aug 22 2006, 04:38

ну не факт.. даже для систем с EmbeddedLinux на борту (а это от 8МБ ОЗУ и выше) часто юзают ulibc заместо стандартной либо

2_Harbour

Собрал по быстрому dietlibc, в архив вошло:
1. dietlibc.a - собственно че Вам и требутся
2. libcompat.a
3. liblatin1.a
4. libm (вот это уже интересно для меня, приеду домой сравню с fp модулем newlibc по скорости)
5. start.o dyn_start.o dyn_stop.o (наверно они нах ненужны но всетаки пусть будут)

librpc libpthread libcrypt - я исключил, их без рукоприкладства сходу собрать не получилось.
заголовки у вас есть - вы качали библу.
Попробуте, отпишите че получилось. Самому интересно.

Задачи задачам - рознь, все на асме влом писать, к тому же если есть из чего выбрать сишного. newlib/uclibc проигрывают dietlibc раза в 3-4 по обьему кода.
dietlibc я тоже собирал, правда пришлось патчить librpc - задача не в том чтобы собрать, а в том чтобы иметь arm/interwork комплект библиотек, грамотно прикрученных к gcc, как это сделано с newlib.

Нет проблем. могем сделать и arm/interwork, тоесть две версии библы. Тока зачем Вам rpc?

В gcc/binutils есть понятие multilib - в зависимости от разных параметров применения одних и тех же функций (например hard-float/soft-float, arm/thumb/interwork и т.д.) gcc создает несколько версий библиотек. При компиляции проекта компилятор видя _как_ применяется f()-ия генерит обьектник из соответствующего набора. Речь шла именно об этом.

Спасибо конечно, но я знаком с этими явлениями поскольку сталкиваюсь с ними в повседневнойжизны .
Я ж говорил что собрал по бырому только под ARMv4T(ARM7TDMS-I) + ARM mode. исключительно чтоб попробывать. Чесно говоря пока не использую THUMB, у меня всегда борьба за наносекунды а в такого чтоб в флеш не влезло пока еще не разу небыло, до 40% процентов на асме прописываю. Сначала gcc генерит из C, потом я дооптимизирую выбранную трассу, напрмер код функый которые в цикле вызываются.
От libc мне интересен только libm, больше я ни чем как правило не пользуюсь

Ну так я не понял, Вам нужена dietlib собранная по полной или нет? Я так понял Вы и сами ее частично ухе собрали.

а разве выполнение thumb кода медленнее чем arm-one ? у меня все в thumb'e за исключением определенных хендлеров - проблем с наносекундами нема. А dietlibc я и так юзаю - в ручном режиме.

Я не мерял, но в документации написано что на 10-30 процентов медленне, и на столькоже компактнее. Я поверил. Иначе зачем они существуют раздельно? Дело в том что мои задачки обычно маленькие и проблнм с всовыванием не бывает бывает

Декодирование наборов инструкций занимает одно и тоже время, при грамотном буфере к флеши прирост скорости в thumb режиме может в идеале быть 160% (для 16-bit bus) см. http://www.keil.com/support/docs/2940.asp?bhcp=1

А какой "прирост", когда вместо:

такое:

А всего-то хотел

На реальных задачах получить прирост от Thumb не реально.

Ну шибко это от программиста зависит - если в лоб переносить asm код - то где-то так оно и будет. При использовании C, лично я не замечал замедления - компилятор оптимизирует функции thumb используя соответствующую стратегию - редкий код оперирующий в основном 32 битными значениями может потерять в производительности.

P.S. Я бы сделал так :

0: 4b01 ldr r1, [pc, #4] (8 <.text+0x8>) ; // 256
2: 18c9 adds r0, r0, r1

Сообщение отредактировал Harbour - Aug 26 2006, 07:47

:-)
"Стратегию" это хорошо. A в Arm компилятор, значит, о "стратегических" замашках забывает и пользуется только "тактическими", дабы не выделяться :-).

Для 32bit контроллера, с исключительно 32bit регистрами и с ограничеными возможностями адресации отличных 32bit данных, "редким" является прямо противоположное.
Соэдание искуственно кода выпячивающего "преимущество" Thumb естественно возможно.
А в реальной жизни размер кода уменьшается максимум процентов на 30, что явно показывает невозможность замены команда-в команду, при этом количество команд становится больше процентов на 40
(с учетом вновь появившихся констант несколько меньше) соответственно скорость падает очень заметно.
Падение скорости при работе из медленного Flash при наличии у контроллера кэшобразных наворотов несколько компенсируется и в этом случае получается провал процентов на 10-15.