вот я олух! ну ведь знал я о ключике -ffixed-rX!!! как я мог забыть?! а по поводу оптимизаторов что скажете?

А вот кстати
присоединяюсь, и аналогичный вопрос по AVR. А в основном уже сижу под линуксом, но вот подсел на чужие сборки и так сам и не наладил процесс :-)

а вопрос то в чем?

"Не имеется ли сборки для AVR для Ubuntu/64"

зддрасти приехали...
сообщение #343 читать до самого низу обязательно, Vasen уж наверно наверно педали нажимает, а Вы на стоянке пипелац в упор незаметили
если незаведется то кривым стартером (ldconfig) поможем - либы отделным архивом, их в /usr/lib usr/local/lib сыпать не нада - затрете системые и могут быть глюки потому что у меня версии свежие(т.е отличаются от тех что в ситеме), свалите сошки в отдельную папку и прокешируйте ее с помощщу ldconfig

Это Ваша версия, klen.


А это предпоследний yagarto


Как видите, в Вашу пользу выигрыш около 300 байт на 31 килобайт.
Прошивка работает, что приятно отличает от предпоследней версии. Прерывания, как Вы понимаете, заработали сами. Я не модифицировал текст (только префикс для компилятора в Makefile).

Стеки в bss... Пожалуй зря. На самом деле - не обратил внимания. Там ещё можно накопать - не используется user stack. Но очищаю bss я не в подпрограмме - потому и не заметил ничего плохого.
Где-то встретил требование по выравниванию стеков для ARM-EABI на 8 байт. Не прокомментируете?

klen, как Вы правильно заметили, делаю приёмник (уже давно разные варианты), сейчас на стадии рисования схемы платы передающего тракта для превращения в приёмо-передатчик. В программе формирование телеграфного сигнала с ручного манипулятора и управление автоматикой переключения приём-передача присутствует. Я на forum.cqham.ru этот проект выкладываю свежее состояние и фотографии плат.

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



я таки думаю что не прерывания неработали, а вообще ничего неработао (или работало непрвильно еще недоходя до прерываний)


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

Так он же вроде для ARM просил, а не для AVR.
Ладно, выдохну выпускной -- разберусь.

действительно, это я пипелац не увидел, извиняюсь.
выложу пожже

klen, не получилось развернуть архив со сборкой (сливал 2 раза).
Выкидывает вот такую ошибку:

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

Хм. Вроде все видно (там кликнуть надо для увеличения). Ну да ладно. Вот лог.

а это ваще как?
ладно, ниче не понятно, попробуем к кобыле с зади подойти. я сожму директорию без tar, посмотрим че получится.

http://klen.org/Files/DevTools/ubuntu64/kgp_arm_eabi.7z
http://klen.org/Files/DevTools/ubuntu64/kgp_avr.7z
http://klen.org/Files/DevTools/ubuntu64/lib.7z

прошу... еще один подход к снаряду

klen, спасибо еще раз. Подход к снаряду удался.

В чем разница между avr-gcc.exe и avr-gcc-4.6.0.exe ?

никакого

свежак

ARM:
http://www.klen.org/Files/DevTools/kgp_arm_eabi_20100630.7z
openocd собран с ключами
--enable-ft2232_ftd2xx
--enable-usb_blaster_ftd2xx
--enable-amtjtagaccel
--enable-ep93xx
--enable-at91rm9200
--enable-gw16012
--enable-presto_ftd2xx
--enable-usbprog
--enable-jlink
--enable-vsllink
--enable-rlink
--enable-arm-jtag-ew
тоесть теоретически все это барахло должно работать в качестве отладчиков, работать через libusb0 котроая тоже имеется. Кроме ft2232_ftd2xx на которой постоянно работаю проверили на MT-Link (jlink) - работает, что дает осноания полагать что и дрогие отдладчики должны работать.

win32:
http://www.klen.org/Files/DevTools/kgp_mingw32_20100630.7z

mips:
http://www.klen.org/Files/DevTools/kgp_mips_elf_20100630.7z

arm-kgp-eabi-gdb.exe выполнил недопустимую операцию и будет закрыт

klen, а вы не пытались отлаживать два кристалла, стоединенные в jtag-цепочку?

а как у меня тогда работает? значит так - те кто это читает не качайте дистрибутив или качайте но gdb возьмите из предыдущего архива. Заодно выяснится кто гонит пургу gdb или gcc хрень кладет в dwarf секции.
а я пока посмотрю тоже и если че обнаружу пересоберу ченить.


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

