[fontp 0]

Возник вопрос о переносе ассемблерных модулей из VDSP++ в gcc или в CrossCore® Embedded Studio.

Кто имеет опыт и может поделиться? Понятно, что в принципе можно причесать ассемблерный модуль к виду ассемблерной вставки,

однако с такой подход требует большого объема формальной работы по кодированию, да и для сложных ассемблерных модулей gcc

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

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

конвенциям С, С++ по передаче параметров?

Опять же какие типы объектных файлов использует CrossCore® Embedded Studio?

Вопрос связан,например, с тем, что AD выкладывал некоторые Application в виде объектных библиотек VDSP++. Возможно ли их использовать

в альтернативных средах?

[gbs 0]

Удалось ли вам продвинуться в изучении проблемы? Мы сейчас примерно с тем же столкнулись.

 

 

[fontp 0]

Удалось ли вам продвинуться в изучении проблемы? Мы сейчас примерно с тем же столкнулись.

 

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

Изучайте проблему использования elf-toolchain

http://electronix.ru/forum/index.php?showt...p;#entry1408344

 

Мне кажется, что для перехода к gcc нужны очень веские основания. В типичном случае целевая плата обрабатывает данные с ацп и результат передает через универсальные порты (ethernet, usb, can, uart, spi) на компьютер или сервер. Нет необходимости поднимать сервисы на целевой плате и достаточно VDSP ++ При этом нет никаких резонов для использования для целевой задачи gcc, за исключением одного случая - когда это бортовая автономная система и никакого больше компьютера или сервера нет, но есть потребность в службах, типичных для универсального компьютера. Например, автономная бортовая система в которой нужно поднять файловую систему на флешке