Comments 71
Главный вопрос: А зачем?!

Это же контроллер. И не так уж много ресурсов у SMT32Fx оказывается, когда пишешь что то более менее серьезное.
И, если, используешь контроллер по полной (DMA, прерывания и пр.), то зачастую приходится и листинги ассемблера смотреть что бы понять, в чем проблема и как gcc код скомпилил.
А тут еще какая то дополнительная прослойка (самодельный .NET), вносящая что то свое. Мало глюков в GCC. Еще глюки в левом софте.

используя всю мощь управляемого кода и Visual Studio

Ну ну…
Ну если только помигать лампочками…
Совершенно бредовый проект.
Да, это сложно. Чтобы писать нормально на .Net Micro Framework нужно ставить внешнюю RAM и FLASH.
Но это все вполне работоспособно. Я знаю успешный коммерческий проект, сделанный на этой технологии.

Если вам нужно сделать устройство со сложной логикой работы и поддержкой многих протоколов, а не просто помигать лампочками, то тут как раз все прелести «управляемого кода и Visual Studio» и пригодятся.

А помигать лампочками как раз проще в каком нибудь Arduino.
Наличие проекта на .NET говорит ни о чем. Скорее только о том, что где то кто то привык к .NET и имеет наработки на нем.

Если кому то нужна внешняя ОЗУ или FLASH к классическому микроконтроллеру — это означает скорее ошибку в выборе архитектуры/чипсета.
Линейки контроллеров весьма сбалансированы по своим параметрам и для типичных задач не требуют внешних расширений памяти.

Хотя ладно… не всегда ошибку. Причины могут быть разные (склад завален конкретными корпусами, плата уже разведена, разработчики есть только под .NET и т.д. и т.п.). Но все равно, в общем случае — это корявое решение.
По другому и не сказать.

А помигать лампочками как раз проще в каком нибудь Arduino.

Не говорите мне про Arduino. У меня это слово вызывает отвращение.
Вот именно, что мигать лампочками…

«Наличие проекта на .NET говорит ни о чем. Скорее только о том, что где то кто то привык к .NET и имеет наработки на нем.» В общем и целом согласен. Каждый выбирает то что он хочет. У любого подхода есть свои плюсы и минусы.

Моя цель не в том, чтобы убедить всех что нужно только .NET Micro Fraimwork, а чтобы показать что есть еще и такая технология и что можно ей пользоваться. Ну и рассказать как ее использовать.

С точки зрения коммерческой разработки, я тоже считаю Arduino просто игрушкой. Но, как платформа для обучения, он неплох. А вот с .NET Micro Fraimwork наоборот. Играть с и учиться с ним сложно, а для коммерческих проектов он может быть полезен.
Если разработчики дадут мне разрешение, то я напишу про этот коммерческий проект.
К более менее серьезному можно отнести порт на MCBSTM32F400. Он тоже входит в репозиторий.
Там есть сеть, USB, внешняя flash и т.д. С этим можно уже не только светодиодами мигать.

Еще есть Netduino — открытая аппаратная платформа для .NET Micro Framework

Кроме того, есть компания GHI Electronics весь бизнес которой построен на .NET Micro Fraimwork. На их сайте есть галерея проектов.
На текущий момент, он все еще требует определенных навыков и знаний


Прочел и задумался о той интересной эволюции взглядов, которая нынче происходит. То, что профессиональный инструмент требует «определенных навыков и знаний», подается как безусловный минус; очевидный смысл фразы в одобрении стремления к предельному упрощению всего и вся, пускай и в ущерб эффективности — только бы мозг не напрягать. Но помилуйте, это же не продукт для рядового пользователя, в котором стремление разгрузить извилины еще можно оправдать, а вполне себе инструмент разработки (даже то, насколько он хорош сам по себе — другой вопрос).

В целом мне очень жаль, что эта идеология, давно господствующая в заметной части прикладного программирования, теперь просачивается и в эмбед, причем не без подачи самих производителей.
Дело в том, что крупные компании кинувшись в след IoT пытаются расширить свое влияние в embedded и для этого стараются привлечь к своей технологии максимальную аудиторию. Те или иные наборы IoT софта для работы с микроконтроллерами есть и у Google и у Intel и у других менее масштабных фирм.

И все стремятся облегчить труд программиста, потому что embedded это действительно сложно. Лично я не вижу ничего плохого в этом. Те кто хочет напрячь мозг — и так будут его напрягать, зато появятся люди с другим складом ума, которые придумают много новых необычных устройств, так как создавать их станет гораздо легче.

