реклама на сайте
подробности

 
 
> Возможность переноса кода BF между разными средами разработки, Совместимость модулей VDSP++, gcc, CrossCore®Embedded Studio
fontp
сообщение Jan 23 2016, 17:13
Сообщение #1


Эксперт
*****

Группа: Свой
Сообщений: 1 467
Регистрация: 25-06-04
Пользователь №: 183



Возник вопрос о переносе ассемблерных модулей из VDSP++ в gcc или в CrossCore® Embedded Studio.
Кто имеет опыт и может поделиться? Понятно, что в принципе можно причесать ассемблерный модуль к виду ассемблерной вставки,
однако с такой подход требует большого объема формальной работы по кодированию, да и для сложных ассемблерных модулей gcc
может не хватить регистров. На уровне исполняемых задач известны способы загрузить dxe или ldr и исполнить их, под uLinux. Однако,
это требует вручную разрешать конфликты ресурсов. Существует ли возможность подключения "чужих" объектных файлов, следующих
конвенциям С, С++ по передаче параметров?
Опять же какие типы объектных файлов использует CrossCore® Embedded Studio?
Вопрос связан,например, с тем, что AD выкладывал некоторые Application в виде объектных библиотек VDSP++. Возможно ли их использовать
в альтернативных средах?
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов (1 - 2)
gbs
сообщение Feb 29 2016, 11:42
Сообщение #2





Группа: Участник
Сообщений: 7
Регистрация: 25-05-15
Пользователь №: 86 860



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

Go to the top of the page
 
+Quote Post
fontp
сообщение Mar 2 2016, 16:56
Сообщение #3


Эксперт
*****

Группа: Свой
Сообщений: 1 467
Регистрация: 25-06-04
Пользователь №: 183



QUOTE (gbs @ Feb 29 2016, 15:42) *
Удалось ли вам продвинуться в изучении проблемы? Мы сейчас примерно с тем же столкнулись.


Нет, ведь это практическая проблема, а не умозрительная. Поэтому, я попросил поделиться опытом тех, кто этот путь проходил.
Изучайте проблему использования elf-toolchain
http://electronix.ru/forum/index.php?showt...p;#entry1408344

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

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 29th July 2025 - 06:46
Рейтинг@Mail.ru


Страница сгенерированна за 0.01349 секунд с 7
ELECTRONIX ©2004-2016