Я сначала пытался запустить только отладку, .elf был собран при помощи Yagarto от 20100501, получил ту же ошибку, пересобрал полностью проект вашей сборкой, результат тот же. Так что скорее всего gdb. gdb от yagarto работал. Можем списаться по асе или скайпу, попробуем разобраться вместе.
Там, похоже, бага в openocd - он когда сообщает gdb карту памяти, пихает в нее информацию о банках флеш обоих кристаллов и gdb ругается на перекрывающиеся регионы. Я заполнил bugreport на сайте openocd, но уже полтора месяца реакции никакой. Думал, может я чего-то не так делаю. Да и при обработке обратных вызовов у них там какая-то каша - вешаю для каждого ядра свой $_TARGETNAME configure -event reset-init, а он их исполняет всегда на текущем target. И вообще частенько путается между ядрами.

обновил исходники, пересобрал все, проверил на WinXP32bit и на Ubuntu 64bit, среда Eclipse Helios
все работает и отлаживаетсо. тестил на проекте USB девайса, былибы глюки гденибудь вылезло бы.

http://www.klen.org/Files/DevTools/kgp_arm_eabi_20100701.7z
дравер для JLink/MT-Link лежит в /share/drivers


по поводу падения GDB, у меня такие маразмы были четыре дня назад когда обновился на Helios, пришлось заводить новый workspace и перетягивать проекты туда из старого. исходя из того что все нормализовалось после этой процедуры, сдеал заключение что настройки CDT6 корорые были в старом workspace выкручивают мозги CDT7 - который потом маразмы посылает отладчику от чего тот дохнет.


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

The requested URL /Files/DevTools/kgp_arm_eabi_20100701.7z was not found on this server.
Убил и построил заново Workspace, результат тот же.
Попутный вопрос - в эклипсе в настройке debug configuration есть возможность выбрать GDB(DSF) Hardware debug launcher и Standart GDB Hardware debug launcher. Какой предпочтительнее? DSF, похоже, не реагирует на настройку формата отображения регистров - каждый раз приходится вручную переключать отбражение с десятичного вида на шестнадцатиричный. Для стандартного формат задается в Window->Preverences->C/C++/Debug. Для DSF есть что-то подобное?

И еще один вопрос - как вы подключаетесь к openocd - через tcp или через pipe? В helios у меня перестал работать запуск openocd через target remote | openocd --pipe. При запуске из командной строки все работает, а при запуске из эклипсы

Для этого надо:
a) быть уверенным, что это баг.
б) быть членом команды разработчиков.
Я пока застрял на первом пункте.

У меня такое было, пока я не сообразил, что надо указать openocd файл конфигурации :

Мда. Расследование показало, что оно теперь запускается не в директории проекта, а в домашнем каталоге c:/documents and settings/пользователь. Спасибо за наводку, ни за что бы не догадался. С меня "напиво"
Спасает добавление в поле GDB connect string после "| openocd --pipe" еще и " -s ${project_loc}".

klen, как насчет "пофиксить и выложить в репозиторий" эклипсы?

Добавлено: Хрен, не спасает. При запуске gdb из командной строки из любого места спасает, из эклипсы - нет

Отквочу для истории
Я так и не понял, каким образом у тебя раньше был указан файл конфигурации. У меня в настройках отладчика в поле "GDB command file" указано "prj/.gdbinit". А уже в этом файле весь скрипт для отладчика и прописан. Но это ещё бета Helios, и без доп. плагинов.
ЗЫ. А вообще это наверное офтопик здесь

да, по ошибке лишний символ ввел в имя файла. теперь должен качатся.
я DSF выключаю. с ним вроде не работало у менфя.

Господин Клейн! Почему бы вам не выложить ваш архив на местный FTP, благо вы имеете к нему доступ?
Если ваш ответ отрицательный, то спрошу, как вы отнесетесь к тому, если это сделает кто-то другой?

если Вам нада - выкладывайте архив куда угодно. только он через неделю потеряет актуальность. в этом прикол моих сборок.
1. я выкладываю на свой сервер потому что мне это удобно - на сервере раздел который я удаленно могу подмонтровать к любому бездисковому терминалучерез любую среду и полноценно работать имея доступ к своим инструментам
2, система сборки работает с этим разделом и делается все практически автоматом(за исключением того до чего руки не дошли).
3, у меня очень быстрое оборудование и подключено к хребту провайдера - Вы получаете высокую скорость и нагрузочную способность.
4. для девушек у меня ответ всегда положительный