Тут можно сравнить этот процесс с эволюцией PC. С каждым годом разработка уходит все дальше от железа, а когда то ведь писали все на ассемблере.
зато появятся люди с другим складом ума, которые придумают много новых необычных устройств, так как создавать их станет гораздо легче.


Не знаю, возможно в таком контексте это прозвучит излишне резко, но мне почему-то сразу вспомнилась известная идея про миллион обезъян с пишущими машинками…

Как минимум отмечу, что «необычный» и «полезный» — это разные категории, хотя иногда и пересекающиеся.
Это не эволюция. Скриптовые языки также стары как ассемблер.
Вся индустрия ПЛК держится на скриптовых движках уже десятки лет.
Но движки ПЛК по прежнему продаются за огромные деньги и не собираются дешеветь.

А смысл скриптов в том что они безопасны на микроконтроллерах без MMU.
Если в линуксе можно писать на нативном C-и и все равно иметь безопасный код, то для микроконтроллеров типа Cortex-M3,M4,M7,M8 остаются только скрипты.
И в этом их сила. Можно написать глючный скрипт, загрузить его по сети в микроконтроллер и этот скрипт не убъёт все остальные задачи RTOS на микроконтроллере.
А значит вы резко увеличиваете эффективность разработки, поскольку не тратите лишние минуты на подъем убитой среды исполнения после каждой итерации.
Вы, наверное, не совсем внимательно прочли мой комментарий. Я совершенно не выступаю против скриптовых языков самих по себе (хотя, кстати, я бы не назвал C# скриптовым языком); более того, я сам с удовольствием использую в проектах, например, C и Lua — получается где надо, гибко, а где надо — эффективно, а в целом в меру быстро и качественно.

Комментарий был даже не про C# сам по себе, о необходимости встраивания которого можно вести отдельные дебаты, а об общей тенденции к разработке средств, ориентированных прежде всего на дилетантов. В наши дни, как мы видим, уже звучат возгласы о том, что если средство требует навыков и знаний для того, чтобы его использовать, то это уже плохо.

А вообще, безопасность (встраиваемого) кода должна обеспечиваться в первую очередь квалификацией разработчика (я даже не называю его программистом, потому что тот, кто пишет для встраиваемых систем, всегда должен быть больше электронщиком), а после этого — тестированием. Тогда не потребуется спускать значительную часть производительности под костыли, которые призваны подчистить ошибки, проистекающие от низкой квалификации пишущего.
В некоторых случаях может быть дешевле создать костыли один раз и потом посадить кодировать беженцев из Пакистана, чем каждый раз тратиться на качественное тестирование и зарплаты квалифицированным специалистам, которым потом ещё попробуй замену найди, если кто-то решит уволиться.
Чистая правда. Печально то, что такой подход начинают считать нормой.
Как минимум отмечу, что «необычный» и «полезный» — это разные категории, хотя иногда и пересекающиеся.


Так в том то и дело! Все необычные идеи — это, как правило, прототипы. А полезные вещи делать будут как раз люди, напрягающие мозг, подхватившие хорошую идею )

Так же сейчас везде и происходит! Да и хороших embedded разработчиков станет тоже больше. Некоторым ведь и покопаться глубже захочится )
полезные вещи делать будут как раз люди, напрягающие мозг, подхватившие хорошую идею


Люди, напрягающие мозг, обычно не нуждаются в том, чтобы подхватывать чью-то идею — у них и своих хватает. Просто квалифицированный разработчик как правило не возьмется за 80% того, что дилетант вприпрыжку побежит реализовывать. Это оттого, что профессионал благодаря своему образованию и опыту видит возможные подводные камни еще до того, как они возникнут, и не горит желанием на них натыкаться, а сразу ищет обходные пути. Потому его рабочий процесс с виду протекает не так бурно.

В целом, мнение о том, что человек «с улицы» сможет сделать/придумать что-то такое, что недоступно профессионалу в данной области, является классическим проявлением эффекта Даннинга-Крюгера. На деле увеличение количества дилетантов в определенной области приводит только к усилению информационного шума, в результате чего он порой начинает скрывать что-то действительно стоящее.
То есть вы выступаете против популяризации технологий, так как это ведет к увеличению количества дилетантов? Но ведь профессионалы тоже с чего то начинали, будучи дилетантами.

