Jump to content

    
Sign in to follow this  
RomanG

Переносимость на embedded Linux

Recommended Posts

Тут нужно в первую очередь рассматривать ресурсы чипа и реализацию BSP а не тип дистритутива.

 

 

В порядке убывания стандартизированности:

Ethernet

USB

LCD

GPIO

 

 

 

 

+100500

Честно говоря, я предполагал, что где-то так:

представьте себе поле. Большое. И там везде грабли, грабли, грабли..

До самого горизонта.

:lol:

Но все же хотелось верить во все хорошее....

 

В порядке убывания стандартизированности:

Ethernet

USB

LCD

GPIO

Насколько я понял, чем менее стандартный драйвер, тем более вероятны проблемы при каких бы то ни было переходах. Поэтому при использовании не очень стандартной аппаратуры (GPIO, I2C, LCD(?)) "светлого будущего" с полной переносимостью кода между разными embedded платформами на Linux пока нет. Может, конечно, повезет, но рассчитывать на это, наверное, не стоит. Такое вот впечатление...

 

Спасибо всем за ответы, жаль, что тема (как это часто бывает) перерастает во flame

:smile3009:

Share this post


Link to post
Share on other sites
Насколько я понял, чем менее стандартный драйвер, тем более вероятны проблемы при каких бы то ни было переходах. Поэтому при использовании не очень стандартной аппаратуры (GPIO, I2C, LCD(?)) "светлого будущего" с полной переносимостью кода между разными embedded платформами на Linux пока нет. Может, конечно, повезет, но рассчитывать на это, наверное, не стоит. Такое вот впечатление...

Под более менее распространненые порты (GPIO, SPI, I2C) существуют фреймворки, которые обеспечивают стандартный интерфейс. Тут весь вопрос в реализации нижнего слоя драйвера, который непосредственно общается с аппаратурой. А именно кто и как его будет/должен реализовывать. Производители микропроцессоров этим как правило не занимается, а в комьюнити ветку тянут два-три человека, которым м.б. эти модули для своего проекта и не нужны совсем.

Так что это не флейм, скорее эмоции от путешествия по полю с граблями:)

 

Share this post


Link to post
Share on other sites
Под более менее распространненые порты (GPIO, SPI, I2C) существуют фреймворки, которые обеспечивают стандартный интерфейс.

Нельзя ли примерчик такого фреймворка?

 

Тут весь вопрос в реализации нижнего слоя драйвера, который непосредственно общается с аппаратурой. А именно кто и как его будет/должен реализовывать.

В таком случае, если я использую такой фреймворк и перехожу, например, на OEM-модуль Colibri от Toradex для которого драйверы имеются, шанс на переносимость кода по работе с аппаратурой на другую платформу есть? (То, что грабли, в принципе, могут встретиться в любом месте я уже понял :) )

 

Share this post


Link to post
Share on other sites
Нельзя ли примерчик такого фреймворка?

 

Они все описаны в документации к ядру

http://lxr.free-electrons.com/source/Documentation/

 

шанс на переносимость кода по работе с аппаратурой на другую платформу есть?

 

100%, нестандартные драйверы даже TI не пишет, в этом просто нет смысла. Будет разница в подключении поэтому потребуется корректировка - номера GPIO, интерфейсов, чипселектов и т.д.

Edited by sasamy

Share this post


Link to post
Share on other sites
Нельзя ли примерчик такого фреймворка?

 

 

В таком случае, если я использую такой фреймворк и перехожу, например, на OEM-модуль Colibri от Toradex для которого драйверы имеются, шанс на переносимость кода по работе с аппаратурой на другую платформу есть? (То, что грабли, в принципе, могут встретиться в любом месте я уже понял :) )

Да, тут граблей меньше. Если уже есть драйвер, это большое дело.

Я так понял что драйвер есть, на Интеле пашет, надо на АРМ?

1. Посмотреть, чтоб версия кернела на Интеле поддерживалась бы производителем платы АРМа.

2. Читать документацию на плату, потому как там не редко еррата с "все хорошо, только 28я ножка на плате не работает".

 

Share this post


Link to post
Share on other sites
Нельзя ли примерчик такого фреймворка?

 

Поищите в этом треде. Три фреймворка здесь обсуждались.

 

http://electronix.ru/forum/index.php?showtopic=113476

 

ZIO должен быть серьёзным. Один из авторов соавтор библии линуксовских драйверов.

 

 

Однако фреймворк не панацея от всех проблем и при переносе системы вы столкнетесь с проблемами, которых фреймворком не решить. Фреймворки работают для драйверов устройств, которые вы хотите подключить к работающей системе. Есть много драйверов, с которыми фреймворк вам не поможет.

Я бы вам посоветовал не переносить систему с платформы на платформу, а найти работающую платформу на том процессоре, что вы планируете использовать.

Следующим шагом научиться строить кернел для этой платформы.

Далее изучить индивидуальный файл для этой платформы, где определена только ее конфигурация

для ОМАП2 и ОМАП3 это файлы из:

arch/arm/mach-omap2/

Для Биглборда машинный файл board-omap3beagle.c лежит здесь. board-omap3evm.c для мистралевского борда на AM3715.

Здесь создаются все устройства, которые вы собираетесь использовать.

 

С дисплеем можно попасть в струю если есть возможность выбирать. Для проекта, что я работаю сейчас мы нашли дисплей,что обошлись без драйвера. Я только добавил видео моду для нужного разрешения (1024х600).

