Как настроить поддержку в CrossWorks Maverick сопроцессора для ep93xx?

Если под Winows, то, ИМХО, никак. Под Linux'ом можно попробовать прикрутить тулчейн от Цирруса, если CrossWorks это позволяет.

Хмм а почему?
К примеру Ep93xx\Src\Kernel\Hal\Common\crunch.s

Оно то должно как-то компилироваться??

А для WinCE впридачу идёт CrunchLib (где sqrt, sin, cos и тд оптимизированы под crunch) хотя толку от неё не скажешь, что особо много...

Ну почемуж никак.
Нада пересобрать GCC с поддержкой ep9312. Я как раз это собираюсь сделать. Если получится то выложу.

Я правильно понимаю что ep9312 как раз и содержит MavericCRUNCH. C точки зрения gcc пересобирается binutils в котором ассемблер здает кроме ARM инструкций еще и модуля MavericCRUNCH, и соответственно собирается gcc +newlib в котором по другому собирается libm - для использования инструкций сопроцессора. Все.

Если ктонить мне подарит долголетие к CW 1.6 build 3 то я ему сделаю поддержку чего угодно


Дык асемблер может ругнутся что незнает он таких инструкций.


Наверно так "оптимизирована"
Былаб у меня плата с таким девайсом яб с удовольствием поупражнялся вместе с GCC функции на ассемблерных вставках пореализовывать. Но нет девайса..

А у ep9301 есть сопроцессор?

Дык WinCE собирается и не ругается, а это был файл из HAL вот только компилятор С/С++ от MS не генирирует года Crunch =( (по крайне мере я про это ничего не нашел) поэтому в WinCE остается только CrunchLIB или ручками на ассемблере...


Нет, зато есть у всех остальных этого семейства (9302/9307/9312/9315)

[quote name='klen' post='179412' date='Nov 23 2006, 20:09']
А у ep9301 есть сопроцессор?
[/quote]
Нет, зато есть у всех остальных этого семейства (9302/9307/9312/9315)
[/quote]

какой большой облом я плакаю.
У терры-электроники есть дев-платка на 9301 - стоит ~4000р НО на 9301 , хотел уже побежать в магазин...
Olimex обесчает скоро появится тоже самое но на 9315: http://www.olimex.com/dev/index.html

Я уже созрел для такой машинки. Поставлю ее на авиамодель. Хотелосьбы чтоб она дешевле 250$ стоила

Да, я несколько погорячился - мне почему-то казалось, что crunch доступен только в виде бинарников. Но все равно, по-моему, овчинка выделки не стоит.


С точки зрения ассемблера это просто инструкции работы с сопроцессором - CDP, LDC, STC, MCR, MRC - они вполне могут и макросами определяться.

Эта появлюсь я в теме.

Во первых у olimexa существует точно такае же платка, но на 9302, в котором сопроцессор присутсвует. Терра похоже может закупить их если заказов будет более 100 у.е, то есть хотябы один. А на 9301 плат у них в наличии сейчас все-равно нет. Я в принципе то же заинтересован, так что можно сообща обратится к барыгам с просьбой привести платки.

Во-вторых. Я тут тоже с кроссворксом вожусь, правда пока с 1.5. в процессе возникли следующие вопросы.

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

2 почему линкер gcc ругаецца на inline функции как на multiply definition в разных модулях. Я объявил конечно функции из библиотечки atmel как static но по-моему это бред какой-то.

3 Каким образом компилять в thumb режиме? Дело в том что в программе используются обработчики прерываний, а они должны быть arm. Ну собственно вопроса то два. Во превых можно ли как то объяснить gcc что функция должна быть арм. Во-вторых насколько корректно скомпиляется прога, если не использовать общий обработчик в стартапе, а пользоваться __attribute__

4 Насколько возможно к этому долбаному кроссворску подключить сторониий gсс дистрибутив, например такой http://www.codesourcery.com/gnu_toolchains/arm/ Я так и не понял каким образом сделатть так, чтобы использовались библиотеки идущие с этой сборкой, а не от кроссворкса. Пробовал подключать только собственно компилер - с библиотеками кроссворкса не уживается.

Я всеми лапами ЗА. Очень хоцца помацать GCC+сопроцессор из исследовательских целей.


если компиллер генерит код с опцией -g.. то в объектник валются все секции код, данные, отладка и тд. Чтоб оставить только содержательный код нужно пройтись по elf-бинарникам и библиотекам утилитой strip (в пакете binutils), собраной под arm-elf.
Тем неменение в флешь заливается не ELF, а сделанный из него с помощью утилиты obj-copy HEX или BIN файл. Поэтому во флеш по любому не лезет лишние секции. Другое дело если вы не используете оптимизацию. То тогда GCC по умолчанию генерит все по стандарту и не отбрасывает "ненужный код". Попробуйте собрать с опцией -O1 или -O2 Напимер. код должен уменьшится и ускорится.



в отличие от других компиллеров в GCC для использования кода Thumb нужно этот код собирать в отдельных модулях и компелировать с опцией -mthumb, в дополнение к опциям компиляции модулей обоих типов необходимо добавить опуию -mthumb-interwork, чттоб компиллер генерил кодд совместимый с перекрестными вызоваи функций с кодом обоих типов.


Не только возможно но и категарически нужно. Поскольку в GCC найденные баги правятся "на лету", в отличие от коммерческих компиллеров.
Для этого нада просто поменять файлы в CrossWorks/gcc/bin на новые из другой сборки.

Людиииииии... есть у кого таблетка к CrossWorks 1.6 biuld 3, пааамираюю..

Я это дело проверял именно по размеру бинарника в профилях ARM flash debug и ARM flash release c подсоединненой бибилиотечкой усарта и без нее, в main в обоих случаях было просто записано for(;;);
с подсоедиными к проекту файлами бинарник занял около 9К в дебаге и около 5К в релизе, в то время как с неприсоединнеными файлами заняло что-то около 500 байт. Я могу повторить экспиримент с и привести точные данные если хотите.


ОК. Только мне осталось непонятным как при таком подходе будут работать обработчики прерываний, при условии что обработчик в startup не задействован.


Да дело даже не столько в багах сколько именно в возможности использовать сторонние дистрибутивы. а то вся прелесть gcc вобще-то и теряется.


Дык блин говорю же, так и поступал. причем можно даже ничего не менять указав путь к gcc в tools->options-build, компилятор по прежнему заглотил код, но линкер начал ругатся на оепратор деления , типа не смог наети entry point или что-то в этом роде.



кстати а что с inline? Я что то непонимаю или как?

To Klen. Умирать не стоит.

Есть добро на земле русской!! огромное спасибо.
Пытался собрать gcc под ep9312 - компиллер собрался, а с асмом поблема - на инструкции сопроцессора гавкает - убедился что нада пересобрать binutils отдельно для ep. Доделаю выложу потестировать.
Сам компиллер генерит правильный(тоесть использует сопроцессор а не библиотечную эмуляцию) асм код. Смотрел вывод по асму.