За .NET Micro Fraework стоит огромный пласт сложного кода на C/C++. Без знания устройства портов сложно сделать что-то действительно стоящее. Это вполне может подтолкнуть человека к более глубокому изучению темы. Так что гипотетический студент, помигав светодиодами с помощью C#, захочет изучать направление дальше — вполне возможный сценарий. И не так важно что будет дальше: Arduino, Netduino или собственная плата. Даже пусть он поиграет и бросит все это, все-равно положительный эффект будет. Важно что человек научился чему-то новому.

Хабр для этого и существует, чтобы одним делиться информацией, а другим ее получать. Ну и для холивара тоже место найдется :) В дискуссиях и спорах рождается истина! :)
То есть вы выступаете против популяризации технологий, так как это ведет к увеличению количества дилетантов?


Я выступаю против популяризации технологий путем увеличения количества дилетантов.

Гипотетическому студенту, если он начинает с нуля, гораздо полезнее курс теоретических основ электротехники, чем мигание светодиодом с помощью фреймворка, которого он не понимает. Да и мигание светодиодом бывает разное. Мигание светодиодом на ассемблере — это обучение, ибо дает понятие об устройстве контроллера, строении периферийных блоков, организации памяти программ и данных, принципах исполнения кода и т.п. Мигание светодиодом на той же Ардуине — развлечение, т.к. для этого не требуется никакого понимания железа. Ну а про .NET я вообще не говорю.

Важно что человек научился чему-то новому.


В данном случае мы имеем дело с тем, что у человека создалась иллюзия того, что он чему-то научился, хотя он даже не прикоснулся к сути. Так и получаются люди, прикручивающие WiFi к Ардуино (и в силу этого уверенные в своей крутизне), но не знающие законов Кирхгофа.
В ваших словах есть своя правда. ТОЭ будет гораздо полезное мигания светодиодами. Как овсянка по утрам полезнее бутербродов. Но многие ли едят овсянку по своему желанию?
ТОЭ — это теория, причем достаточно нудная. А за полтора часа с нуля помигать светодиодами — это интересно. И вполне может сподвигнуть к изучению ТОЭ. Так и с овсянкой. Если в нее добавить, например, вишневого варенья, то ее вполне можно уже есть :)

Популяризация технологий методом «учиться 3 года чтобы прикрутить Wifi к Arduino и почувствовать себя по настоящему крутым, потому что теперь ты будешь понимать все: от каждого вольта в триггерах регистров до колебания частиц в антенне» не самая лучшая затея. Мы же с вами не в вузе преподаем сейчас.

4 года назад, когда я первый раз узнал о netmf, я бы очень обрадовался статье, рассказывающей как с этим всем работать.
ТОЭ — это теория, причем достаточно нудная.


Видимо, вам не повезло с преподавателем, ну или это просто не ваше. Мне в свое время на лекциях по теории цепей было интересно.

А за полтора часа с нуля помигать светодиодами — это интересно.


Правда, совершенно бесполезно. Более того, даже вредно, ибо создает ложное чувство понимания. Все должно приходить в свое время и после соответствующего количества усвоенного.

И вполне может сподвигнуть к изучению ТОЭ.… Мы же с вами не в вузе преподаем сейчас.


Вы сами-то в это верите?

Будете смеяться, но я таки преподаю в ВУЗе (по совместительству с основной работой, конечно), и могу сказать, что те, кому сама специальность неинтересна (а таких большинство), не подвигнутся даже такими граничащими с клоунадой мерами, а те, кто правда знают, куда и зачем пришли, не боятся и голого железа с ассемблером, более того, сами просят, чтобы я на занятиях копнул глубже.

учиться 3 года чтобы прикрутить Wifi к Arduino и почувствовать себя по настоящему крутым, потому что теперь ты будешь понимать все: от каждого вольта в триггерах регистров до колебания частиц в антенне


Снова неверный посыл и полное непонимание того, зачем же надо учиться, кстати, не три, а шесть лет в ВУЗе. Очень характерное, кстати, непонимание.

Так вот, в ВУЗе надо учиться не для того, чтобы подключать WiFi модуль к Arduino. В ВУЗе учатся те, кто будет делать не детские поделки из кубиков, а настоящие промышленные устройства, на которых держится современный мир. Например, электронику для автомобилей с соответствующими требованиями к исполнению и надежности. Ну а в свободное время такие люди могут попроектировать и Ардуино-кубики, чтобы массы забавлялись…
Я предполагал, что вы преподаете. Это видно по основательности и стилю ваших комментариев.