I2C, SPI, GPIO драйверы писать не надо. все уже есть. Правда если вы хотите подключить какой-нибудь чип, использующий скажем I2C, то вам придется писать драйвер (а то и не один) для поддержки всей остальной части чипа.

Хорошие новости. Множество драйверов уже реализовано. Иногда поддержка производителя чипа дает коды драйверов.

Edited by Tarbal

Share this post


Link to post
Share on other sites
Я так понял что драйвер есть, на Интеле пашет, надо на АРМ?

Задача следующая: выбираем вычислительную платформу для одного мобильного устройства, то есть как аппаратуру, так и ОС. Хотелось бы иметь возможность перехода на другую аналогичную аппаратуру, если выбранный OEM-модуль снимут с производства. Меня сейчас интересует выбор ОС: Linux, либо Android ( Windows будет тяжеловат). Android в наших экспериментах обеспечивал 100% переносимость (как и следовало ожидать). Программа работает на разных платах, устройствах, смартфонах одинаково. Минус - ограниченный набор интерфейсов и потери производительности на Java-машине.

 

 

Поищите в этом треде. Три фреймворка здесь обсуждались.

http://electronix.ru/forum/index.php?showtopic=113476

ZIO должен быть серьёзным. Один из авторов соавтор библии линуксовских драйверов.

Спасибо!

Share this post


Link to post
Share on other sites
Задача следующая: выбираем вычислительную платформу для одного мобильного устройства, то есть как аппаратуру, так и ОС. Хотелось бы иметь возможность перехода на другую аналогичную аппаратуру, если выбранный OEM-модуль снимут с производства. Меня сейчас интересует выбор ОС: Linux, либо Android ( Windows будет тяжеловат). Android в наших экспериментах обеспечивал 100% переносимость (как и следовало ожидать). Программа работает на разных платах, устройствах, смартфонах одинаково. Минус - ограниченный набор интерфейсов и потери производительности на Java-машине.

Разницы не будет. Проблема с портированием самого Линукса (ядра) на платформу. А юзерленду все равно фактически.

Ну у вас вариантов нет, что Линух, что Андроид придется портировать.

 

Share this post


Link to post
Share on other sites
Разницы не будет. Проблема с портированием самого Линукса (ядра) на платформу. А юзерленду все равно фактически.

Ну у вас вариантов нет, что Линух, что Андроид придется портировать.

 

Причем в случае Андроида портировать тоже Линукс :)

Share this post


Link to post
Share on other sites
Разницы не будет. Проблема с портированием самого Линукса (ядра) на платформу. А юзерленду все равно фактически.

Ну у вас вариантов нет, что Линух, что Андроид придется портировать.

А если предположить, что для обоих платформ существуют готовые дистрибутивы Android и Linux с необходимыми драйверами (про совместимость драйверов данных нет)? С андроидом, как я уже писал, наблюдаем очень хорошую переносимость: экранчик, USB, мышка/тачпад работают на всех протестированных устройствах без какого бы то ни было портирования нашего ПО. После обсуждения в данной теме складывается впечатление, что от Linux такого ожидать не стоит. Это так?

Share this post


Link to post
Share on other sites
А если предположить, что для обоих платформ существуют готовые дистрибутивы Android и Linux с необходимыми драйверами (про совместимость драйверов данных нет)? С андроидом, как я уже писал, наблюдаем очень хорошую переносимость: экранчик, USB, мышка/тачпад работают на всех протестированных устройствах без какого бы то ни было портирования нашего ПО. После обсуждения в данной теме складывается впечатление, что от Linux такого ожидать не стоит. Это так?

Ну если дистрибутивы готовы, то какие могут быть проблемы?

Все должно быть пучком. Хоть Линух, хоть Андроид

Share this post


Link to post
Share on other sites
А если предположить, что для обоих платформ существуют готовые дистрибутивы Android и Linux с необходимыми драйверами (про совместимость драйверов данных нет)? С андроидом, как я уже писал, наблюдаем очень хорошую переносимость: экранчик, USB, мышка/тачпад работают на всех протестированных устройствах без какого бы то ни было портирования нашего ПО. После обсуждения в данной теме складывается впечатление, что от Linux такого ожидать не стоит. Это так?

 

драйвер для Линукса и для Андроида будет один и тот же. Андроид формально неверно называть ОС, в качестве операционной системы он использует Линукс. Андроид это Линукс + надстройка. Я бы отдал предпочтение Андроиду.

 

У нас сейчас такая проблема. Портирую Ubuntu на iMX53 драйверы работают, но для использования хардверных видео декодеров и енкодеров скажем H264 надо использовать Gstreamer, который работает в пользовательской моде. Там элементы написаны с кучей недокументированых свойств. Получить поддержку от Фрискейла не удалось. Движемся методом проб и ошибок.

В Андроиде нет нужды обеспечивать работу енкодера и декодера на уровне Gstreamer. Там если нет харверной поддержки H264, то оно не работает и Фрискейл не может отрапортовать, что оно работает с Андроидом. Да к тому же сейчас все силы поддержки на Андроид нацелены.

Резюме: С Линуксом у вас будет больше проблем.

Share this post


Link to post
Share on other sites
Андроид формально неверно называть ОС, в качестве операционной системы он использует Линукс. Андроид это Линукс + надстройка.
Линукс -- это не операционная система. Это ядро.

Share this post


Link to post
Share on other sites
Линукс -- это не операционная система. Это ядро.

 

Значит если я переставлю кернел от Убунту на Красную Шапку, то Красная Шапка превратится в Убунту?

 

Edited by Tarbal

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this