Обзор Бета версии .NET Micro Framework 4.2

    Сегодня на Хабре уже была новость о выходе новой Beta версии .Net Micro Framework. Я хочу подробнее рассказать о новых возможностях и нашем участии в выпуске этой версии.

    Новость о выходе беты можно прочитать в блоге лидера команды разработки .Net MF Колина Миллера. Особенностью этого релиза является то, что, помимо исправлений и дополнений, сделанных самой Microsoft, в него вошли несколько компонентов, созданных членами .Net MF Community.

    Главные нововведения .Net Micro Framework 4.2 Beta следующие:
    • Поддержка удаленного обновления ПО (MFUpdate)
    • Работа с АЦП/ЦАП (A/D conversion)
    • Поддержка VB.NET
    • Оптимизация IL кода
    Со стороны комьюнити вклад сделан следующий:
    • Julius Friedman при поддержке Michael Schwarz реализовали StringBuilder.
    • Valer Bocan помог в реализации Simple Network Time Protocol (SNTP)
    • Мы с коллегой, Игорем Киселевым, добавили специальную IDE для разработки новых портов – PKStudio.

    Немного поподробнее о каждом нововведении:

    MFUpdate:
    Новый функционал, позволяющий удобно удаленно обновлять ПО .Net Micro Framework. Хорошей новостью является то, что этот механизм позволяет использовать новые криптографические примитивы. Разработчики теперь могут еще и обеспечить криптографическую защиту обновлений.

    A/D conversion:
    Работа с АЦП/ЦАП спроектирована специально с учетом требований к производительности. Поддерживается до 8 каналов.

    VB.NET:
    Код теперь можно писать не только на C# но и на VB. Были добавлены соответствующие шаблоны для Visual Studio. (Для Visual Studio Express поддерживается пока только C#)

    StringBuilder:
    Реализация StringBuilder полностью соответствует «большому» .NET. Это первый шаг к реализации RegEx, которая будет добавлена немного позднее.

    SNTP:
    Новая реализация SNTP может быть использована с lwIP или любым другим стеком.

    PKStudio:
    PKStudio собирает в одну графическую IDE все необходимые для разработки портов функции. При разработке PKStudio мы старались как можно больше упростить процесс создания портов, используя собственный опыт написания порта. Она позволяет удобно работать со всеми компонентами Porting Kit: искать, анализировать взаимные связи, создавать и модифицировать компоненты, компилировать проекты и т.д. Важной функцией является возможность преобразования проектов Porting Kit в полностью работоспособные проекты uVision от Keil. Так как на текущий момент PKStudio до конца еще не отлажена, то она доступна только в составе дистрибутива исходного кода на Codeplex.

    Таким образом .Net Micro Framework активно развивается. Комьюнити понемногу разрастается, а платформа становится все популярнее.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 18
    • +1
      Спасибо за обзор.
      Особо этой сферой деятельности не интересуюсь, но в целом, что касается .NET — интересуюсь.
      • 0
        Интересно было бы узнать у вас, как у разработчика на .NET Micro Framework. На сколько всё удобно, быстро и надёжно. Стоит ли уже использовать или нужно подождать?
        • 0
          Ну я все-таки не разработчик .Net MF. Мы просто сделали инструмент для портирования.
          По поводу быстроты и удобства использования — то вопрос в том, как вы хотите его использовать. Вообще, .Net MF это быстро удобно и надежно, НО чтобы получить все это, нужно либо купить уже готовые платы, либо проделать большую и не самую простую работу чтобы сделать плату самому. Если вам просто на поиграть и поизучать — то берите и пользуйтесь готовыми платам. Если делать реальное устройство — то я бы выбрал второй вариант.
        • 0
          А можно еще перечислить, для программинга _КАКИХ_ микроконтроллеров? Потому как тот же АЦП в Атмелевской меге и Арме, к примеру — это две большие разницы.
          • 0
            Почитайте первый пост автора.
            • +1
              Вся прелость в том, что, благодаря своей архитектуре, .Net MF не зависит от конкретной аппаратной платформы. Он предоставляет один и тот же API не зависимо от «железа». Разработчику приложений на C# все равно какая архитектура у процессора.
              Это как .Net для Windows и Mono для Linux. ОC разные а API одно и тоже.
            • 0
              Мне нравится .Net, но мне намного более интересно было бы если бы можно было поменять VHDL/Verilog на C# чтобы программировать FPGA.
              • +2
                Это было бы здорово, но на текущий момент, к сожалению, нереально
                • 0
                  Интересно, реально ли написать кросскомпилятор…
              • 0
                Так все таки и не нашел какие процессоры сейчас поддерживаются. Я так понял это ARM7 а кортексы? И какие? M0 потянет? Тяжело ли писать драйвер HAL? Есть ли какое нить сравнение с Keil/IAR/gcc/g++? Можно ли вести отладку с помощью JTAG?
                • +1
                  Список архитектур есть в этой статье.
                  На текущий момент .NET Micro Framework может быть запущен на процессорах таких архитектур, как ARM7, ARM9, Cortex, XScale, ARC и ADI Blackfin. CortexM0 вполне потянет.

                  По поводу создания HAL я писал в вышеуказанной статье. Писать не тяжелее любого другого native проекта для микроконтроллеров, вот только объем работы большой. Вообще говоря, программируя любой микроконтроллер, вам все равно в той или иной степени нужно писать те же самые драйвера.

                  Сравнения… Сравните разработку MFC и .Net — тут тоже самое.

                  А отладку чего вы хотите вести? Приложения, написанные на C# отлаживаются прямо из Visual Studio. Порт можно отлаживать в Keil по JTAG, но для этого нужно сконвертировать проект для uVision. Наша PKStudio позволяет это сделать (правда она до конца еще не доделана, по этому возможны глюки). Наверное можно было бы наладить отладку и из других сред, но нужно создавать проекты для этих сред из кучи разрозненных исходников (в Porting Kit для построения используется MSBuild).
                  • 0
                    По JTAG хотелось бы поставить брейкпойнт прямо в студии и он остановил программу в контроллере в это время и посмотреть чему там равны переменные в тот или иной момент. Keil вообще может графики строить по переменным из контроллера но цена его не разумна, а вы предлагаете в нем отлаживать =). И как он кстати там отлаживается прямо по C# коду?
                    А сравнение я тут скорей какой нить бенчмарк имел ввиду, по сложности это понятно дело чудок облегчает работу, но никак не лишает обязанности знать всю подноготную того или иного камня.
                    • 0
                      Из-под кода C# вы ни как не сможете увидеть кода C++ как на «большом» .Net, так и на .Net MF. У VisualStudio свой канал отладки, определяемый портом. Однако если вы сумеете собрать исходники порта в проект для той или иной IDE, вы сможете дебагить его параллельно с отладкой C#. Такой схемой пользуемся мы, отлаживая параллельно управляемый код в C# в Visual Studio и неуправляемый в Keil uVision.
                      Сравнений точных нет, но управляемый код естественно работает немного медленнее.
                      • +1
                        Да. Спасибо, теперь понял как это все выглядит.
                        В двух средах что то делать одновременно на мой взгляд тот еще гемор.
                        Для себя пока оставлю gcc/g++ для разработки под embeded.
                        Я тут все присматриваюсь на язык vala, вот бы кто нить сообразил порт для embeded устройств.
                        • 0
                          Не туда написал… Прочитайте пожалуйста мой комментарий ниже :)
                • 0
                  Правильно ли я понял что vala это чтото типа C#, но он компилируется не в псевдо-код, а в платформо зависимый ассемблерный код?
                  • +1
                    Да, там путь примерно следующий:
                    VALA транслируется в исходник на си (не си++) с помощью какой нибудь обьектной нотации, или вообще без нее. Есть glib (gobject), dova.
                    А потом все это компилится с ппомощью gcc. Соответственно нет сборщика мусора, есть только подсчет ссылок.
                    • 0
                      Ну, теоретически, наверное можно подсунуть вместо gcc x86 gcc для ARM…

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