В мое время на инженера учились 5.5 лет, из которых 2 года были общеобразовательные предметы. Так что 3 года на специальность — это как раз срок обучения на втором высшем образовании.

На мой взгляд, в вас говорит закоренелый преподаватель, несколько оторванный от студентов. Причем это ни сколько не умоляет ваших достоинств. Как правило, такие люди дают наиболее фундаментальные знания.
Но, истории у всех разные.
Я, например, один из немногих на потоке, кто действительно работает по специальности. И все этапы, о которых вы говорите, испытал на себе. Но и мои сокурсники при этом тоже вполне неплохо устроились в жизни.
А еще, наоборот, я знаю хороших разработчиков, закончивших непрофильные ВУЗы.

Интерес к специальности появляется курсе на 4, когда ты понимаешь что и зачем. А до этого, куча информации на лекциях остается огромным объемом, который нужно впихнуть себе в голову, интересным только эпизодически. А еще тебе 20 лет и жизнь вокруг кипит…
Конечно есть на потоке несколько человек тех, кто «кто правда знают, куда и зачем пришли». Но, скажем так, это несколько «странные» люди.
в вас говорит закоренелый преподаватель


Не уверен, что у меня было время закоренеть. :) Я сам не так давно закончил, да и вообще преподаю, скажем так, в свободное время, скорее для души и из благодарности родному ВУЗу, «кто если не я», и т.д., и т.п.

Интерес к специальности появляется курсе на 4, когда ты понимаешь что и зачем.


Это катастрофа, на самом-то деле. Сначала должен появляться интерес к специальности, а потом человек должен выбирать соответствующий ВУЗ. Иначе смысл вообще идти в ВУЗ наугад? А так получается, что когда (хотя я бы сказал «если») пробуждается интерес к специальности, необходимые курсы уже прошли мимо.

Конечно есть на потоке несколько человек тех, кто «кто правда знают, куда и зачем пришли». Но, скажем так, это несколько «странные» люди.


Порой мне приходит мысль, что всех остальных, не «странных», стоило бы отчислить для пользы дела — это позволило бы лучше учить тех троих человек, которые пришли не зря. В такие моменты я обычно усилием воли смиряю перфекционизм и ставлю зачет за такую работу, за которую по справедливости стоило бы отчислить…

Вообще, если посмотреть на дело по-честному, это просто в голову не умещается — «странными» считаются как раз те, кто пришел по адресу и достоин учиться там, куда поступил. Не абсурд ли? Может остальным все же стоит уйти в какие-то другие места? Тем не менее, по факту это сейчас норма…

А еще тебе 20 лет и жизнь вокруг кипит…


Я пошел в местный политех потому, что к одиннадцатому классу сочинял схемы и программировал контроллеры на ассемблере и Си, а на эту «кипящую жизнь» мне было как-то плевать, я хотел совсем другого. По наивности я ожидал, что уж там-то (в отличие от школы) я встречу единомышленников, вообще, некоторое подобие радиофорума… Ну, вы понимаете, как круто я обломился. Так что я, увы, понимаю, о чем вы. Только я считаю это не нормой, а большой бедой нашего образования. Увлеченные одиночки вынуждены выживать даже в тех местах, которые, казалось бы, созданы специально для них. Грустно, когда тому, кто называется студентом-радиотехником, интереснее КВН и посиделки в общаге, чем ТОЭ и курс общей физики. КВН это, наверное, тоже хорошо; однако, может быть, тем, кто им до такой степени интересуется, стоит идти в ГИТИС?
У всех своя дорога.
Наверное, лет 30-40 назад вы бы встретили единомышленников практически в любом техническом вузе, но мир слишком быстро меняется.
Я в свои 17 лет писал только бейсике и ни о каких схемах и контроллерах не знал и в помине. Шел в ВУЗ скорее интуитивно. Лично мне с самого первого курса не хватало понимания схемы образования. Нас просто пихали знаниями, не объясняя зачем. Понятно стало уже потом…

Мне кажется что 90% студентов не очень понимают куда именно они попали и чему конкретно их будут учить. И так было всегда.

Наверное вы правы, насчет того, что это серьезная проблема образования. Но уровни вузов везде разные. Я не знаю, что вы закончили, но наверное в МГУ или в Бауманке вы бы нашли единомышленников, не говоря уж о зарубежных вузах…

