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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

отака фигня

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

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

Линукс на нем запустить не удастся.
Первая причина - отсутствие в этих чипах, насколько я знаю, интерфейса к внешней памяти. Линуксу все-таки нужно хотя бы 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 автор топика вряд ли осилит.

Хе-хе - знатная лапша



С такими ресурсами ногодрыгатель может и получится какой перенести А теперь внимание вопрос - зачем платить за то чтобы эмулировать сервисы ОС предоставляемой бесплатно ?

У меня видение Getting started with uClinux™ for STM32F10x high-density devices...
ЗЫ
Или имеется ввиду что автор не осилит воспользоваться готовым портом?

Упс, сорри на дезинформацию... Я почему-то считал, что у всех STM32F нет внешней шины.

А я что-то вообще не въехал -- а причем здесь Линукс?

Ну да, беспокойство автора библиотеки понятно. Но причем здесь Линукс? Библиотека использует какие-то функции ядра (линуксойдного)? Или использует в свою очередь какие-то вызовы из других библиотек (Линукса)? Если ничего этого нет, то зачем компилить под Линь? Может запросить обычную кросс-библиотеку (т.е. комповый файл, внутри которого коды команд Кортекса) и хэдерный файл. Потом при создании (естесственно!) на компе бинарника для кортекса эта библиотека будет тупо прилинкована к Вашему коду. Остается в сам проц (кортекс) залить полученный бинарник. Причем здесь Линукс?

Столько тумана. Кто кого хочет надуть? По моему при таком раскладе дел на старте проекта, нормально поднять его -- не получиться.

Ваш закрытый объектный файл скорее всего скомпилирован для х86, как вы его на арме исполнять собираетесь? А если он для арма скомпилирован, то есть такая секретная программа под названием линкер.

Вы задайте ему лучше вопрос, зачем там вообще линукс. Используют ли они какие-то сервисы ядра ОС, если да, то какие именно.
Если принципиальной привязки именно к ядру линукса нет, то пусть соберут либу в любой удобной вам среде и передадут вам ее вместе с файлом заголовка.

Это footprint самой системы. Отводите под приложение столько, сколько нужно. Есть примеры и с фильтрами, и с FFT, и с web-сервером.


Наверное для того чтобы сэкономить собственное (небесплатное, полагаю) время.

Какое отношение эти примеры имеют к конкретной ОС ?



Сервер серверу рознь - апач c пхп туда перенесете ?



Да-да - видимо для экономии вы сначала пишете под linux а потом ищете эмулятор linux за деньги Не проще сразу выбирать подходящую ОС или заплатить за разработку BSP если вы так цените свое время ?

Заказчику надо сказать, чтобы код был скомпилирован под ARM Cortex-M3 без использования чего-либо кроме Си Stdlib. Никаких внешних зависимостей не допускается. Если заказчик на такие условия пойдёт (что крайне маловероятно), то линукс вам не понадобится. Если есть зависимости, то надо проводить серьёзное изучение на предмет находимости этих зависимостей в исходниках, либо собранных под будущую платформу. Затем нужно будет выбрать достаточно толстый проц типа АРМ9 и потихоньку туда перетаскать все зависимости и собранную либу от заказчика.

И не забыть про FPU, так как можно гарантировать что он там потребуется. К тому же разрабатывалось это наверняка под PC, так что еще не факт что вообще в маленький ARM справиться.

я хоть и поклоник Линукса, но хочу сказать следующее!
в этой задаче не ясно на кой болт нужны эти мутные танцы с линуксом?
Както все мутно описано.
Даже если вы запустите проект - вы его потом не сможете поддерживать и развивать.
Или делайте без линукса, или с Линуксом но с открытым хотя бы для вас кодом.
Ох и на мучаетесь из за того что прогнетесь под закрытую библиотеку...

Очевидно - требование заказчика.



А вот это и есть главная проблема - очевидно исполнитель просто не подходит под требования заказчика.



Все эти "мучения" только в головах местных ненавистников открытого ПО Открывать нужно только код который непосредственно линкуется с кодом под GPL - таже glibc имеет лицензию LGPL которая разрешает линковку с закрытым кодом, QT тоже самое. Бинарные блобы есть даже в ядре - выход там простой, они вызывают функции-обертки и открывают код только оберток, так как блоб не вызывает напрямую функции ядра его можно уже не открывать. Выходов предостаточно.

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

зачем вообще люди устанавливают линуксы (ОС) на МК? для реализации многозадачности? и все?

