Использование моно во встроенном Linux для оборудования

Question

Я занимаюсь исследованиями для компании в качестве стажировки.У меня возник вопрос по поводу использования Mono, кроссплатформенной реализации платформы .Net.Моя компания разрабатывает аппаратное и программное обеспечение.

Мои знания по использованию встроенного Linux очень ограничены.Моя компания, где я прохожу стажировку, действительно настроена на .NET.Но новые разработки mono, они спрашивают себя, могут ли они ориентироваться на linux для небольших проектов, также позволяют избежать высокой стоимости лицензирования для людей, для которых они разрабатывают программное и аппаратное обеспечение.

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

Я видел несколько историй, в которых они просто взяли несколько стандартных библиотек Linux для создания встроенного Linux на оборудовании.Я также видел, что существуют специальные дистрибутивы Linux, такие как uClinux (он же µClinux).Так в чем же разница, или это все то же самое.Как обычно выглядит этот процесс, когда я хочу использовать встроенный linux на целевом устройстве?

ОК, чем монофоническая часть, поэтому в основном я хочу иметь возможность запускать C # во встроенном linux.Здесь в основном они используют uclinux, могу ли я использовать моно для этого?Я посмотрел на некоторые спецификации, и у них нет модуля управления памятью (MMU).

ТАК, в основном, я беспокоюсь о том, что нет MMU.Поскольку как будет реагировать сборщик мусора?

Надеюсь, я не дал перегрузки вопросов,

С уважением, и я уже благодарю вас за чтение,

Бенджамин

Answer 1

Сборщик мусора не зависит от MMU, хотя может быть более эффективным, если он есть.

В настоящее время мы используем его для генерации исключений нулевой ссылки без проверок: в uclinux вам нужно будет включить явные проверки (код уже есть, его просто нужно включить). Другие люди сообщали об использовании mono в uclinux, хотя, скорее всего, некоторые источники нуждаются в некоторых настройках, поскольку мы никогда не тестируем их на этой платформе (конечно, я говорю об uclinux на архитектуре процессора, которую мы уже поддерживаем, например, ARM, вы не указано).

Что касается других комментариев, AOT и mkbundle в значительной степени не имеют отношения к тому, что вам нужно. То, что вы действительно хотите, - это уменьшить монофоническую площадь, чтобы соответствовать тому, что позволяет ваше устройство, для получения дополнительной информации см. http://www.mono -project.com / Small_footprint .

Если бы я принимал решение, я бы всегда выбирал обычный ARM linux вместо uclinux для запуска сложного программного обеспечения, такого как mono, или любой другой программы, которая вам нужна для запуска на mono.

Answer 2

Моно может быть настолько ограниченным, насколько вы хотите. Если вы используете устройство без MMU, я бы посмотрел на Ahead of Time compilation .

mkbundle также может работать, но я не уверен, что это может обойтись без MMU. Тем не менее, если вы используете AOT, вы сначала будете использовать mkbundle, чтобы получить все зависимости.

Answer 3

Если на ваших устройствах нет MMU, возможно, вы захотите использовать Microsoft с открытым исходным кодом .NET Micro Framework . Он намного более ограничен, чем .NET / Mono, и это интерпретатор, а не JIT, но он может работать на намного более ограниченного оборудования.

Answer 4

Если ваша компания хочет ориентироваться на встроенные платы Linux через MONO, и все, что нужно, это перенести какое-то приложение, которое уже работает на настольном компьютере с Windows, тогда у вас, вероятно, будет очень мало проблем. Но если вы хотите поговорить с некоторыми IO, I2C, SPI, 1-Wire и другими периферийными устройствами, у вас будет проблема с доступом к ним через MONO, и вам, вероятно, придется сделать какой-то переводчик (вероятно, написанный в GCC), который будет шлюз между реальным оборудованием и приложением MONO.