Но все таки ВУЗ это далеко не только учеба. В какой-то из статей известной когда-то «Компьютерры» я прочитал интервью, в котором была высказана идея, что «высшее образование делает человека сложнее и именно в этом его цель». ВУЗ должен развивать, причем в разных направлениях. Это и музыка, и КВН, и посиделки в общаге, и спорт, и самое главное, конечно, само образование. Но все это единое целое, неделимое.

ВУЗ дает возможность понять кто ты и дает выбрать свою дорогу. А уж кто и как воспользуется этим выбором, зависит только от самого человека.
Впрочем, мы с вами совсем далеко ушли от темы статьи. Я с удовольствием подискутировал бы с вам за чашкой чая!
Повторяю свой вопрос…
Сколько ресурсов требует / потребляет описанное в статье приложение?
Бинарник CLR от GCC — 316 кб. От RealView — 297 кб. По потреблению RAM сказать пока не могу, не смотрел. Как посмотрю — напишу вам.
ещё просьба замерить быстродейстсвие на простой типовой алгоритмической задаче и сравнить с gcc
например БИХ фильтр с длинной в 10 выборок, и замерить в микросекундах время фильтрации 8 тысяч выборок на C и C#.

например такой код: http://pastebin.com/qWWBqEWk
настройки винфильтра такие: http://prntscr.com/98zddd
Замерил на .NET Micro Framework.

Использовал вот такой код:

public static class WinFilterеTest
    {
        private const int NCoef = 10;
        private const int DCgain = 8192;

        //__int16 iir(__int16 NewSample)
        public static short iir(short NewSample)
        {
            short[] ACoef = new short[NCoef + 1] {
               93,
              930,
             4186,
            11163,
            19536,
            23443,
            19536,
            11163,
             4186,
              930,
               93
            };

            short[] BCoef = new short[NCoef + 1] {
             1024,
            -5106,
            12222,
            -18168,
            18404,
            -13195,
             6751,
            -2425,
              584,
              -85,
                5
            };

            int[] y = new int[NCoef + 1]; //output samples
                                          //Warning!!!!!! This variable should be signed (input sample width + Coefs width + 10 )-bit width to avoid saturation.

            int[] x = new int[NCoef + 1]; //input samples
            int n;

            //shift the old samples
            for (n = NCoef; n > 0; n--)
            {
                x[n] = x[n - 1];
                y[n] = y[n - 1];
            }

            //Calculate the new output
            x[0] = NewSample;
            y[0] = ACoef[0] * x[0];
            for (n = 1; n <= NCoef; n++)
                y[0] += ACoef[n] * x[n] - BCoef[n] * y[n];

            y[0] /= BCoef[0];

            return (short)(y[0] / DCgain);
        }
    }


