Всем добрый день!

Возникла необходимость разработать один девайс на ARM Cortex под управлением Linux.
Ранее писал под ARM'ы, DSP, восьмибитники, но только на Си или ассемблере, т.е. дело с Линуксом и операционками в принципе не имел.

После исследования интернета нашёл кучу информации о том, как сконфигурировать ядро. Но, все статьи такого плана заканчивались словами а-ля "...теперь ядро благополучно залито, с чем мы вас и поздравляем". И всё.

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

Он пишется на стандартном С или нет? Как оформляются файлы проекта? Как происходит его интеграция в ОС? И т.д.

Подскажите, пожалуйста, в общих чертах, принцип разработки проекта после внедрения ядра в контроллер. Или/и направьте на хорошую тематическую литературу.

Всем большое спасибо заранее!

Какой именно Cortex M3, не знаю таких который бы имел MMU, а без него только uClinux или что-то вроде UCOS. Раз вы раньше писали под ARM'ы, DSP, восьмибитники, то пора бы и знать об этом. Ну и поиск можно было бы..

Планировался STM32F103.
Дистрибутив роли совершенно не играет, единственным фактором, из-за чего необходимо использовать Линукс, является то, что к проекту нужно будет обязательно подключить некоторую математическую библиотеку под Линукс, предоставляемую заказчиком.

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

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

P.S. Сейчас ещё раз воспользуюсь поиском, предыдущая попытка успехом не увенчалась. Если что, извиняюсь за дублирование темы.

Сообщение отредактировал SiMiLya - Nov 4 2010, 08:15

Что-то я не пойму, зачем математической библиотеке линукс.
И что такое библиотека?
Бинарник или исходники?
Если бинарник, то его полюбому надо компилировать под конкретное железо, если исходники - то можно переписать как надо без всяких линуксов.

Короче, у заказчика есть какой то супер-пупер алгоритм комплексирования (задача по комплексированию курса, навигация) который он купил за большое бабло, и теперь хочет его внедрить в этот проект. А алгоритм сам представляет собой, как выразился мой коллега (не ручаюсь за смысловую правильность его слов) "закрытый объектный файл" для Линукса, который в качестве исходника, мол, мы увидеть не можем.
Посему надо изголятся, чтобы найти возможность использовать эту стороннюю математику в новом проекте.

P.S. Вкратце, этой сторонней математикой мы должны обрабатывать принятые показания двух приборов.

Сообщение отредактировал SiMiLya - Nov 4 2010, 08:26

Посмотрите Unison v4, v5
http://www.rowebots.com/products/unison_rtos
Ее можно запустить на ARM Cortex M3 без MMU. Но это не Linux. Но авторы обещают облегченный перенос Linux-приложений под нее.Кажется, это Ваш случай

P.S. Она платная.
http://www.rowebots.com/khxc/index.php?app...sonarmcm3-stm32

Вам пояснил MrYuran, что если файл бинарный (или объектный), то он уже скомпилирован под конкретное ядро. Linux - это просто система. Она может исполняться как под ARM так и под Intel, к примеру. Соответственно скомпилирована ваша библиотека под конкретное железо. И просто так вы эту библиотеку в любой проц не вставите.

Кроме того, если математика сложная, то производительность Cortex-M3 вас может не устроить. Учитывая тормоза самой системы на этом камне. Так что уточните свою задачу, возможно выбор уже будет само сабой разумеющимся.

Спасибо за интересную информацию, никогда ранее не слышал о подобных системах.
Но, зная этого заказчика, уверен на 200% что денег на описанный UNISON он не даст





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

P.S. ТЗ я получал от человека, который, грубо говоря, занимается менеджментом, и в теме разработки (а в Линуксе и подавно) имеет оочень поверхностное представление. Возможно, идея "передать объектный файл с математикой" из уже ранее реализованного проекта, а не исходник, в корне не верна, и всё в конечном итоге сведётся к совсем другим вещам...


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

Правильный подход у тех, кто хочет сберечь интеллектуальную собственность.
Если Вам развязали руки в выборе ядра и железа, то всё упрощается. Составляйте ТЗ и вперёд. В плане ПО главное, чтобы у Вас с заказчиком тулчейны были одинаковые. Работать с подключенной библиотекой может любой вразумительный тулчейн, GCC в частности. Необходимости применять Linux, как и ОС вообще, нет никакой.

