Code Red Suit v2.0, Среда разработки на базе эклипса Опции

[Vitaliy_ARM]

Приобрели эту среду, так как очень хотелось иметь среду на базе эклипса с нормальным дебагером.
Среда на базе эклипса 3.3 и гнушного компилятора gcc 4.2.0. Этот вариант гораздо бюджетнее IAR.
О нем можно почитать здесь: www.code-red-tech.com

В кратце о среде:
Джитаг собран на FT2232, максимальная скорость - 6МГц. По сравнению с IAR,
работает заметно медленнее.
Геммора с настройкой проекта практически нет (C-проекта).
На мой взгляд, очень удачное решение для тех, кому нравится эклипс.

Со средой вместе идут несколько проектов, в частности для LPC17xx и LPC23xx/24xx. и гигобайтная флешка с фирменным лабелом.
Все проекты написаны на C, компилируются и работают сностно. При создании
проекта на С, автоматически генерируются 3 файла для компановщика.

При создании проекта на C++ так же генерятся три файла скрипта компановщика, в которых отсутствуют секции для конструкторов и прочее.
При использовании обычного класса компановщик начинает ругаться непонятными ошибками:

Код

make all
Building target: BootCR.axf
Invoking: MCU C++ Linker
arm-none-eabi-c++ -nostdlib -Xlinker --gc-sections -Xlinker -Map=BootCR.map -mcpu=arm7tdmi -T BootCR.ld -o"BootCR.axf"  ./src/DoCmd.o ./src/Emac.o ./src/Fldr.o ./src/PortIO.o ./src/Rc6.o ./src/Stip.o ./src/TestPins.o ./src/cr_startup.o ./src/main.o  
c:/code_red/red_suite/tools/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\libc.a(lib_a-abort.o): In function `abort':
abort.c:(.text+0xc): undefined reference to `_exit'
c:/code_red/red_suite/tools/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text+0x4): undefined reference to `_getpid'
c:/code_red/red_suite/tools/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text+0x2c): undefined reference to `_kill'
c:/code_red/red_suite/tools/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
collect2: ld returned 1 exit status
make: *** [BootCR.axf] Error 1

Был у меня еще один проект, который собирался в gcc ранней версии (уже не помню в какой). Путем колдовства и добавления секций, таких как .сtors и .dtors результата не принесло,
только ошибки сменились. Потом засунул скрипт от старого проекта линкеру. Написал, что все скомпилилось с размером кода 0.
Вывод пока такой, что ребята не доделали поддержку C++ (генерятся неправильные файлы линковщика). Возможность вставлять свой файл есть.
Приведу изначальный скрипт компановщика.
Может кто знает, чего там не хватает, может кто-то уже использует эту среду с С++?

Прикрепленные файлы

 Debug.zip ( 1.58 килобайт ) Кол-во скачиваний: 28

 

[klen]

вижу плагин, котрый парсит регисты переферии - это гуд

но чето 1000$ както дороговато на мой взгляд.

используется newlib, судя по компиллеру

[Vitaliy_ARM]

Вижу плагин, котрый парсит регисты переферии - это гуд
но чето 1000$ как-то дороговато на мой взгляд.

IAR вообще не реальных денег стоит. Этот еще можно купить

[klen]

ыыы

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

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

[Vitaliy_ARM]

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

Можно попробовать. У меня постоянно был геммор с отладчиком. GDB сервер постоянно вылетал, то сбоил, то еще чего нибудь выдавал, например жмешь перепрыгнуть
через функцию, а он туда залетает и потом вешается. Джитаг от Olimex. Сносно работал j-link со своим GDB сервером, но тоже не все было гладко. Короче говоря я надолбался с
бесплатным софтом, но так нормально и не настроил.
Думаю тут надо сначала состыковать это добро между собой, чтобы не глючило. А потом браться за плагин. В коде реде вроде бы свой GDB сервер, с их джитагом вроде работает
более или менее.
Как появится возможность, постараюсь залить на местный фтп эту среду.

Сейчас порюсь с такой проблемой, наверное это больше к линкеру относится. Переписываю свой бутлодер.
Где находятся вектора прерываний в этом коде? (перенос KEEP(*(.isr_vector)) в другую секцию, размещенную по нулевому адресу результата не принесло, может чего упустил?).

.text :
{
KEEP(*(.isr_vector))
*(.text*)
*(.rodata*)
KEEP(*(.init));
KEEP(*(.fini));
} > FLASH

Вот еще нашел такой комментарий в скрипте линкера:

/*
Note: (ref: M0000066)
Moving the stack down by 16 is to work around a GDB bug.
This space can be reclaimed for Production Builds.
*/

[Vitaliy_ARM]

Понял что вектора прерываний находятся полностью в KEEP(*(.isr_vector).

Однако .text должен находиться в в одной секции и после KEEP(*(.isr_vector).

Код

.boot :
    {
        KEEP(*(.isr_vector));
        *(.text*)
        *(.rodata*)        
        
    } > BOOTMEM

Если сделать так:

Код

    .boot :
    {
        KEEP(*(.isr_vector));        
        
    } > BOOTMEM

    .text :
    {
        *(.text*)
        *(.rodata*)  
    } > MFlash512

То дебагер улетает в undefine handler. Получается что вектор резета указывает не на начало .text, а непонятно куда.
В чем может быть дело, как правильно разнести вектора и основную программу?