Вызов кода:

    public class Program
    {
        public static void Main()
        {

            for (int j = 0; j < 10; j++)
            {
                short[] input = new short[8000];
                short[] output = new short[8000];

                for (int i = 0; i < 8000; i++)
                {
                    input[i] = (short) i;
                }

                var start = DateTime.Now;
                for (int i = 0; i < 8000; i++)
                {
                    output[i] = WinFilterеTest.iir(input[i]);
                }
                var stop = DateTime.Now;

                var delta = stop - start;

                Debug.Print(delta.ToString());
            }
}


Время выполнения на эмуляторе под Windows (i5-3317U 1,7GHz) около 2.2 секунд.
Время выполнения на STN32F4Discovery около 6.2 секунд.

Скоро замеряю через Keil. С GCC мне сейчас сложно замерять. Буду рад, если кто-то поможет. Код выложу.
6.2 секунд на каждый из 10 блоков по 8000 выборок? Или это общее время на на все 10 блоков?
Это общее время на вот это:

for (int i = 0; i < 8000; i++)
{
      output[i] = WinFilterеTest.iir(input[i]);
}


То есть на каждый блок по 8000 выборок
В Keil замерил вот такой код:

#define NCoef 10
#define DCgain 8192

#define __int16 short
#define __int32 int

__int16 iir(__int16 NewSample) {
    __int16 ACoef[NCoef+1] = {
           93,
          930,
         4186,
        11163,
        19536,
        23443,
        19536,
        11163,
         4186,
          930,
           93
    };

    __int16 BCoef[NCoef+1] = {
         1024,
        -5106,
        12222,
        -18168,
        18404,
        -13195,
         6751,
        -2425,
          584,
          -85,
            5
    };

    static __int32 y[NCoef+1]; //output samples
    //Warning!!!!!! This variable should be signed (input sample width + Coefs width + 10 )-bit width to avoid saturation.

    static __int16 x[NCoef+1]; //input samples
    int n;

    //shift the old samples
    for(n=NCoef; n>0; n--) {
       x[n] = x[n-1];
       y[n] = y[n-1];
    }

    //Calculate the new output
    x[0] = NewSample;
    y[0] = ACoef[0] * x[0];
    for(n=1; n<=NCoef; n++)
        y[0] += ACoef[n] * x[n] - BCoef[n] * y[n];

    y[0] /= BCoef[0];
    
    return y[0] / DCgain;
}

short input[8000];
short output[8000];

int main(void)
{
 int i,j;
	for (j = 0; j < 10; j++)
	{		

			for (i = 0; i < 8000; i++)
			{
					input[i] = (short) i;
			}

			for (i = 0; i < 8000; i++)
			{
					output[i] = iir(input[i]);
			}		
	}
  
  /* Infinite loop */
  while (1)
  {
  }
}


Результат одного блока на 8000 выборок примерно 0.55 секунды.
у меня другие результаты:
проц: STM32F405RG
частота: 160Mhz
компилятор: GCC 2013q3 (https://launchpad.net/gcc-arm-embedded)
среда: Coocox IDE 2013 года
вынес в конст: const __int16 ACoef[NCoef+1], аналогично и BCoef
компиляция в режиме инструкций M4, SIMD, -O2 (это сильная, но не макс оптимизация)

Результат одного блока на 8000 выборок примерно: 0.022сек

может Вы забыли включить -О2 и симд оптимизацию? та что умножает 2 пары чисел с накоплением
в остальном у меня всё аналогично, input и output так же глобальными
код взял Ваш
только чуток допилил ACoef и BCoef до констант, без них const чуток медленее на пару тыщь тактов для одного блока
Возможно частота другая и оптимизация, но сути это не меняет.

Я думаю стоит ориентироваться на то, что .Net Micro Framework работает на 2-3 порядка медленнее, в зависимости от оптимизации. Но он и не ориентирован на вычисления.

Для примера вот тут сравнивается C# и C++ на обычном компьютере.
«Самая медленная(из рассмотренных конечно) реализация на С#, медленнее самой медленной С++ реализации примерно в 4 раза»
Я так понимаю там средняя разница примерно в 10 раз.
теоритический предел 0.010сек (если по подсчёту операций)
так что мой результат ближе.
но даже случай с кейл на голову разгромил вывод такой для меня: звук не отфильтруешь даже низкого качества т.к. на один блок больше 1 сек. А кейл показал типичный результат компилятора без оптимизации: сейчас повторил на своём gcc — тоже чуть больше полу секунды.

Но мне C# нравится и наработками в области алгоритмов, и хорошей объектной моделью языка и думаю что он идеально применим в области например умного дома, промышленного управления и в прочих низкоскоростных вещах типа автомобильной и страховой телематики с мед гаджетами.

И думаю Си шарп в будущем ускорят и есть куда: я например делал на авр эмулятор 8051, смог добиться полной эмуляции его инструкций в реалтайме: разница в быстродействии выходила в 24 раза, на одну аппаратную инструкцию 51ого МК, выходило 24 инструкции АРМ. Сделал в виде таблицы функций 51ого на все 256 шт, каждая функция буквально пара асм инструкций на АРМе, кроме работы с переферией.
Соответственно, можно сделать вывод, что сам код примерно на порядок (12 раз) быстрее исполняется в native чем на .Net MicroFraimwork.
В документации к версии 4.3 указаны следующие минимальные требования: 64 Kb of RAM and 256 Kb of flash memory
Думаю что принципиально тут ничего не поменялось. Все зависит от набора периферии, поддерживаемой портом.
Как раз после ответа, мол, «4.4 сильно отличается от 4.3» я и начал повторять свой вопрос. Новая версия позволяет компилировать/транслировать C# напрямую в машинный код (грубо говоря, нету виртуальной машины). Это как нативные сборки UWP на платформе Windows 10.
Не совсем так. .NET Micro Framework состоит из 2х частей. Трансляцией C# в машинный код без использования портов занимается llilum. Но это пока экспериментальный проект.
В статье же речь идет о netmf-interpreter. Это прямой наследник версии 4.3, хотя и сильно отличающийся по составу дистрибутива.
кто по задумке разработчиков должен делать порты под разные микроконтроллеры: сами разработчики фреймворка или пользователи (программисты)?

порт делается под МК или под плату?
Порты может делать кто угодно, но как правило их делают пользователи. .NET Micro Framework изначально был платным и, видимо, подразумевалось что порт будут делать производители железа.

Порт делается под конкретную плату, но разные порты могут использовать один и тот же код, связанный с микрокнтроллером. В версии 4.4 входит код для STM32F4, на его базе сделано 2 порта: STM32F4Discovery и MCBSTM32F400.

Порты могут содержать разную периферию, при этом процессор моет быть один и тот же. Плата может быть с дисплеем или без, с сетью или без, с SD карточкой или без и т.д.
«как правило их делают пользователи»
ну пока я на гитхабе вижу только 2 порта под мк))

