.Net Micro Framework — технология, позволяющая писать приложения для микроконтроллеров используя всю мощь управляемого кода и Visual Studio. Она существует давно и сейчас переживает второе рождение. Вокруг нее сформирован open-source проект, который не так давно переехал на GitHub. Однако пока еще это не “коробочный” продукт. Работа с .Net Micro Framework требует определенных навыков. В прошлый раз я писал про то, как создать и запустить простое ”Hello world” приложение на эмуляторе для Windows. Сейчас речь пойдет о том, как поработать с .Net Micro Framework на настоящем “железе” — отладочной плате STM32F4Discovery.
Плата достаточно распространена и может быть приобретена, например, тут. Начиная с версии 4.4 порт для этой платы входит в дистрибутив netmf-interpreter. Ранее он существовал как отдельный проект.
В интернете и, в частности, на хабре можно найти материалы про запуск .Net Micro Framework на этой плате, но во-первых в них говорится о версии 4.3, а во-вторых там используются уже готовая сборка. Я же расскажу о том, как скомпилировать и запустить на STM32F4Discovery .Net Micro Framework версии 4.4 во всех подробностях. Статья будет длинная, так как нужно будет исправить несколько ошибок в дистрибутиве и скачать и установить несколько утилит и драйверов.
Подготовка к компиляции
Дистрибутив
В первую очередь нужно иметь сам дистрибутив.
Репозиторий находится тут. Можно скачать его как zip-архив, а можно получить, используя git. Инструкции на английском языке о том, как получить репозиторий и собрать из него установочные файлы, можно посмотреть тут. На основе этих инструкций и написана статья. Версии репозитория, связанные с конкретными релизами, можно скачать в zip-архивах тут.
Чтобы получить репозиторий с помощью git, нужно сделать следующее:
- Создать публичную копию на вашем аккаунте на серверах GitHub сделав fork. Все pull-запросы должны идти с публичного GitHub репозитория.
- Получить локальную копию репозитория, используя clone. Например, вот так:
git clone https://github.com/<your GitHub ID>/netmf-interpreter.git
Важно: При выборе пути для локального репозитория нужно обязательно сделать хотя бы одну родительскую папку. Например,D:\NETMF\repo, гдеrepo— папка для репозитория. Это требуется для его правильной сборки.
- Настроить локальный репозиторий, как Upstream. Это позволит получать с помощью pull изменения с последних официальных коммитов и разбирать все несоответствия при получении кода локально до выполнения запроса pull. Для настройки Upstream можно использовать следующую команду:
git remote add upstream https://github.com/NETMF/netmf-interpreter.git
Важно: Требования к локальному пути (должна быть хотя бы одна родительская папка — см. п 2 работы с git) актуальны и при распаковке репозитория из архива.
К сожалению, релиз .NET Micro Framework v4.4 Release To Web (RTW) содержит ошибки, которые не позволяют сразу собрать установочные файлы из репозитория. Однако, эти ошибки можно исправить, и далее я расскажу как это сделать.
После того, как репозиторий тем или иным способом оказался скопирован в локальную папку, нужно сделать следующее:
- Скачать binary tools zip файл. Этот файл содержит утилиты, необходимые для сборки как установочных файлов, так и “портов” для устройств. В будущем планируется отказаться от этих утилит, но пока еще они нужны.
- Разархивировать содержимое binary tools zip-файла в родительскую папку репозитория. Например для пути
D:\NETMF\repo, гдеrepo— папка для репозитория, папкиbinиtoolsдолжны оказаться в папкеD:\NETMF. - Важно: В файле
<repo folder>\Framework\Tools\BuildTasksInternal\BuildSigner\BuildSignerSpotBuild.csproj
в строке 37 нужно заменить
<HintPath>$(MSBuildProgramFiles32)\Microsoft Internal\Codesign.Submitter\CODESIGN.Submitter.dll</HintPath>
на
<HintPath>$(SPOROOT)\tools\x86\CODESIGN\CODESIGN.Submitter.dll</HintPath>
Это исправление первой ошибки. Без такой замены собрать репозиторий не удастся. Как было сказано выше, .Net Micro Framework это open source проект и, к сожалению, он сталкивается с теми же проблемами, что и другие открытые проекты. Это исправление необходимо только для релиза .NET Micro Framework v4.4 Release To Web (RTW). В дальнейшем репозиторий уже будет содержать поправленные файлы. Про эту проблему можно почитать тут. - Нужно скачать библиотеку CMSIS и положить ее в папку
<repo folder>\СMSIS.Где ее брать и какая именно версия нужна, написано в файле<repo folder>\СMSIS\ReadMe.md.
CMSIS расшифровывается как Cortex Microcontroller Software Interface Standart. Это не зависящая от конкретного производителя библиотека для работы с ядром Cortex-M, поставляемая и поддерживаемая разработчиками ядра — компанией ARM. Использование этой библиотеки позволяет существенно упростить создание “портов” на разные микроконтроллеры разных производителей.
В случае с версией .Net Micro Framework 4.4 нужно скачать CMSIS не ниже версии 4.3. Библиотека поставляется в виде zip-архива (CMSIS-SP-00300-r4p3-00rel0.zip). Ее можно скачать на сайте ARM. Содержимое архива нужно положить в папку<repo folder>\СMSIS. - Далее нужно установить .Net Micro Framework Cryptographic Libraries. Эти библиотеки используются для подписи сборок, которые будут исполняться на микроконтроллерах. Для работы нужны только исполняемые файлы криптографической библиотеки. Но, при желании, можно узнать как она устроена, так как можно посмотреть и исходные коды.
Библиотеки доступны в виде установочного msi файла. Я рекомендую установить их в любую удобную папку (далее будем называть ее<crypto install folder>), а затем копировать их в корень каждого репозитория, напримерD:\NETMF\repoиD:\NETMF\repo_master.
Дистрибутив представляет собой сложную структуру с огромным количеством перекрестных ссылок. Объединено все это с помощью проекта для MSBuild. Файлы проекта внешне выглядят как знакомые всем sln и proj файлы для Visual Studio, однако внутри у них более сложная структура. Именно поэтому использовать Visual Studio для сборки не получится.
Подробнее о составных частях и связях внутри дистрибутива я расскажу в следующих статьях, а сейчас нужно знать, что порт для STM3F4Discovery находится в папке
<repo folder>\Solutions\STM32F4DISCOVERY
а собранные бинарные и hex файлы появятся в папке
<repo folder>\BuildOutput
Visual Studio
MSBuild входит в состав Visual Studio. В документации к .netmf interpreter 4.4 указано, что поддерживаются редакции Visual Studio 2015 Community, Pro и Ultimate, так что для успешной сборки порта нужно установить одну из них.
Компилятор ARM
Далее нужен компилятор для ARM. Предусмотрена работа с двумя компиляторами:
Компилятор RealView входит в состав средства разработки Keil MDK. Бесплатная версия имеет ограничение в 32 кб кода, однако порт имеет больший объем, поэтому обязательно нужна лицензия, например 7-Day MDK-Professional Trial License. Про установку Keil MDK 5 можно прочитать тут.
Он должен быть установлен по умолчанию в папку
C:\Keil_v5
.GCC бесплатен, но генерируемые им прошивки имеют на 10% больший объем, чем сгенерированные компилятором RealView. GCC ARM Embedded можно скачать в виде архива и распаковать содержимое в любое место. Папку с распакованным содержимым архива я буду далее называть
<gcc folder>
.Компиляция с помощью ARM RealView Compilation tools
В дистрибутиве уже сделаны настройки компиляции для версий MDK 3.1, 3.80a, 4.12, 4.13, 4.54, 5.04, 5.05. Если нужно использовать другую версию, то можно добавить несколько строк в файл
<repo folder>\tools\Targets\Microsoft.Spot.system.mdk.targets
Я использовал версию 5.06. Для этого после строк
<CC Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.05'">"$(MDK_TOOL_PATH)\ARMCC\bin\armcc.exe"</CC>
<CPP Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.05'">"$(MDK_TOOL_PATH)\ARMCC\bin\armcc.exe"</CPP>
<AS Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.05'">"$(MDK_TOOL_PATH)\ARMCC\bin\armasm.exe"</AS>
<LINK Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.05'">"$(MDK_TOOL_PATH)\ARMCC\bin\armlink.exe"</LINK>
<AR Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.05'">"$(MDK_TOOL_PATH)\ARMCC\bin\armar.exe"</AR>
<FROMELF Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.05'">"$(MDK_TOOL_PATH)\ARMCC\bin\fromelf.exe"</FROMELF>
<MdkCrtLibLinkSwitch Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.05'">$(MdkCrtLibLinkSwitch) $(SWTC)libpath $(MDK_TOOL_PATH)\ARMCC\LIB</MdkCrtLibLinkSwitch>
я добавил строки
<CC Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.06'">"$(MDK_TOOL_PATH)\ARMCC\bin\armcc.exe"</CC>
<CPP Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.06'">"$(MDK_TOOL_PATH)\ARMCC\bin\armcc.exe"</CPP>
<AS Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.06'">"$(MDK_TOOL_PATH)\ARMCC\bin\armasm.exe"</AS>
<LINK Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.06'">"$(MDK_TOOL_PATH)\ARMCC\bin\armlink.exe"</LINK>
<AR Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.06'">"$(MDK_TOOL_PATH)\ARMCC\bin\armar.exe"</AR>
<FROMELF Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.06'">"$(MDK_TOOL_PATH)\ARMCC\bin\fromelf.exe"</FROMELF>
<MdkCrtLibLinkSwitch Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.06'">$(MdkCrtLibLinkSwitch) $(SWTC)libpath $(MDK_TOOL_PATH)\ARMCC\LIB</MdkCrtLibLinkSwitch>
Теперь можно приступать к компиляици. Нужно открыть командную строку и перейти в папку с репозиторием, например так:
cd /d D:\WORKDIR\NetMf\NetMFRepo\repo
затем нужно установить переменные окружения, выполнив:
setenv_mdk 5.06
После чего перейти к папке с портом (
<repo folder>\Solutions\STM32F4DISCOVERY). Например, так:
cd /d D:\WORKDIR\NetMf\NetMFRepo\repo\Solutions\STM32F4DISCOVERY
Теперь можно запускать компиляцию используя, например, такую команду:
msbuild dotnetmf.proj /p:flavor=release /fl
где
msbuild
— вызов запуска сборки
dotnetmf.proj
— проект порта для STM32F4DISCOVERY
/p:flavor=release
— тип сборки (debug/release/rtm)
/fl
— запись лога сборки в файл.файл лога будет лежать в текущей папке (в примере это
D:\WORKDIR\NetMf\NetMFRepo\repo\Solutions\STM32F4DISCOVERY
). Если лог не нужен, то
/fl
можно убрать.Чтобы посмотреть все варианты компиляции нужно выполнить
msbuild /t:help
Компиляция идет долго и занимает у меня 10 минут:
В результат появится множество файлов из которых нужны будут:
<repo folder>\BuildOutput\THUMB2FP\MDK5.06\le\FLASH\release\STM32F4DISCOVERY\bin\Tinybooter.hex\<repo folder>\BuildOutput\THUMB2FP\MDK5.06\le\FLASH\release\STM32F4DISCOVERY\bin\tinyclr.hex\ER_CONFIG<repo folder>\BuildOutput\THUMB2FP\MDK5.06\le\FLASH\release\STM32F4DISCOVERY\bin\tinyclr.hex\ER_FLASHДля чистой сборки перед выполнением команды
msbuild dotnetmf.proj /p:flavor=release /fl
нужно выполнить команду
msbuild /t:clean
или удалить папку
<repo folder>\BuildOutput
Компиляция с помощью GCC ARM Embedded
Использование GCC может потребовать еще одной правки. В файле:
<repo folder>\Solutions\STM32F4DISCOVERY\STM32F4DISCOVERY.settings
после строки
<NO_BOOTLOADER_COMPRESSION>true</NO_BOOTLOADER_COMPRESSION>
нужно добавить
<PLATFORM_EMULATED_FLOATINGPOINT Condition="'$(COMPILER_TOOL)'=='GCC'">true</PLATFORM_EMULATED_FLOATINGPOINT>
Это исправляет ошибку “NNNN.a uses VFP register arguments”. Подробнее можно прочитать тут.
Однако, эта ошибка может и не возникнуть, если использовать “чистую” сборку.
Для чистой сборки перед выполнением команды
msbuild dotnetmf.proj /p:flavor=release /fl
нужно выполнить команду
msbuild /t:clean
или удалить папку
<repo folder>\BuildOutput
Итак, чтобы собрать порт нужно открыть командную строку и перейти в папку с репозиторием, например так:
cd /d D:\WORKDIR\NetMf\NetMFRepo\repo
затем нужно установить переменные окружения, выполнив:
setenv_gcc <gcc ver> <gcc folder>
где
<gcc ver>
— версия gcc
<gcc folder>
— путь, где находится GCC ARM EmbeddedКоманда может выглядеть например так:
setenv_gcc 4.9.3 D:\WORKDIR\NetMf\gcc_4_9_3
После чего перейти к папке с портом (
<repo folder>\Solutions\STM32F4DISCOVERY
). Например так:
cd /d D:\WORKDIR\NetMf\NetMFRepo\repo\Solutions\STM32F4DISCOVERY
Компиляцию можно запустить используя, например, такую команду:
msbuild dotnetmf.proj /p:flavor=release /fl
где
msbuild
— вызов запуска сборки
dotnetmf.proj
— проект порта для STM32F4DISCOVERY
/p:flavor=release
— тип сборки (debug/release/rtm)
/fl
— запись лога сборки в файл.файл лога будет лежать в текущей папке (в примере это
D:\WORKDIR\NetMf\NetMFRepo\repo\Solutions\STM32F4DISCOVERY
). Если лог не нужен, то
/fl
можно убрать.Чтобы посмотреть все варианты компиляции нужно выполнить
msbuild /t:help
Компиляция идет долго и занимает у меня 10 минут:
В результат появится множество файлов из которых нужны будут:
<repo folder>\BuildOutput\THUMB2FP\GCC4.9\le\FLASH\release\STM32F4DISCOVERY\bin\Tinybooter.hex<repo folder>\BuildOutput\THUMB2FP\GCC4.9\le\FLASH\release\STM32F4DISCOVERY\bin\tinyclr.hex\ER_CONFIG<repo folder>\BuildOutput\THUMB2FP\GCC4.9\le\FLASH\release\STM32F4DISCOVERY\bin\tinyclr.hex\ER_FLASHПрошивка платы
Итак, имеются 3 файла:
Tinybooter.hex, ER_CONFIG и ER_FLASH
.
Tinybooter
— это bootloader. Они используется для прошивки CLR.
ER_CONFIG
и
ER_FLASH
это сама CLR.Для того, чтобы прошить плату нам потребуется дополнительное ПО:
- STM32 ST-LINK Utility — программатор, чтобы прошить TinyBooter.
- Установленные MicroFraimworkSDK.MSI и NetMFVS14.vsix — первый содержит необходимые библиотеки и утилиты, второй — template проектов .Net Micro Fraimwork для Visual Studio.
- USB драйер, необходимый для того, чтобы утилиты из состава MicroFraimworkSDK увидили плату (Для Windows 10 не нужен).
Для прошивки платы нужно сделать следующее:
- Подключить плату к компьютеру через miniUSB провод:
- Запустить STM32 ST-LINK Utility и выбирать меню Target->Connect:
После соединения с платой STM32 ST-LINK Utility будет выглядеть примерно так:
- Нужно стереть текущую прошивку выбрав в меню Target->Erase Sectors...:
И там нажать Select All а затем Apply:
Процесс очистки flash микроконтроллера:
После очистки STM32 ST-LINK Utility будет выглядеть так:
- Нужно прошить TinyBooter.hex выбрав меню Target-> Program & Verify...:
а затем выбрать файл tinybooter.hex и нажать Start:
После прошивки STM32 ST-LINK Utility будет выглядеть так:
- Нужно перезагрузить плату или вытащив miniUsb провод или нажав черную кнопку Reset
- Вставить microUSB провод:
STM32 ST-LINK Utility можно закрыть. miniUsb провод теперь будет использоваться только в качестве питания.
- На Windows 10 драйвер устанавливается автоматически, а для других версий нужно установить USB драйвер из списка выше в режиме ручной установки:
- Теперь нужно запустить .NET Micro Framework Deployment Tool.
Найти ее можно в MicroFrameworkSDK:
C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.4\Tools\MFDeploy.exe
В ней нужно переключить интерфейс с Serial на USB:
После этого появится имя платы. Проверить правильность работы TinyBooter можно нажав кнопку Ping. В консоли будет выведеноPinigng… TinyBooter
- Далее нужно с помощью .NET Micro Framework Deployment Tool прошить оставшиеся 2 файла ER_CONFIG и ER_FLASH. Выбрать их нужно после нажатия нижней кнопки Browse…
Для прошивки нужно нажать Deploy:
После прошивки можно нажать еще раз Ping и убедиться что CLR развернута на плате:
Все, плата готова для работы.
Первый проект на Visual Studio
Теперь можно создать и запустить проект на Visual Studio. Сделаем простой blinky проект, мигающий светодиодами.
Запускаем Visual Studio и создаем новый проект:
Если установка SDK и vsix была выполнена верно, то появится новый template проекта Micro Framework. Выберем Console Application:
Создав solution, можно зайти в свойства проекта:
В настройках проекта на вкладке .NET Micro Framework в поле Transport выбираем USB. После этого название платы должно появиться в поле Device:
Сохраняем и закрываем настройки.
Далее нужно добавить Refrence на сборку по адресу:
C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.4\Assemblies\le\Microsoft.SPOT.Hardware.dll
И последним этапом нужно заменить код в
program.cs
на этот:using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
namespace STM32F4DISC_Test
{
public class Program
{
public static void Main()
{
OutputPort ledGreen = new OutputPort((Cpu.Pin)60, false);
OutputPort ledYellow = new OutputPort((Cpu.Pin)61, false);
OutputPort ledRed = new OutputPort((Cpu.Pin)62, false);
OutputPort ledBlue = new OutputPort((Cpu.Pin)63, false);
while (true)
{
ledGreen.Write(true);
Thread.Sleep(500);
ledYellow.Write(true);
Thread.Sleep(500);
ledRed.Write(true);
Thread.Sleep(500);
ledBlue.Write(true);
Thread.Sleep(500);
ledGreen.Write(false);
ledYellow.Write(false);
ledRed.Write(false);
ledBlue.Write(false);
Thread.Sleep(500);
}
}
}
}
Запускаем проект:
И через несколько секунд светодиоды на плате начинают мигать.
Заключение
.NET Micro Fraimwork — достаточно сложный проект. На текущий момент, он все еще требует определенных навыков и знаний, особенно при работе с репозиторием. В данной статье я специально максимально подробно рассказал о том, с чем приходится сталкиваться при компиляции портов, так как эта информация пригодится при разработке решений для собственных плат.
Однако запустить .NET Micro Fraimwork на STM32F4Discovery можно проще и быстрее, взяв уже готовые файлы Tinybooter.hex, ER_CONFIG и ER_FLASH. Скачать их можно тут.
В ближайшее время я подготовлю архив, содержащий исправленную версию репозитория и все необходимые инструменты для сборки и запуска порта на STM32F4Discovery с помощью GCC, и опубликую на geektimes короткую инструкцию о том, как это сделать.
Комментарии (66)
Ununtrium
30.11.2015 11:37+1А пример чего-то более-менее серьезного будет?
AlexandrSurkov
30.11.2015 11:39Если разработчики дадут мне разрешение, то я напишу про этот коммерческий проект.
AlexandrSurkov
30.11.2015 13:07К более менее серьезному можно отнести порт на MCBSTM32F400. Он тоже входит в репозиторий.
Там есть сеть, USB, внешняя flash и т.д. С этим можно уже не только светодиодами мигать.
Еще есть Netduino — открытая аппаратная платформа для .NET Micro Framework
Кроме того, есть компания GHI Electronics весь бизнес которой построен на .NET Micro Fraimwork. На их сайте есть галерея проектов.
LampTester
30.11.2015 13:22+3На текущий момент, он все еще требует определенных навыков и знаний
Прочел и задумался о той интересной эволюции взглядов, которая нынче происходит. То, что профессиональный инструмент требует «определенных навыков и знаний», подается как безусловный минус; очевидный смысл фразы в одобрении стремления к предельному упрощению всего и вся, пускай и в ущерб эффективности — только бы мозг не напрягать. Но помилуйте, это же не продукт для рядового пользователя, в котором стремление разгрузить извилины еще можно оправдать, а вполне себе инструмент разработки (даже то, насколько он хорош сам по себе — другой вопрос).
В целом мне очень жаль, что эта идеология, давно господствующая в заметной части прикладного программирования, теперь просачивается и в эмбед, причем не без подачи самих производителей.AlexandrSurkov
30.11.2015 13:38+2Дело в том, что крупные компании кинувшись в след IoT пытаются расширить свое влияние в embedded и для этого стараются привлечь к своей технологии максимальную аудиторию. Те или иные наборы IoT софта для работы с микроконтроллерами есть и у Google и у Intel и у других менее масштабных фирм.
И все стремятся облегчить труд программиста, потому что embedded это действительно сложно. Лично я не вижу ничего плохого в этом. Те кто хочет напрячь мозг — и так будут его напрягать, зато появятся люди с другим складом ума, которые придумают много новых необычных устройств, так как создавать их станет гораздо легче.
Тут можно сравнить этот процесс с эволюцией PC. С каждым годом разработка уходит все дальше от железа, а когда то ведь писали все на ассемблере.LampTester
30.11.2015 17:55зато появятся люди с другим складом ума, которые придумают много новых необычных устройств, так как создавать их станет гораздо легче.
Не знаю, возможно в таком контексте это прозвучит излишне резко, но мне почему-то сразу вспомнилась известная идея про миллион обезъян с пишущими машинками…
Как минимум отмечу, что «необычный» и «полезный» — это разные категории, хотя иногда и пересекающиеся.
Indemsys
01.12.2015 00:49+1Это не эволюция. Скриптовые языки также стары как ассемблер.
Вся индустрия ПЛК держится на скриптовых движках уже десятки лет.
Но движки ПЛК по прежнему продаются за огромные деньги и не собираются дешеветь.
А смысл скриптов в том что они безопасны на микроконтроллерах без MMU.
Если в линуксе можно писать на нативном C-и и все равно иметь безопасный код, то для микроконтроллеров типа Cortex-M3,M4,M7,M8 остаются только скрипты.
И в этом их сила. Можно написать глючный скрипт, загрузить его по сети в микроконтроллер и этот скрипт не убъёт все остальные задачи RTOS на микроконтроллере.
А значит вы резко увеличиваете эффективность разработки, поскольку не тратите лишние минуты на подъем убитой среды исполнения после каждой итерации.LampTester
01.12.2015 12:13Вы, наверное, не совсем внимательно прочли мой комментарий. Я совершенно не выступаю против скриптовых языков самих по себе (хотя, кстати, я бы не назвал C# скриптовым языком); более того, я сам с удовольствием использую в проектах, например, C и Lua — получается где надо, гибко, а где надо — эффективно, а в целом в меру быстро и качественно.
Комментарий был даже не про C# сам по себе, о необходимости встраивания которого можно вести отдельные дебаты, а об общей тенденции к разработке средств, ориентированных прежде всего на дилетантов. В наши дни, как мы видим, уже звучат возгласы о том, что если средство требует навыков и знаний для того, чтобы его использовать, то это уже плохо.
А вообще, безопасность (встраиваемого) кода должна обеспечиваться в первую очередь квалификацией разработчика (я даже не называю его программистом, потому что тот, кто пишет для встраиваемых систем, всегда должен быть больше электронщиком), а после этого — тестированием. Тогда не потребуется спускать значительную часть производительности под костыли, которые призваны подчистить ошибки, проистекающие от низкой квалификации пишущего.
Alexey2005
01.12.2015 13:11+1В некоторых случаях может быть дешевле создать костыли один раз и потом посадить кодировать беженцев из Пакистана, чем каждый раз тратиться на качественное тестирование и зарплаты квалифицированным специалистам, которым потом ещё попробуй замену найди, если кто-то решит уволиться.
AlexandrSurkov
30.11.2015 18:28Как минимум отмечу, что «необычный» и «полезный» — это разные категории, хотя иногда и пересекающиеся.
Так в том то и дело! Все необычные идеи — это, как правило, прототипы. А полезные вещи делать будут как раз люди, напрягающие мозг, подхватившие хорошую идею )
Так же сейчас везде и происходит! Да и хороших embedded разработчиков станет тоже больше. Некоторым ведь и покопаться глубже захочится )LampTester
01.12.2015 12:27полезные вещи делать будут как раз люди, напрягающие мозг, подхватившие хорошую идею
Люди, напрягающие мозг, обычно не нуждаются в том, чтобы подхватывать чью-то идею — у них и своих хватает. Просто квалифицированный разработчик как правило не возьмется за 80% того, что дилетант вприпрыжку побежит реализовывать. Это оттого, что профессионал благодаря своему образованию и опыту видит возможные подводные камни еще до того, как они возникнут, и не горит желанием на них натыкаться, а сразу ищет обходные пути. Потому его рабочий процесс с виду протекает не так бурно.
В целом, мнение о том, что человек «с улицы» сможет сделать/придумать что-то такое, что недоступно профессионалу в данной области, является классическим проявлением эффекта Даннинга-Крюгера. На деле увеличение количества дилетантов в определенной области приводит только к усилению информационного шума, в результате чего он порой начинает скрывать что-то действительно стоящее.AlexandrSurkov
01.12.2015 12:53То есть вы выступаете против популяризации технологий, так как это ведет к увеличению количества дилетантов? Но ведь профессионалы тоже с чего то начинали, будучи дилетантами.
За .NET Micro Fraework стоит огромный пласт сложного кода на C/C++. Без знания устройства портов сложно сделать что-то действительно стоящее. Это вполне может подтолкнуть человека к более глубокому изучению темы. Так что гипотетический студент, помигав светодиодами с помощью C#, захочет изучать направление дальше — вполне возможный сценарий. И не так важно что будет дальше: Arduino, Netduino или собственная плата. Даже пусть он поиграет и бросит все это, все-равно положительный эффект будет. Важно что человек научился чему-то новому.
Хабр для этого и существует, чтобы одним делиться информацией, а другим ее получать. Ну и для холивара тоже место найдется :) В дискуссиях и спорах рождается истина! :)LampTester
01.12.2015 13:07То есть вы выступаете против популяризации технологий, так как это ведет к увеличению количества дилетантов?
Я выступаю против популяризации технологий путем увеличения количества дилетантов.
Гипотетическому студенту, если он начинает с нуля, гораздо полезнее курс теоретических основ электротехники, чем мигание светодиодом с помощью фреймворка, которого он не понимает. Да и мигание светодиодом бывает разное. Мигание светодиодом на ассемблере — это обучение, ибо дает понятие об устройстве контроллера, строении периферийных блоков, организации памяти программ и данных, принципах исполнения кода и т.п. Мигание светодиодом на той же Ардуине — развлечение, т.к. для этого не требуется никакого понимания железа. Ну а про .NET я вообще не говорю.
Важно что человек научился чему-то новому.
В данном случае мы имеем дело с тем, что у человека создалась иллюзия того, что он чему-то научился, хотя он даже не прикоснулся к сути. Так и получаются люди, прикручивающие WiFi к Ардуино (и в силу этого уверенные в своей крутизне), но не знающие законов Кирхгофа.AlexandrSurkov
01.12.2015 13:34В ваших словах есть своя правда. ТОЭ будет гораздо полезное мигания светодиодами. Как овсянка по утрам полезнее бутербродов. Но многие ли едят овсянку по своему желанию?
ТОЭ — это теория, причем достаточно нудная. А за полтора часа с нуля помигать светодиодами — это интересно. И вполне может сподвигнуть к изучению ТОЭ. Так и с овсянкой. Если в нее добавить, например, вишневого варенья, то ее вполне можно уже есть :)
Популяризация технологий методом «учиться 3 года чтобы прикрутить Wifi к Arduino и почувствовать себя по настоящему крутым, потому что теперь ты будешь понимать все: от каждого вольта в триггерах регистров до колебания частиц в антенне» не самая лучшая затея. Мы же с вами не в вузе преподаем сейчас.
4 года назад, когда я первый раз узнал о netmf, я бы очень обрадовался статье, рассказывающей как с этим всем работать.LampTester
01.12.2015 13:54ТОЭ — это теория, причем достаточно нудная.
Видимо, вам не повезло с преподавателем, ну или это просто не ваше. Мне в свое время на лекциях по теории цепей было интересно.
А за полтора часа с нуля помигать светодиодами — это интересно.
Правда, совершенно бесполезно. Более того, даже вредно, ибо создает ложное чувство понимания. Все должно приходить в свое время и после соответствующего количества усвоенного.
И вполне может сподвигнуть к изучению ТОЭ.… Мы же с вами не в вузе преподаем сейчас.
Вы сами-то в это верите?
Будете смеяться, но я таки преподаю в ВУЗе (по совместительству с основной работой, конечно), и могу сказать, что те, кому сама специальность неинтересна (а таких большинство), не подвигнутся даже такими граничащими с клоунадой мерами, а те, кто правда знают, куда и зачем пришли, не боятся и голого железа с ассемблером, более того, сами просят, чтобы я на занятиях копнул глубже.
учиться 3 года чтобы прикрутить Wifi к Arduino и почувствовать себя по настоящему крутым, потому что теперь ты будешь понимать все: от каждого вольта в триггерах регистров до колебания частиц в антенне
Снова неверный посыл и полное непонимание того, зачем же надо учиться, кстати, не три, а шесть лет в ВУЗе. Очень характерное, кстати, непонимание.
Так вот, в ВУЗе надо учиться не для того, чтобы подключать WiFi модуль к Arduino. В ВУЗе учатся те, кто будет делать не детские поделки из кубиков, а настоящие промышленные устройства, на которых держится современный мир. Например, электронику для автомобилей с соответствующими требованиями к исполнению и надежности. Ну а в свободное время такие люди могут попроектировать и Ардуино-кубики, чтобы массы забавлялись…AlexandrSurkov
01.12.2015 14:33Я предполагал, что вы преподаете. Это видно по основательности и стилю ваших комментариев.
В мое время на инженера учились 5.5 лет, из которых 2 года были общеобразовательные предметы. Так что 3 года на специальность — это как раз срок обучения на втором высшем образовании.
На мой взгляд, в вас говорит закоренелый преподаватель, несколько оторванный от студентов. Причем это ни сколько не умоляет ваших достоинств. Как правило, такие люди дают наиболее фундаментальные знания.
Но, истории у всех разные.
Я, например, один из немногих на потоке, кто действительно работает по специальности. И все этапы, о которых вы говорите, испытал на себе. Но и мои сокурсники при этом тоже вполне неплохо устроились в жизни.
А еще, наоборот, я знаю хороших разработчиков, закончивших непрофильные ВУЗы.
Интерес к специальности появляется курсе на 4, когда ты понимаешь что и зачем. А до этого, куча информации на лекциях остается огромным объемом, который нужно впихнуть себе в голову, интересным только эпизодически. А еще тебе 20 лет и жизнь вокруг кипит…
Конечно есть на потоке несколько человек тех, кто «кто правда знают, куда и зачем пришли». Но, скажем так, это несколько «странные» люди.LampTester
01.12.2015 15:06+1в вас говорит закоренелый преподаватель
Не уверен, что у меня было время закоренеть. :) Я сам не так давно закончил, да и вообще преподаю, скажем так, в свободное время, скорее для души и из благодарности родному ВУЗу, «кто если не я», и т.д., и т.п.
Интерес к специальности появляется курсе на 4, когда ты понимаешь что и зачем.
Это катастрофа, на самом-то деле. Сначала должен появляться интерес к специальности, а потом человек должен выбирать соответствующий ВУЗ. Иначе смысл вообще идти в ВУЗ наугад? А так получается, что когда (хотя я бы сказал «если») пробуждается интерес к специальности, необходимые курсы уже прошли мимо.
Конечно есть на потоке несколько человек тех, кто «кто правда знают, куда и зачем пришли». Но, скажем так, это несколько «странные» люди.
Порой мне приходит мысль, что всех остальных, не «странных», стоило бы отчислить для пользы дела — это позволило бы лучше учить тех троих человек, которые пришли не зря. В такие моменты я обычно усилием воли смиряю перфекционизм и ставлю зачет за такую работу, за которую по справедливости стоило бы отчислить…
Вообще, если посмотреть на дело по-честному, это просто в голову не умещается — «странными» считаются как раз те, кто пришел по адресу и достоин учиться там, куда поступил. Не абсурд ли? Может остальным все же стоит уйти в какие-то другие места? Тем не менее, по факту это сейчас норма…
А еще тебе 20 лет и жизнь вокруг кипит…
Я пошел в местный политех потому, что к одиннадцатому классу сочинял схемы и программировал контроллеры на ассемблере и Си, а на эту «кипящую жизнь» мне было как-то плевать, я хотел совсем другого. По наивности я ожидал, что уж там-то (в отличие от школы) я встречу единомышленников, вообще, некоторое подобие радиофорума… Ну, вы понимаете, как круто я обломился. Так что я, увы, понимаю, о чем вы. Только я считаю это не нормой, а большой бедой нашего образования. Увлеченные одиночки вынуждены выживать даже в тех местах, которые, казалось бы, созданы специально для них. Грустно, когда тому, кто называется студентом-радиотехником, интереснее КВН и посиделки в общаге, чем ТОЭ и курс общей физики. КВН это, наверное, тоже хорошо; однако, может быть, тем, кто им до такой степени интересуется, стоит идти в ГИТИС?AlexandrSurkov
04.12.2015 14:08У всех своя дорога.
Наверное, лет 30-40 назад вы бы встретили единомышленников практически в любом техническом вузе, но мир слишком быстро меняется.
Я в свои 17 лет писал только бейсике и ни о каких схемах и контроллерах не знал и в помине. Шел в ВУЗ скорее интуитивно. Лично мне с самого первого курса не хватало понимания схемы образования. Нас просто пихали знаниями, не объясняя зачем. Понятно стало уже потом…
Мне кажется что 90% студентов не очень понимают куда именно они попали и чему конкретно их будут учить. И так было всегда.
Наверное вы правы, насчет того, что это серьезная проблема образования. Но уровни вузов везде разные. Я не знаю, что вы закончили, но наверное в МГУ или в Бауманке вы бы нашли единомышленников, не говоря уж о зарубежных вузах…
Но все таки ВУЗ это далеко не только учеба. В какой-то из статей известной когда-то «Компьютерры» я прочитал интервью, в котором была высказана идея, что «высшее образование делает человека сложнее и именно в этом его цель». ВУЗ должен развивать, причем в разных направлениях. Это и музыка, и КВН, и посиделки в общаге, и спорт, и самое главное, конечно, само образование. Но все это единое целое, неделимое.
ВУЗ дает возможность понять кто ты и дает выбрать свою дорогу. А уж кто и как воспользуется этим выбором, зависит только от самого человека.
AlexandrSurkov
01.12.2015 14:52+1Впрочем, мы с вами совсем далеко ушли от темы статьи. Я с удовольствием подискутировал бы с вам за чашкой чая!
HomoLuden
30.11.2015 19:10Повторяю свой вопрос…
Сколько ресурсов требует / потребляет описанное в статье приложение?AlexandrSurkov
30.11.2015 21:35Бинарник CLR от GCC — 316 кб. От RealView — 297 кб. По потреблению RAM сказать пока не могу, не смотрел. Как посмотрю — напишу вам.
Mirn
30.11.2015 22:50ещё просьба замерить быстродейстсвие на простой типовой алгоритмической задаче и сравнить с gcc
AlexandrSurkov
01.12.2015 10:03Предложите задачу, я попробую сравнить.
Mirn
01.12.2015 10:19например БИХ фильтр с длинной в 10 выборок, и замерить в микросекундах время фильтрации 8 тысяч выборок на C и C#.
например такой код: http://pastebin.com/qWWBqEWk
настройки винфильтра такие: http://prntscr.com/98zdddAlexandrSurkov
04.12.2015 16:33+1Замерил на .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 мне сейчас сложно замерять. Буду рад, если кто-то поможет. Код выложу.Mirn
04.12.2015 17:026.2 секунд на каждый из 10 блоков по 8000 выборок? Или это общее время на на все 10 блоков?
AlexandrSurkov
04.12.2015 17:12Это общее время на вот это:
for (int i = 0; i < 8000; i++) { output[i] = WinFilterеTest.iir(input[i]); }
То есть на каждый блок по 8000 выборок
AlexandrSurkov
04.12.2015 17:30+1В 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 секунды.Mirn
04.12.2015 17:49у меня другие результаты:
проц: 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 чуток медленее на пару тыщь тактов для одного блокаAlexandrSurkov
04.12.2015 18:04Возможно частота другая и оптимизация, но сути это не меняет.
Я думаю стоит ориентироваться на то, что .Net Micro Framework работает на 2-3 порядка медленнее, в зависимости от оптимизации. Но он и не ориентирован на вычисления.
Для примера вот тут сравнивается C# и C++ на обычном компьютере.
«Самая медленная(из рассмотренных конечно) реализация на С#, медленнее самой медленной С++ реализации примерно в 4 раза»
Я так понимаю там средняя разница примерно в 10 раз.Mirn
04.12.2015 18:16+1теоритический предел 0.010сек (если по подсчёту операций)
так что мой результат ближе.
но даже случай с кейл на голову разгромил вывод такой для меня: звук не отфильтруешь даже низкого качества т.к. на один блок больше 1 сек. А кейл показал типичный результат компилятора без оптимизации: сейчас повторил на своём gcc — тоже чуть больше полу секунды.
Но мне C# нравится и наработками в области алгоритмов, и хорошей объектной моделью языка и думаю что он идеально применим в области например умного дома, промышленного управления и в прочих низкоскоростных вещах типа автомобильной и страховой телематики с мед гаджетами.
И думаю Си шарп в будущем ускорят и есть куда: я например делал на авр эмулятор 8051, смог добиться полной эмуляции его инструкций в реалтайме: разница в быстродействии выходила в 24 раза, на одну аппаратную инструкцию 51ого МК, выходило 24 инструкции АРМ. Сделал в виде таблицы функций 51ого на все 256 шт, каждая функция буквально пара асм инструкций на АРМе, кроме работы с переферией.
AlexandrSurkov
04.12.2015 17:33Соответственно, можно сделать вывод, что сам код примерно на порядок (12 раз) быстрее исполняется в native чем на .Net MicroFraimwork.
AlexandrSurkov
01.12.2015 09:31В документации к версии 4.3 указаны следующие минимальные требования: 64 Kb of RAM and 256 Kb of flash memory
Думаю что принципиально тут ничего не поменялось. Все зависит от набора периферии, поддерживаемой портом.HomoLuden
01.12.2015 12:29Как раз после ответа, мол, «4.4 сильно отличается от 4.3» я и начал повторять свой вопрос. Новая версия позволяет компилировать/транслировать C# напрямую в машинный код (грубо говоря, нету виртуальной машины). Это как нативные сборки UWP на платформе Windows 10.
AlexandrSurkov
01.12.2015 13:05Не совсем так. .NET Micro Framework состоит из 2х частей. Трансляцией C# в машинный код без использования портов занимается llilum. Но это пока экспериментальный проект.
В статье же речь идет о netmf-interpreter. Это прямой наследник версии 4.3, хотя и сильно отличающийся по составу дистрибутива.
den1s1
30.11.2015 22:33кто по задумке разработчиков должен делать порты под разные микроконтроллеры: сами разработчики фреймворка или пользователи (программисты)?
порт делается под МК или под плату?AlexandrSurkov
01.12.2015 09:42Порты может делать кто угодно, но как правило их делают пользователи. .NET Micro Framework изначально был платным и, видимо, подразумевалось что порт будут делать производители железа.
Порт делается под конкретную плату, но разные порты могут использовать один и тот же код, связанный с микрокнтроллером. В версии 4.4 входит код для STM32F4, на его базе сделано 2 порта: STM32F4Discovery и MCBSTM32F400.
Порты могут содержать разную периферию, при этом процессор моет быть один и тот же. Плата может быть с дисплеем или без, с сетью или без, с SD карточкой или без и т.д.den1s1
01.12.2015 09:46«как правило их делают пользователи»
ну пока я на гитхабе вижу только 2 порта под мк))
1. а есть ли документация или некая памятка по созданию портов?
2. известно ли о планах разработчиков по созданию некоего набора портов?AlexandrSurkov
01.12.2015 10:25Дело в том, что с переездом на GitHub разработчики переделали дистрибутив, убрав оттуда «все лишнее».
Раньше, netmf состоял из 2х частей: client — все что связано с разработкой приложений для .NET Micro Framework и Porting Kit — для разработки портов. Сейчас все это объединено. При этом за бортом остались порты под старые ARM7 процессоры (NXP LPC22XX,LPC24XX Renesas SH72XX и тд.) и много полезного софта и документации для работы с портами.
1) По документации вы можете начать отсюда. Это ссылка на документы к версии 4.3. Они достаточно скудные, но лучше чем ничего. А вот тут уже достаточно подробное описание.
AlexandrSurkov
01.12.2015 10:542) Разработчики порты не делают. Сейчас они очень активно работают над llilum. Это вторая ветка .NET Micro Fraimork, основанная на совершенно новом подходе. Тут идея в том, что код сначала компилируется в Microsoft Intermediate Language (MSIL, предшественник CLI), а затем в Intermediate representation (IR). IR код подвергается существенной оптимизации и из него уже получается машинный код. По сути это немного измененная LLVM.
То есть нет никаких портов, а приложение компилируется сразу в ассемблерный код.
AlexandrSurkov
01.12.2015 11:03«The STM32 (Cortex M3) Port was provided by Cuno Pfister and Beat Heeb at Oberon Microsystems.» — анонс версии netmf 4.2
История этих портов уходит аж в 2011 год :)
Indemsys
01.12.2015 00:40+1Спасибо за статьи.
Правильно ли я понял, что сборка под ARM производится скриптами msbuild, а не средствами IDE Keil?
Т.е. непосредственно под Keil нет проекта для сборки?
И вообще нет ничего такого где можно было бы обозреть проект для сборки .NET FM в виде структурированного дерева папок и исходников.
Понять состав проекта можно только изучая скрипты msbuild?
AlexandrSurkov
01.12.2015 10:38Почитайте эту документацию. Она дает общее представление о том, что такое порты и как они устроены.
В 2011 году я и мой коллега задавались точно такими же вопросами. В итоге мы сделали свою IDE для разработки портов — PKStudio. Она умела делать следующее:
— Редактор кода
— Компиляция из программы
— Переход к ошибкам
— Анализ связей компонентов в виде диаграмм
— Полное преобразование проектов в компилируемые и линкуемые проекты Keil
— Просмотр и в будующем редактирование:
* Libraries
* LibraryCategories
* Features
* Processors
* Assemblies
— Просмотр Solutions
— Добавление и редактирование проектов
— Верификация Компонентов:
* Проверка ссылок
* Проверка уникальности GIUD
— Поиск компонентов по имени
Вот несколько скриншотов:
Она даже вошла в ветку comm дистрибутива 4.2
Но сейчас ее нет в дистрибутиве.
Вообще я планировал подправить PKStudio для работы с версией 4.4 и написать о ней статью, заодно рассказать об устройстве портов. Но это будет наверное уже в январе.
Indemsys
01.12.2015 11:39На основе какого-то фреймворка делали PKStudio?
А какой компилятор там используется?
Т.е. я прав, что нет обозревателя для проекта .NET FM?AlexandrSurkov
01.12.2015 12:17Сделано все на C# и WinForms. Для построения используется тот же MSBuild, а компилятор настраивается переменными окружения. То есть процесс тот же, что и в статье, просто все это визуализировано.
Стандартного обозревателя нет, но с помощью PKStudio можно сконвертировать порт в проект для Keil, который можно скомпилировать и даже отлаживать на микроконтроллереюIndemsys
01.12.2015 13:40+1Все скомпилил и загрузил, но ссылка на USB драйвер вроде битая.
Мой Windows 7 нашел драйвер, но показывает его как WinUsB и MFDeploy.exe не видит плату.
Не могли бы поправить ссылку.AlexandrSurkov
01.12.2015 13:44+1Скачайте по первой найденной ссылке в гугле. Так должно работать. А я пока попробую найти прямую рабочую ссылку.
AlexandrSurkov
01.12.2015 13:50Поправил.
Indemsys
01.12.2015 14:32Что-то не то.
Вот мое окно в ST-LINK
Тут и загрузочный образ больше и начальные вектора совсем другие чем в вашей статье.
Компилировал KEIL ARM MDK 5.06
Причем все качал сегодня. И файл BuildSignerSpotBuild.csproj править не пришлось. Уже был исправлен.AlexandrSurkov
01.12.2015 14:35+1Попробуйте скачать и залить скомпилированные мной hex файлы.
Если все отработает — будем разбираться что не так скомпилировалось. А если нет, то значит что-то вы не так подключаете.Indemsys
01.12.2015 15:00+1Получилось.
Делал так.
-Загрузил вашу прошивку. Не помогло.
-Тогда снес драйвер WinUsb в адвансед режиме со стиранием файлов драйвера. И снова воткнул разъем USB в Discovery.
-Тогда появился совсем другой драйвер и в другой ветке дивайсов. Вот такой:
-Тогда загрузил опять свою прошивку. Плата обнаружилась.
Остальное тоже загрузилось после этого.
Пушу приложение.AlexandrSurkov
01.12.2015 15:03+1У меня на Windows 10 на одной из машин тоже были проблемы с драйвером. Плата в системе была видна, но MFDeploy.exe ее не видел. А на других все работало без проблем. Мир не идеален :)
Indemsys
01.12.2015 15:25+1Все написал и запустил приложение.
Потрясающе просто и быстро.
Arduino в подметки не годится.
Вот такая программа
выдавала вот такой меандр ():
Для скрипта очень неплохо.
AlexandrSurkov
01.12.2015 15:07А каким именно способом репозиторий скачивали?
Indemsys
01.12.2015 15:30Скачивал как описано в вашей статье. Сначала Fork, потом клонировал на комп.
Но я пользуюсь программой GitHub Desktop
mmMike
Главный вопрос: А зачем?!
Это же контроллер. И не так уж много ресурсов у SMT32Fx оказывается, когда пишешь что то более менее серьезное.
И, если, используешь контроллер по полной (DMA, прерывания и пр.), то зачастую приходится и листинги ассемблера смотреть что бы понять, в чем проблема и как gcc код скомпилил.
А тут еще какая то дополнительная прослойка (самодельный .NET), вносящая что то свое. Мало глюков в GCC. Еще глюки в левом софте.
Ну ну…
Ну если только помигать лампочками…
Совершенно бредовый проект.
AlexandrSurkov
Да, это сложно. Чтобы писать нормально на .Net Micro Framework нужно ставить внешнюю RAM и FLASH.
Но это все вполне работоспособно. Я знаю успешный коммерческий проект, сделанный на этой технологии.
Если вам нужно сделать устройство со сложной логикой работы и поддержкой многих протоколов, а не просто помигать лампочками, то тут как раз все прелести «управляемого кода и Visual Studio» и пригодятся.
А помигать лампочками как раз проще в каком нибудь Arduino.
mmMike
Наличие проекта на .NET говорит ни о чем. Скорее только о том, что где то кто то привык к .NET и имеет наработки на нем.
Если кому то нужна внешняя ОЗУ или FLASH к классическому микроконтроллеру — это означает скорее ошибку в выборе архитектуры/чипсета.
Линейки контроллеров весьма сбалансированы по своим параметрам и для типичных задач не требуют внешних расширений памяти.
Хотя ладно… не всегда ошибку. Причины могут быть разные (склад завален конкретными корпусами, плата уже разведена, разработчики есть только под .NET и т.д. и т.п.). Но все равно, в общем случае — это корявое решение.
По другому и не сказать.
Не говорите мне про Arduino. У меня это слово вызывает отвращение.
Вот именно, что мигать лампочками…
AlexandrSurkov
«Наличие проекта на .NET говорит ни о чем. Скорее только о том, что где то кто то привык к .NET и имеет наработки на нем.» В общем и целом согласен. Каждый выбирает то что он хочет. У любого подхода есть свои плюсы и минусы.
Моя цель не в том, чтобы убедить всех что нужно только .NET Micro Fraimwork, а чтобы показать что есть еще и такая технология и что можно ей пользоваться. Ну и рассказать как ее использовать.
С точки зрения коммерческой разработки, я тоже считаю Arduino просто игрушкой. Но, как платформа для обучения, он неплох. А вот с .NET Micro Fraimwork наоборот. Играть с и учиться с ним сложно, а для коммерческих проектов он может быть полезен.