свежак

ARM
http://www.klen.org/Files/DevTools/kgp-arm-eabi_20100707.7z

AVR
http://www.klen.org/Files/DevTools/kgp-avr_20100707.7z

MIPS
http://www.klen.org/Files/DevTools/kgp-mips-elf_20100707.7z

i686-pc-mingw32
http://www.klen.org/Files/DevTools/kgp-i68...w32_20100707.7z

сопутствующие тулсы
http://www.klen.org/Files/DevTools/make_sh_rm_touch.7z

а этот mingw крайний Qt собирает?

они у меня вроде все собирали текущий Qt, тока временами в qt нада рукиами залазить ( есть корявость с именами функций управления состоянием сопроцессора, может так и должно быть ? ).
я собираю переодически, щас пользую 460 только не помню сам собирал или сразу дистр скачал.

4.7 не собирается. На форумах пишут что это из-за сломанного gcc 4.5. Видимо придётся вернуться на 4.4.0

в моей сборке предлагается gcc 4,6, возможно соберется, попробую.
Qt 4.7 - бета, она может не собратся по своим внутренним причинам

Проблема со сборкой для AVR или это у меня путь как-то не так прописан!?

Стоит WinAVR 20100110 с ним всё работает!
Добавил рядом Ваш. С ним тоже работает пока не подключаю math.h

Если включить #include <math.h>
получаю сообщение:
In file included from ./Source/mss-1_atmega.c:198:0:
d:\develop\winavr_kgp\bin\../lib/gcc/avr/4.6.0/include-fixed/math.h:14:23: fatal error: sys/reent.h: No such file or directory
compilation terminated.
make: *** [obj/mss-1_atmega.o] Error 1

Без этого включения проект собирается нормально!
Похоже он пытается подключить не тот math.h так как их там два и в одном действительно есть ссылка на этот файл.

я это тоже увидел но после того как архив выложил, решил пока отключением math.h. посмотрю. походу хидер берет не оттуда.

В точности такая же история с limits.h при сборке бутлоадеров. Вызывается из boot.h. Не находится в include-fixed.
Пока решил правкой самого limits.h - удалил рекурсивное подключение самого себя в конце файла. Работает.

гдето косяг в определении путей препроцессором. наверно. я буду смотреть.

посмотрел. косяг устранен.
http://www.klen.org/Files/DevTools/kgp-avr_20100709.7z

klen

Добрый день!

Специально зарегистрировался на этом форуме, поскольку наткнулся на специалиста в области сборки кросс-версий GCC У меня есть пара вопросов: не планируется ли сборка достаточно свежей версии GCC, работающей под Виндой (mingw, cygwin -- без разницы), генерирующей код под ARM и включающей в свой состав компилятор Ады? Собственно, именно он и нужен, у меня пока что версия 4.0.1, а она глючит... Ну а второй вопрос: нельзя ли означенную Аду собрать для генерации кода под AVR (пускай без библиотек, голый компилятор)?

> Добрый день!

аналогично

>не планируется ли сборка достаточно свежей версии GCC

обычно раз в неделю я собираю наисвежайшую версию с наисвежайщими фичами и глюками, исходники из trunk SVN.

>работающей под Виндой (mingw, cygwin -- без разницы), генерирующей код под ARM и включающей в свой состав компилятор Ады?

все кроме ады есть. могу предложить фортран. с адой есть проблемы 1. чтоб собрать аду нужна первичная ада которая соберет новый компилятор - это архитектурная особенность ады. я могу собрать аду для i686 - вопрос а сможет ли она собрать аду для ARM, я не знаю но попробую, мне интересно.


> Собственно, именно он и нужен, у меня пока что версия 4.0.1, а она глючит... Ну а второй вопрос: нельзя ли означенную Аду собрать для генерации кода под AVR (пускай без библиотек, голый компилятор)?

4.0.1 - это чтото жутко старое

до чего манагеры негров довели - до цегундера! аду на AVR - такое только "могулы из верхнего руковдства" могут изобрести. сразу вспомнилось содержание книги Эдварда Йордана - "Путь камикадзе"

круче маразм может быть наверно только Java на К1878ВЕ1 к счастью это невозможно !

Фортран не годится, именно Ада потребна А в 4.0.1 наткнулся на ошибку компилятора (падает на совершенно корректном исходнике), посему и нужен переход на новую версию. Под кыгвином собственно кыгвиновский 4.3.какой-то мне собрать удавалось, но вот кросс-компилятор -- ни в какую...



