Комментарии 12
Да что-то вы замудрили. В таком небольшом проекте заменить дисплей можно и так без проблем. Обработка данных с датчиков это отдельные функции. А вот взять взамен маленького олед даже если большой TFT, графический интерфейс в любом случае надо переписывать, а данные которые они показывают никуда не денутся.
И да- писать под такие проекты под NET это то еще извращение. Тут даже без RTOS на чистых плюсах все будет работать быстрее и лучше.
Речь в основном не о конкретном проекте, а об использование Dependency injection в проекте, демонстрация как это выглядит. DI в дальнейшем потребуется для написания REST API как это реализовано в "большом" .NET, но уже для микроконтроллеров.
Очень узко специализировано, чисто для пет проектов и прототипов. В реальной жизни NET и DI в микроконтроллерах никому не сдался.
Раньше сказали бы и nF никому в реальной жизни не нужен. Однако nF живет и развивается. Классический шаблон для реализации REST API как раз таки DI. Весь смысл этой затеи перетянуть подход к проектированию приложений с "большого" .NET на микроконтроллеры. Для разработчиков стереть грань программирования между ПК и микроконтроллеров. Переквалифицировать текущих разработчиков .NET под задачи малой автоматизации на nF.
Я не эксперт в области программирование на микроконтроллерах. По моему маленькому опыту, один из самых важных аспектов это подбор оборудования, максимально дешево и чтобы можно было выполнить поставленную задачу. Возможно, для простых задач на микроконтроллерах, которые не требует высокой скорости обработки входных сигналов и относительной дешевизны stm, такая архитектура будет к месту. На текущий момент мне сложно представить, такого специалиста, который будет программировать что-то на C# и DI, а где-то будет использовать что-то другое более производительное без усложнений. На каждый экземпляр устройства будет тратиться больше денег, для того чтобы потенциально удешевить скорость замены модулей оборудования. Также мне очень трудно представить сложную архитектуру в устройствах на микроконтроллерах. Из личного опыта, последний хоум проект был связан с программирование робо руки. Прочитав несколько книжек по DI и набравшись опыта в C#, я решил, да будет ООП, сделаю все по "уму". Не буду вдаваться в подробности, но скорость поворота членов устройства меня сильно разочаровала и я перешел на старый добрый спагети код.
Вы забываете добавить к стоимости итоговой продукции еще затраты человеко*часы. За счет высокой абстракции nF позволяет писать код существенно быстрее. Задачи нефтедобычи и энергетики для вас это простые задачи? Устройство PalThree — используется для частого и точного мониторинга нефтегазовых месторождений от компании OrgPal.IoT, работает на nanoFramework. Более подробно в предыдущих постах тут и тут. Еще не забываем про родовую ветку microFramework, которую ведет компания GHI Electronics.
На большом .NET зарабатывает компания Toradex. Самостоятельно выпускает модули SoM и SBC. Платы работают на Linux, для разработки прикладного ПО используется:
Невозможно что-то конкретно сказать про ваш проект. Но если он у вас не получился на C#, точнее не были достигнуты целевые показатели, то из этого не следует что .NET на Linux или микроконтроллерах плохо работает.
В nanoFramework есть возможность блоки исходного управляемого кода переносить на ниже лежащий неуправляемый код, т.е. переводить на C+. Переносить функции особо критичные по скорости выполнения на уровень прошивки. А все остальное приложение остается на C#. Этот момент не был подробно пока рассмотрен в статьях, в следующих публикациях более подробно на этом остановимся. В частности, переносить на уровень прошивки потребуется драйвер и графическую библиотеку для больших экранов, для достижения максимального fps. Сделаем парочку интересных игр на большом дисплее со всеми плюшками в виде кнопочек, менюшек, и емкостной панели.
Ну и раскладка кнопок (красные)! Никогда такой бредовой не видел - да ещё и до 11....
Отсчет идет с 0 до 11, всего 12 кнопок, что тут странного? А мне, например, нравится красный цвет. Красный фирменный цвет SparkFun. Представленная модель не что иное, как клон SparkFun Capacitive Touch Keypad - MPR121.
Хм, прикольно. Но я бы ещё сравнил объемы программы с di и без. Ну и тут конечно удобно на c# писать. В какой-нибудь с уже di так легко не воткнешь... Ни конструктора нет, ни места куда инжектить зависимость.
Все это круто, а есть ли в этом самом nanoframework'e работа ulp?
Паттерн внедрение зависимостей в .NET nanoFramework для микроконтроллеров