1. а есть ли документация или некая памятка по созданию портов?
2. известно ли о планах разработчиков по созданию некоего набора портов?
Дело в том, что с переездом на GitHub разработчики переделали дистрибутив, убрав оттуда «все лишнее».
Раньше, netmf состоял из 2х частей: client — все что связано с разработкой приложений для .NET Micro Framework и Porting Kit — для разработки портов. Сейчас все это объединено. При этом за бортом остались порты под старые ARM7 процессоры (NXP LPC22XX,LPC24XX Renesas SH72XX и тд.) и много полезного софта и документации для работы с портами.

1) По документации вы можете начать отсюда. Это ссылка на документы к версии 4.3. Они достаточно скудные, но лучше чем ничего. А вот тут уже достаточно подробное описание.

2) Разработчики порты не делают. Сейчас они очень активно работают над llilum. Это вторая ветка .NET Micro Fraimork, основанная на совершенно новом подходе. Тут идея в том, что код сначала компилируется в Microsoft Intermediate Language (MSIL, предшественник CLI), а затем в Intermediate representation (IR). IR код подвергается существенной оптимизации и из него уже получается машинный код. По сути это немного измененная LLVM.

То есть нет никаких портов, а приложение компилируется сразу в ассемблерный код.
«The STM32 (Cortex M3) Port was provided by Cuno Pfister and Beat Heeb at Oberon Microsystems.» — анонс версии netmf 4.2
История этих портов уходит аж в 2011 год :)
Спасибо за статьи.

Правильно ли я понял, что сборка под ARM производится скриптами msbuild, а не средствами IDE Keil?
Т.е. непосредственно под Keil нет проекта для сборки?
И вообще нет ничего такого где можно было бы обозреть проект для сборки .NET FM в виде структурированного дерева папок и исходников.
Понять состав проекта можно только изучая скрипты msbuild?

Почитайте эту документацию. Она дает общее представление о том, что такое порты и как они устроены.

В 2011 году я и мой коллега задавались точно такими же вопросами. В итоге мы сделали свою IDE для разработки портов — PKStudio. Она умела делать следующее:
— Редактор кода
— Компиляция из программы
— Переход к ошибкам
— Анализ связей компонентов в виде диаграмм
— Полное преобразование проектов в компилируемые и линкуемые проекты Keil
— Просмотр и в будующем редактирование:
* Libraries
* LibraryCategories
* Features
* Processors
* Assemblies
— Просмотр Solutions
— Добавление и редактирование проектов
— Верификация Компонентов:
* Проверка ссылок
* Проверка уникальности GIUD
— Поиск компонентов по имени

Вот несколько скриншотов:





Она даже вошла в ветку comm дистрибутива 4.2

Но сейчас ее нет в дистрибутиве.

Вообще я планировал подправить PKStudio для работы с версией 4.4 и написать о ней статью, заодно рассказать об устройстве портов. Но это будет наверное уже в январе.

На основе какого-то фреймворка делали PKStudio?
А какой компилятор там используется?

Т.е. я прав, что нет обозревателя для проекта .NET FM?
Сделано все на C# и WinForms. Для построения используется тот же MSBuild, а компилятор настраивается переменными окружения. То есть процесс тот же, что и в статье, просто все это визуализировано.

Стандартного обозревателя нет, но с помощью PKStudio можно сконвертировать порт в проект для Keil, который можно скомпилировать и даже отлаживать на микроконтроллерею
Все скомпилил и загрузил, но ссылка на USB драйвер вроде битая.
Мой Windows 7 нашел драйвер, но показывает его как WinUsB и MFDeploy.exe не видит плату.