Ну почему ж... Мне интересно было б глянуть, что из этого выйдет (если выйдет), хотя на практике под AVR пишу только на асме -- си/си++ терпеть не могу за ужасный синтаксис и провоцирование нелепых ошибок, а посему ну их куда подальше

> си/си++ терпеть не могу за ужасный синтаксис и провоцирование нелепых ошибок, а посему ну их куда подальше

ааа.... а я то думаю! я все понял - "вам нужны шашечки, а не ехать"

Вот только добрался...
После
отвалился evince, перестал показывать pdf-ки (пожужжит нмного и тихо умирает).
xpdf работает, в различиях использования ими библиотек не вникал. Остальное ежедневно используемое вроде бы без проблем.
Пока вернул взад и обошёлся добавлением в префикс в Makefile
хоть это и кажется немного кривым способом.

Как раз наоборот -- ехать, а не стоять из-за сплошных трудноуловимых багоглюков. Конечно, можно заявлять, что-де сам виноват, если по невнимательности пишешь && вместо & и т.п., но... Лично я предпочитаю, чтобы язык просто не допускал возникновения подобных ошибок. Ада соответствует этому критерию, Си -- абсолютно нет. В общем, пускай весь мир пишет на Си/Си++, если ему так хочется, ну а я буду на том, что мне удобней и больше нравится Впрочем, всё это лирика.

Огромное спасибо, сейчас буду попробовать.

>круче маразм может быть наверно только Java на К1878ВЕ1 к счастью это невозможно !
Для нашего булыжника с его asm нет ничего невозможного, я считаю )))
С него начинал..


UPD:
проверил, компиляется, работает.
boot.h больше не имеет претензий к limits.h

в связи с итересом некоторых коллег в контесте засовывания kgp в CrossWorks, выкладываю архив для CrossWorks. проверял на 1.7.15

klen.org/Files/DevTools/cw_1.7_gcc_20100707.7z

Спасибо огромное!

Скопировал в папку бин, появились такие вот ошибки. Со сторым GCC к-ый в 1.7.3 шел такого не было.

Ошибки вот такие вот:
D:/PRG_MKS/trunk/main.cpp:8: undefined reference to `__cxa_atexit'
D:/PRG_MKS/trunk/main.cpp:204: undefined reference to `__dso_handle'
D:/PRG_MKS/trunk/chiv/chive.cpp:5: undefined reference to `__cxa_atexit'
D:/PRG_MKS/trunk/chiv/chive.cpp:1130: undefined reference to `__dso_handle'
В каких модулях должны эти функции находиться? Что цеплять?


Заранее благодарен!

попробуйте их объявить в таком виде
void* __dso_handle = NULL ;
void
__cxa_atexit(void (*arg1)(void*), void* arg2, void* arg3)
{
}


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

даже больше- а че у Вас в main в срочках 8, 204 уж не аля printf или чето в этом роде?

а в теории должно работать - ведь деструкторы статических объектов никогда не вызываются! соответственно __cxa_atexit никогда не вызовется и никогда небудет использован указатель _dso_handle

Уже неоднократно публиковалось решение. Добавить к проекту вот этот файлик: Нажмите для просмотра прикрепленного файла.
(Нужда в нём, кстати, возникает при использовании чисто виртуальных функций)

дело тут немного интереснее - кросворкc использует не newlib а какуюто свою прикрутку которую они называют супер-мега-турбо-libc, поэтому им закон (интерфейс ) неписан
я это так понимаю. тоесть должно заработать но не факт что ковырять не прийдется как с "прозрачной" newlib

Удалось мне начерно собрать армовский кросс-компиль (си и ада) версии 4.4.4 под МингВ. И если с сями особых проблем не было (пара ошибок), то с адой пришлось побороться, вплоть до того, что одна фактическая ошибка была в исходниках. Библиотеку обкромсал очень сильно -- иначе не компилировалось, поскольку стандартный мэйкфайл пытался впихнуть сокеты и всякую прочую белиберду, которой в принципе быть не может в компиляторе под голое железо. Пока проверил на своём коде -- транслирует нормально, не падает (в отличие от ранее мной использовавшейся версии 4.0.1). Правда, много падений было во время сборки библиотеки под тумбу, из-за чего часть пакетов порезал нафиг (комплексная арифметика и ещё что-то там такое).