Скорее, для более нетривиальных сервисов, доступных при помощи линукса: продвинутая сеть, файловые системы (включая NTFS), wifi-адаптеры (для многих есть линукс-драйверы) и т.д.

И можно абстрагироваться от аппаратных особенностей?
К примеру, я схемотехник/программист по мк, придумываю плату и т.п., аппаратно реализую все как считаю нужным/оптимальным, программирую драйвер под линукс для работы со своим хардом, а программист под лину (который не знает какой стороной держать паяльник и т.п.) может писать программы уже под лину/мой драйвер?
т.е. реализацию сложных проектов можно разбить на отдельних специалистов, а именно електронщиков и программистов?

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

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

Спасибо, дяденька, что объяснили детишкам неразумным их место в ряду таких крутых дяденек, каким являетесь Вы, услышавший слово "лина" и увидевших "ноута". Прозябали, так сказать в неведении. Ну теперь оно, конечно, полегчало!

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

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

написание ПО для МК куда более простая задача чем под ПК... я то сам по специальности программист под ПК, АВР по дороге изучил, реализовал несколько проектиков... просто в мк подводных камней ооочень мало, осваивается быстро, а вот стать спецом программистом под ПК... ууу... с этой виндой еще... с милионами библиотек и функций... вообще считаю не возможным, или возможным, но ужасно кривым, вот как винда к примеру, всегда была, есть и будет глючная))))

В мк там токо сложно идеально знать все существующие архитектуры и иметь опыт работы со всема...

вот поэтому считаю самой простой задачей - скурить даташит на МК и дрыгать ногами
средняя сложность - +еще изучаем лину
высокая сложность - разбиваем проект на "чистых" схемотехников и программистов, что более грамотно реализовать на отдельном готовом ПК/сервере

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

Вам никогда не казалось, что после "нескольких проектиков" на АВР несколько преждевременно экстраполировать свой опыт на все остальные МК, их подводные камни и сложности программирования?

странно... я думал мои модели реального мира верны, так как уже второй год приносят прибиль, все проекты на МК... проекты на ПК пользы 0, нужно работать на "дядю", притом я не учился на электрика и т.п., моя специальность повязана с высшей математикой

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

тогда вся сложность - присутствие на рынке ооочень разных МК, сложно все освоить

тогда осваиваем 2-3 основных архитектуры, например, АВР, АРМ, что там еще... кортекс... мало/много/нормально?

Нет. Хотя бы потому, что объем документации на сложный МК может отличаться на два порядка от AVR.

Добавлю: А решаемые "контроллерами" задачи на многие порядки. Причем точно так-же задача решаемая контроллером может превосходить те задачи, которые до сих пор задавали преподаватели Integral-лу . Даже на AVR8 делают не только мигалки светодиодами - по той-же вычислительной мощности эта AVR много круче первой персоналки IBM PC/XT.

Не угадали.
ARM, MIPS-M4K и куча 8-битников для души

Есть ли смысл подсчитывать "освоенные архитектуры"? После двух-трёх архитектур "освоение" следующей тривиально (если только это не экзотический монстр). Скорее, следует говорить о накоплении опыта решения различных задач различными средствами. Кругозор, так сказать.

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

МК у меня асоциируются с елементарними задачами (стиральная машинка, "умный" дом, моб. телефон, охранная система, станки с ЧПУ и т.д.), какие есть примеры реализованых проектом на МК поражающих воображение?

Ну Вы и сравнили- стиральную машину и станок с ЧПУ. Представляете сколько десятков человеко-лет уходит на написание софта для станка с УЧПУ?

Топик все больше походит на сеанс кормления тролля.

Вот они: Ariane 5 и Therac-25


Воистину так.

представляю, даже почти реализовал, в станке с ЧПУ больше проблем с механикой нежели с софтом, покрайней мере у меня было((( ПО шмулялось на пк, с ПКАД-овских файлов извлекаем нужны нам данные, а именно диаметри отверствий, их координаты, номинал детали, координаты, угол их расположения и т.п.
сложность была с механика+шаговые двигатели
по 485 порту швыряем нужные нам данные в МК, мк уже на системном уровне определяет на каком шаговике соко шагов сделать и т.п., в основном расматривал возможность изготовления ЧПУ по сверловке ПП и выставлению/запайке смд компонентов... но опять же, отсутствие материальной базы

Согласен, тема себя исчерпала. Закрываю.
Модератор.