Мне кажется, что главным преимуществом этой архитектуры являются то, что это одна их первых архитектур МК. Думаю что было бы неплохо, если не потрогать руками, то хотя бы знать эту архитектуру в общих чертах.
Я свое первое устройство отлаживал на этой плате. Не знаю, сколько она стоит — досталась бесплатно.
Работе с микроконтроллерами я учился в МЭИ на кафедре ВМСС. Нам читали курсы по 8051 а потом давали руками поиграть с PIC-ами. Во время летней практики даже сидел у нач.рука и паял программатор :)
На работе сначала был uPSD3234. Потом на LPC2138 сделал специальный модуль памяти, который до сих про входит в комплектацию продающихся устройств.
Сейчас работаю с LPC2478 и планирую переходить на LPC17XX.
Что касается самого процесса, то мы в своей работе перешли на .Net Micro Framework. Правда, не советую начинать с этого. Управляемый код скрывает тонкости работы с МК также как большой .Net для x86/x64 скрывает огромную проделанную работу на CPP.
Из-под кода C# вы ни как не сможете увидеть кода C++ как на «большом» .Net, так и на .Net MF. У VisualStudio свой канал отладки, определяемый портом. Однако если вы сумеете собрать исходники порта в проект для той или иной IDE, вы сможете дебагить его параллельно с отладкой C#. Такой схемой пользуемся мы, отлаживая параллельно управляемый код в C# в Visual Studio и неуправляемый в Keil uVision.
Сравнений точных нет, но управляемый код естественно работает немного медленнее.
Вся прелость в том, что, благодаря своей архитектуре, .Net MF не зависит от конкретной аппаратной платформы. Он предоставляет один и тот же API не зависимо от «железа». Разработчику приложений на C# все равно какая архитектура у процессора.
Это как .Net для Windows и Mono для Linux. ОC разные а API одно и тоже.
Список архитектур есть в этой статье.
На текущий момент .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).
Ну я все-таки не разработчик .Net MF. Мы просто сделали инструмент для портирования.
По поводу быстроты и удобства использования — то вопрос в том, как вы хотите его использовать. Вообще, .Net MF это быстро удобно и надежно, НО чтобы получить все это, нужно либо купить уже готовые платы, либо проделать большую и не самую простую работу чтобы сделать плату самому. Если вам просто на поиграть и поизучать — то берите и пользуйтесь готовыми платам. Если делать реальное устройство — то я бы выбрал второй вариант.
Ну, если быть предельно формальным, то тут не подходит ни первый ни второй термин, так как Library реализуют напрямую Feature. Library Category используются всего лишь для логической группировки.
А насчет realise, то вот перевод.
Вся юридическая и финансовая сторона тут.
.Net Micro Framework доступен под лицензией Apache 2.0, а значит вы можете использовать его бесплатно в любых целях.
На этот случай существует InterruptPort. Из любого GPIO пина .Net MF может сделать аналог внешнего прерывания. Вы можете настроить любой пин так, чтобы вам приходило вобытие OnInterrupt по фронту или срезу, по фронту и срезу или по уровням.
Вот пример:
public enum InterruptMode
{
InterruptNone, // The port is deactivated
InterruptEdgeLow, // falling edge (Change from high to low)
InterruptEdgeHigh, // rising edge (Change from low to high)
InterruptEdgeBoth, // both edges (Any state change)
InterruptEdgeLevelHigh, // high
InterruptEdgeLevelLow // low
}
public static void Main()
{
InterruptPort port = new InterruptPort(Cpu.Pin.GPIO_Pin3,false,Port.ResistorMode.PullDown,
Port.InterruptMode.InterruptEdgeBoth);
port.OnInterrupt += new NativeEventHandler(port_OnInterrupt);
Работе с микроконтроллерами я учился в МЭИ на кафедре ВМСС. Нам читали курсы по 8051 а потом давали руками поиграть с PIC-ами. Во время летней практики даже сидел у нач.рука и паял программатор :)
На работе сначала был uPSD3234. Потом на LPC2138 сделал специальный модуль памяти, который до сих про входит в комплектацию продающихся устройств.
Сейчас работаю с LPC2478 и планирую переходить на LPC17XX.
Что касается самого процесса, то мы в своей работе перешли на .Net Micro Framework. Правда, не советую начинать с этого. Управляемый код скрывает тонкости работы с МК также как большой .Net для x86/x64 скрывает огромную проделанную работу на CPP.
Сравнений точных нет, но управляемый код естественно работает немного медленнее.
Это как .Net для Windows и Mono для Linux. ОC разные а API одно и тоже.
На текущий момент .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).
По поводу быстроты и удобства использования — то вопрос в том, как вы хотите его использовать. Вообще, .Net MF это быстро удобно и надежно, НО чтобы получить все это, нужно либо купить уже готовые платы, либо проделать большую и не самую простую работу чтобы сделать плату самому. Если вам просто на поиграть и поизучать — то берите и пользуйтесь готовыми платам. Если делать реальное устройство — то я бы выбрал второй вариант.
А насчет realise, то вот перевод.
.Net Micro Framework доступен под лицензией Apache 2.0, а значит вы можете использовать его бесплатно в любых целях.
Если только кто-то специальную модификацию .Net MF сделает.
Вот пример:
public enum InterruptMode
{
InterruptNone, // The port is deactivated
InterruptEdgeLow, // falling edge (Change from high to low)
InterruptEdgeHigh, // rising edge (Change from low to high)
InterruptEdgeBoth, // both edges (Any state change)
InterruptEdgeLevelHigh, // high
InterruptEdgeLevelLow // low
}
public static void Main()
{
InterruptPort port = new InterruptPort(Cpu.Pin.GPIO_Pin3,false,Port.ResistorMode.PullDown,
Port.InterruptMode.InterruptEdgeBoth);
port.OnInterrupt += new NativeEventHandler(port_OnInterrupt);
Thread.Sleep(Timeout.Infinite);
}
private static void port_OnInterrupt(uint port,uint state,TimeSpan time)
{
Debug.Print("Pin=" + port + " State=" + state + " Time=" + time);
}
Пины, разрешенные для такого использования настраиваются как раз при портировании.
Я проверил, остальные прерывания при работе периферии скрыты на уровне HAL.
А вообще, вы можете дополнить библиотеку своими собственными драйверами.
Нас например не устраивает то, что можно работать только с 1 I2C. Мы собираемся добавить свой собственный класс для работы с I2C.