Real time систему построить нельзя, из-за сборщика мусора. Время его включения не просто предсказать.
Насчет прерываний, они используются на уровне HAL. Я на 100% не уверен, но по-моему на уровень управляемого кода аппаратные прерывания не выносятся вообще. Там работа с периферией абстрагирована от аппаратной платформы.
Например вся работа с I2C сводится по сути к 1 функции — Execute, которая синхронно выполняет транзакции чтения или транзакции записи. Если нужна асинхронность — нужно создавать отдельный поток. А вот отработка Execute с обработкой прерываний I2C уже реализована на уровне HAL из управляемого кода не видна вообще.
Вполне может быть и зло. Я не специалист по WPF и XAML, хотя и писал WPF приложения.
В .Net MF WPF урезан, но все же он остается WPF. Сам движок, структура классов, их свойства и методы, подходы к созданию интерфейсов — все соответствуют WPF из «большого» .Net.
Все таки микроконтроллеры — не та платформа, где вам нужно рисовать сногсшибательные интерфейсы.
Посмотрите вот этот ролик Это все сделано на урезанном WPF.
Я не видел как выглядит код ядра линукса, но в .Net MF HAL достаточно запутан.
Если коротко, то когда вы делаете новый порт, вы выбираете фичи, которые хотите реализовать, и вам собирается специальным Wizard'ом проект, содержащий заглушки, вместо которых нужно написать код. Все нужно реализовать более 100 функций.
Вот только порт разделен на элементы, которые взаимосвязаны друг с другом. Это взаимосвязи отследить сложно. Понять откуда тут взялась эта функция и кто ее вызывает порой очень не просто.
В свое время мы всю голову словами. Хотя проблема там не столько в структурировании, сколько в скудности документации.
Мы с коллегой в процессе работы сделали специальную прогу, помогающую делать порты.
Сейчас она на стадии включения в netmf.codeplex.com. Надеемся что она поможет…
Я попозже, подготовлю статью, где постараюсь изложить общую информацию о портировании.
WPF — это концепция а не язык. Он позволяет писать код как на XAML так и на C#. Разница только в представлении.
Для .Net MF же есть неофициальная надстройка, позволяющая использовать XAML.
Это продукция американской компании GHI Electronics. Сайт, кстати, тоже их. Они давно уже специализируются на .Net MF. На «поиграть» у них можно купить что-нибудь. Правда ближайший ретейлир находится в Чехии. Но вот строить производство на их продукции не выгодно. Слишком дорого выходит.
Кстати есть и другие производители, но их не много.
5. Я не работал особо никогда с Linux, но могу сказать что, в основном, для Linux нужны процессоры с MMU. А контроллеры типа ARM7 или CortexM таковых не имеют. Единственный дистрибутив, не требующий наличия MMU, о котором я знаю — uClinux. Но о его портировании я ни чего сказать не могу.
5а. Тут сравнить легко. Linux — ОС, а .Net MF — нет. Я думаю, что Linux обладает бОльшими возможностями.
По поводу разработки: разница та же что и между разработкой для десктопного Linux на C++ и разработкой на C# под .NET. На мой взгляд, по удобству и поддержке .NET будет привлекательнее.
А вообще тут вопрос в том, что вы хотите сделать и сколько на это потратить. Все-таки Linux это больше уровень WinCE а не .NetMF. Ну плюс еще личные предпочтения :).
Лично я считаю, что использование .Net MF будет немного быстрее и дешевле чем Linux.
Это не ОС вообще. Это среда исполнения управляемого кода, запущенная на «голом процессоре». Можно кстати сделать порт и под любую ОС.
Основные требования — 32 разрядность и достаточное количество памяти.
По поводу переноса — если вы имеете ввиду как запустить TinyCLR на не прошитом микроконтроллере — то нужно шить так же как и любую другую программу.
Если вы имеете ввиду само приложение, то есть специальные программы для «разворачивания» приложений. Такую программу можно написать и самому. Visual Studio это делает автоматически при отладке.
Я тоже думаю что не стоит начинать с этого. Сначала нужно знать что и как работает внутри микроконтроллера.
Кстати, Microsoft буквально пару недель назад запустила новый проект на базе .Net MF — .NET Gadgeteer. Это что-то вроде конструктора, который можно программировать. По их мнению, этот проект должен служить образовательным целям.
1) Конкретных замеров по скорости я не производил. Но на вид, работает все быстро. Например, в поставке есть приложение — семпл, представляющее собой web-сервер. Он работает вполне быстро. Есть конечно и косячки. У нас сейчас проблема со скоростью отклика на нажатие кнопок, но похоже это проблема нашего порта а не самого .Net MF
2) Насчет портирования — я думаю, я напишу статью поподробнее.
3) Главное отличие — нет официальной поддержки XAML. То есть весь код пишется на C#. Ну и основные объекты можно пересчитать по пальцам. Правда, это не мешает делать хорошие интерфейсы и, на мой взгляд, это несет больше порядка. На базе .Net MF есть полноценная графическая оболочка — Pyxis 2.0. Она, кстати, тоже бесплатная.
Насчет прерываний, они используются на уровне HAL. Я на 100% не уверен, но по-моему на уровень управляемого кода аппаратные прерывания не выносятся вообще. Там работа с периферией абстрагирована от аппаратной платформы.
Например вся работа с I2C сводится по сути к 1 функции — Execute, которая синхронно выполняет транзакции чтения или транзакции записи. Если нужна асинхронность — нужно создавать отдельный поток. А вот отработка Execute с обработкой прерываний I2C уже реализована на уровне HAL из управляемого кода не видна вообще.
В .Net MF WPF урезан, но все же он остается WPF. Сам движок, структура классов, их свойства и методы, подходы к созданию интерфейсов — все соответствуют WPF из «большого» .Net.
Все таки микроконтроллеры — не та платформа, где вам нужно рисовать сногсшибательные интерфейсы.
Посмотрите вот этот ролик Это все сделано на урезанном WPF.
Если коротко, то когда вы делаете новый порт, вы выбираете фичи, которые хотите реализовать, и вам собирается специальным Wizard'ом проект, содержащий заглушки, вместо которых нужно написать код. Все нужно реализовать более 100 функций.
Вот только порт разделен на элементы, которые взаимосвязаны друг с другом. Это взаимосвязи отследить сложно. Понять откуда тут взялась эта функция и кто ее вызывает порой очень не просто.
В свое время мы всю голову словами. Хотя проблема там не столько в структурировании, сколько в скудности документации.
Мы с коллегой в процессе работы сделали специальную прогу, помогающую делать порты.
Сейчас она на стадии включения в netmf.codeplex.com. Надеемся что она поможет…
Я попозже, подготовлю статью, где постараюсь изложить общую информацию о портировании.
Для .Net MF же есть неофициальная надстройка, позволяющая использовать XAML.
Кстати есть и другие производители, но их не много.
5а. Тут сравнить легко. Linux — ОС, а .Net MF — нет. Я думаю, что Linux обладает бОльшими возможностями.
По поводу разработки: разница та же что и между разработкой для десктопного Linux на C++ и разработкой на C# под .NET. На мой взгляд, по удобству и поддержке .NET будет привлекательнее.
А вообще тут вопрос в том, что вы хотите сделать и сколько на это потратить. Все-таки Linux это больше уровень WinCE а не .NetMF. Ну плюс еще личные предпочтения :).
Лично я считаю, что использование .Net MF будет немного быстрее и дешевле чем Linux.
Основные требования — 32 разрядность и достаточное количество памяти.
По поводу переноса — если вы имеете ввиду как запустить TinyCLR на не прошитом микроконтроллере — то нужно шить так же как и любую другую программу.
Если вы имеете ввиду само приложение, то есть специальные программы для «разворачивания» приложений. Такую программу можно написать и самому. Visual Studio это делает автоматически при отладке.
Кстати, Microsoft буквально пару недель назад запустила новый проект на базе .Net MF — .NET Gadgeteer. Это что-то вроде конструктора, который можно программировать. По их мнению, этот проект должен служить образовательным целям.
2) Насчет портирования — я думаю, я напишу статью поподробнее.
3) Главное отличие — нет официальной поддержки XAML. То есть весь код пишется на C#. Ну и основные объекты можно пересчитать по пальцам. Правда, это не мешает делать хорошие интерфейсы и, на мой взгляд, это несет больше порядка. На базе .Net MF есть полноценная графическая оболочка — Pyxis 2.0. Она, кстати, тоже бесплатная.