никогда таким не занимался и надеюсь что не займусь
предполагаю, что заказчик проекта не хочет давать исходники, т.к. он за них заплатил "кучу бабла" и это его право.
скорее всего вам будет выслана некая либа (библиотека), бинарник, скомпилированный под "выбранный вами АРМ и ОС"
думаю, что принцип работы с ней будем примерно как в Виндовс с DLL - ваша софтина открывает эту либу и пользуясь стандартными заголовками вызова функций взаимодействует с ней. Заказчик должен приложить к бинарнику некий файл хидера, где описаны имена и формат вызова этих функций.
Имхо, в сорцах главное не сам код, а алгоритм работы и логика работы. За это платят деньги - за "интеллектуальную собственность", ну а закодить может почти любой кодер. Разумеется с поправкой на вариации лучше/быстрее/компактнее..
Чужой бинарник почти всегда, при наличии доступа, можно попробовать дизассемблировать, отрассировать, пошагово отдебагить. В случае несложных подпрограмм восстановить алгоритм, ну и написать аналогичный код. Напротив, сорец написанный скажем на Си, использующий плавучку, шифрование и пр. хрень адски тяжело восстановить. (надеюсь это очевидно).
Ну и как написали выше - встает проблема оценки быстродействия. Понятно, что если система только тем и занята, что обсчитывает данные в супер-пупер либе и молчит на все запросы, то это фиговая система. Т.е. хорошо бы с заказчика вытрясти оценочное время работы его функций (в шагах, в тактах, во времени выполнения на тестовой системе)..
Далее можно пойти разными путями
- взгромоздить линукс под АРМ, получить с заказчика бинарник библиотеки, написать свою загружаемую софтину, которая будет делать требуемое
- занятся написанием т.н. стандалоне - единственная программа-прошивка под АРМ управляющая всем. В этом случае заказчик должен прислать либу, откомпиллированную видимо для определенного адреса и список функций с адресами, форматами ввода/вывода данных

отака фигня

Выделенное не обязательно. Обьектные файлы, коими являются либы, являются перемещаемыми. Раздачей адресов занимается линкер при сборке всего проекта.

Вполне можно и так, впрочем это на усмотрение ТС - как ему душить заказчика.
И полная документация на работу с либой - формат и место входных данных, формат и место выходных данных, требования к памяти. Чем больше инфы тем легче разработка.

Сообщение отредактировал Jury093 - Nov 4 2010, 12:08

Линукс на нем запустить не удастся.
Первая причина - отсутствие в этих чипах, насколько я знаю, интерфейса к внешней памяти. Линуксу все-таки нужно хотя бы 4МБ ОЗУ.
Вторая причина - даже если найти чип на Cortex-M3 с интерфейсом SDRAM (например, дождаться LPC177x или LPC178x), линукс придется самостоятельно портировать на этот чип. Насколько я знаю, никто не портировал линукс на Cortex-M3. На Cortex-A8 - портировали, а на M3 - нет.



Вероятно, заказчик будет не очень рад необходимости портировать библиотеку на что-то экзотическое.
Значит, надо взять какой-нибудь более подходящий и хорошо известный процессор.
Возьмите AT91SAM9260, например. На нем прекрасно заработает линукс.
Или возьмите Blackfin BF51x - там uClinux нормально работает.
И то и другое экзотикой не является, и заказчик, скорее всего, сумеет без больших проблем собрать под эти процессоры бинарник своей библиотеки.

ARM Cortex M3 + Linux? Тогда уж uClinux...

Не согласится ли заказчик дать бинарник в виде LLVM-байткода? Тогда можно выбирать вообще любой процессор...

uClinux и linux - не велика разница, по большому счету. Наличие или отсутствие MMU на количество потребной RAM не влияет.
Кстати, основные uClinux-овские патчи уже несколько лет входят в ванильное ядро линукса, так что uClinux теперь - это система сборки да обозначение того, что MMU не используется, а вовсе не отдельный проект.
И в любом случае, порт на Cortex-M3 автор топика вряд ли осилит.