Не могли бы поправить ссылку.
Скачайте по первой найденной ссылке в гугле. Так должно работать. А я пока попробую найти прямую рабочую ссылку.
Что-то не то.
Вот мое окно в ST-LINK


Тут и загрузочный образ больше и начальные вектора совсем другие чем в вашей статье.
Компилировал KEIL ARM MDK 5.06

Причем все качал сегодня. И файл BuildSignerSpotBuild.csproj править не пришлось. Уже был исправлен.
Попробуйте скачать и залить скомпилированные мной hex файлы.
Если все отработает — будем разбираться что не так скомпилировалось. А если нет, то значит что-то вы не так подключаете.
Получилось.
Делал так.
-Загрузил вашу прошивку. Не помогло.
-Тогда снес драйвер WinUsb в адвансед режиме со стиранием файлов драйвера. И снова воткнул разъем USB в Discovery.
-Тогда появился совсем другой драйвер и в другой ветке дивайсов. Вот такой:

-Тогда загрузил опять свою прошивку. Плата обнаружилась.
Остальное тоже загрузилось после этого.
Пушу приложение.
У меня на Windows 10 на одной из машин тоже были проблемы с драйвером. Плата в системе была видна, но MFDeploy.exe ее не видел. А на других все работало без проблем. Мир не идеален :)
Все написал и запустил приложение.
Потрясающе просто и быстро.
Arduino в подметки не годится.

Вот такая программа

выдавала вот такой меандр ():


Для скрипта очень неплохо.
Скачивал как описано в вашей статье. Сначала Fork, потом клонировал на комп.
Но я пользуюсь программой GitHub Desktop
Вопрос к автору, вы с ошибкой MMP: error MMP0000: CLR_E_FAIL не сталкивались?
Полный текст
MMP : error MMP0000: CLR_E_FAIL [c:\root\NETMF\netmf-interpreter\Solutions\STM32F4DISCOVERY\TinyCLR\TinyCLR.proj] c:\root\NETMF\netmf-interpreter\tools\targets\Microsoft.SPOT.System.GCC.targets(349,5): error MSB3073: выход из команды "c:\root\NETMF\netmf-interpreter\BuildOutput\public\Release\Server\dll\MetaDataProcessor.exe -sign_file c:\root\NETMF\netmf-interpreter\BuildOutput\THUMB2FP\GCC4.9\le\FLASH\release\STM32F4DISCOVERY\bin\tinyclr.bin\ER_DAT c:\root\NETMF\netmf-interpreter\t ools\bin\tinybooter_private_key.bin c:\root\NETMF\netmf-interpreter\BuildOutput\THUMB2FP\GCC4.9\le\FLASH\release\STM32F4DISCOVERY\bin\tinyclr.hex\ER_DAT.sig" с кодом 10. [c:\root\NETMF\netmf-interpreter\Solutions\STM32F4DISCOVERY\TinyCLR\TinyCLR.proj]
По моему сталкивался. Эта ошибка говорит о том, что не удается подписать файл ...bin\tinyclr.bin\ER_DAT
Проблема была в том, что его размер равен 0. В моем случае эта ошибка никак не влияла на дальнейшие действия. Вы можете использовать и не подписанные файлы при прошивке платы.

А еще попробуйте сделать «чистую компиляцию»: сотрите всю папку BuildOutput. Мне помогало, так как ошибка возникала, если сначала собрать SDK, а потом уже собирать прошивки для плат.

И еще, можно попробовать получить свежую версию репозитория с GitHub. Я где то видел на форуме ветку про эту ошибку, по этому эта проблема может быть уже исправлена.
Вроде бы удалял уже BuildOutput, но на всякий проверю еще раз. В моем случае ошибка блокирует сборку файла <repo folder>\BuildOutput\THUMB2FP\GCC4.9\le\FLASH\release\STM32F4DISCOVERY\bin\Tinybooter.hex .
Попутно скачаем 2 репозиторий.
Спасибо огромное за статью.
Мне кажется, на такую популярную плату, как discovery, установка должна происходить за пару секунд в аторежиме, ведь целевая аудитория netmf как раз не сосем те люди, которые будут играться с gcc.
Но будем надеятся, что с открытием сырцов ситуация изменится к лучшему. Для мака уже есть возможность работы в mono, может скоро в linux завезут.
Only those users with full accounts are able to leave comments. Log in, please.