Сегодня сломаем привычный мир инженеров и разработчиков встраиваемых систем на микроконтроллерах. В .NET существует замечательный паттерн программирования, как внедрение зависимостей (Dependency injection, DI). Суть паттерна заключается в предоставление механизма, который позволяет сделать взаимодействующие в приложение объекты слабосвязанными. Эти объекты будут связаны между собой через абстракции, например, через интерфейсы, что делает всю систему более гибкой, более адаптируемой и расширяемой. Но когда ведется разработка для микроконтроллеров, все зависимости обычно жестко завязаны на используемых устройствах, и замена датчика иногда приводит к существенному переписыванию программного кода. Напишем приложение на .NET nanoFramework для микроконтроллера ESP32, используя паттерн DI с возможностью легкой замены датчиков и LCD экрана.

Паттерн внедрение зависимостей

Паттерн внедрение зависимостей в основном используют для разработки Веб-приложений на ASP.NET. На самой концепцией паттерна не будем останавливаться, многие .NET разработчики хорошо знакомы с данным паттерном, более подробно можно почитать статью Сервисы и Dependency Injection на metanit.

Библиотека DI для nanoFramework предоставляется в виде nuget-пакета nanoFramework.DependencyInjection. Контейнер DI автоматизирует многие задачи, связывает объекты, управляет жизненным циклом приложения. API библиотеки максимально приближен к официальному .NET Dependency Injection. Исключения в основном возникают из-за отсутствия поддержки дженериков в .NET nanoFramework.

Для создания контейнера DI необходимо три основных компонента:

• Композиция объектов (Object Composition) — композиция объектов, определяющий набор объектов для создания и сопряжения;
• Регистрация сервисов (Registering Services) — необходимо определить экземпляр ServiceCollection и зарегистрировать в нем объекты с определенным временем жизни;
• Поставщик услуг (Service Provider) — создание поставщика услуг для извлечения объекта.

DI был бы неполным без Generic Host (общий хост). В nanoFramework доступен в виде nuget-пакета nanoFramework.Hosting. Generic Host конфигурирует контейнер приложения DI, а также предоставляет доступ к сервисам в контейнере DI и управляет жизненным циклом. Когда запускается Host, то вызывается Start() для каждой реализации IHostedService, которые зарегистрированы в коллекции сервисов хоста. В контейнере приложения для всех объектов IHostedService, таких как BackgroundService или SchedulerService, вызывается метод ExecuteAsync(). API библиотеки максимально приближен к официальному .NET Generic Host. Рассмотрим на практике применение паттерна DI.

Архитектура

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

• Текущая дата и время;
• Температура и влажность;
• Давление.

Таким образом, пользователь может узнать текущее время и температуру окружающей среды. Время на устройстве автоматически синхронизируется с NTP-сервером в сети Интернет.

Метеостанция состоит из следующих компонентов:

• Плата ESP32 DevKit v1 на базе микроконтроллера ESP-WROOM-32;
• Цветной дисплей на контроллере SSD1306 подключали в посте Что нового в .NET nanoFramework? Подключаем LCD экран, сканируем Wi-Fi сети;
• Датчик BME280 для измерения атмосферного давления, температуры и влажности подключали в посте Программируем микроконтроллеры ESP32 и STM32 на C# (nanoFramework);
• Емкостная панель клавиатуры на базе датчика MPR121.

Работа устройства:

Схема подключения

Все датчики подключаются по шине I2C. Единственно, был использован LCD SSD1306 c 7-pin контактами для которого требуется дополнительно подключать контакт GPIO для инициализации. В случае использования 4-pin дисплея этого не требуется делать.

Устройства для подключения:

• Датчик BME280, шина I2C, контакты: 21-pin DATA, 22-pin CLOCK;
• Экран SSD1306 OLED с 7-pin I2C/SPI, шина I2C, контакты: 21-pin DATA, 22-pin CLOCK, 18-pin RES для инициализации;
• Емкостная панель клавиатуры на базе датчика MPR121, шина I2C, контакты: 21-pin DATA, 22-pin.

Итоговая схема будет выглядеть следующим образом:


Принципиальная схема подключения устройств к ESP32 DevKit v1 (fzz)

Приложение

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

• ISensorsService — получение данных о состоянии окружающей среды;
• IKeyboardService — получение номера кнопки;
• IDisplayService — отображение информации.

Интерфейсы

ISensorsService

В интерфейсе ISensorsService декларирована только одна функция получения данных с датчика.

public interface ISensorsService
{
  public SensorsResult GetSensorsResult();
}

public class SensorsResult
{
  public SensorsResult() { }
  public SensorsResult(double temperature, double pressure, double humidity)
  {
    Temperature = temperature;
    Pressure = pressure;
    Humidity = humidity;
  }
  public double Temperature { get; }
  public double Pressure { get; }
  public double Humidity { get; }
}

Как видно из примера, отсутствует жесткая привязка к внутренней реализации работы датчика.

IKeyboardService

Задача интерфейса IKeyboardService заключается в получение кода кнопки. Каким образом будет реализована клавиатура абсолютно неважно, это может быть и обычная кнопочная клавиатура, подключаемая к аналоговому контакту, например клавиатура Analog ADKeyboard Module.


Модуль Analog ADKeyboard Module

Просто считываем код кнопки, который привязан к вариантам состояния экрана.

public interface IKeyboardService
{
  public int ReadKey();
}

IDisplayService

Для интерфейса дисплея IDisplayService передается тип экрана и объект содержащий данные для отображения.

public interface IDisplayService
{
  public void Show(Screen screen, object obj);
}

public enum Screen
{
  Clear_0,
  DateTime_1,
  TempHum_2,
  Pressure_3,
}

Датчики

Рассмотрим клавиатуру на базе датчика Mpr121. Класс KeyboardSingleton наследуется от интерфейсов IKeyboardService и IDisposable. Содержит функцию инициализации и функцию ReadKey() которая объявлена в интерфейсе IKeyboardService.

Файл KeyboardSingleton.cs:

internal class KeyboardSingleton : IKeyboardService, IDisposable
{
  private const int busId = 1; // bus id on the MCU
  private I2cDevice _i2cDevice;
  private Mpr121 _mpr121;
  
  public KeyboardSingleton()
  {
    this.InitMpr121();
  }
  
  private void InitMpr121()
  {
    Debug.WriteLine("Init InitMpr121!");
    I2cConnectionSettings i2cSettings = new(busId, Mpr121.DefaultI2cAddress);
    _i2cDevice = I2cDevice.Create(i2cSettings);
    _mpr121 = new Mpr121(_i2cDevice);
  }

  public int ReadKey()
  {
    bool[] channelStatuses = _mpr121.ReadChannelStatuses();
    int key = -1;
    for (int i = 0; i < channelStatuses.Length; i++)
    {
      if (channelStatuses[i])
      {
        key = i;
        break;
      }
    }
    return key;
  }
}

Работа с другими устройствами, такими как клавиатура и дисплей организованна так же.

Сервисы IHostedService

Сервисы являются основными самостоятельными единицами приложения. Все сервисы добавляются в коллекцию сервисов ServiceCollection(). Host builder вызывает методы Start() и Stop() для соответствующих сервисов. Можно создать несколько реализаций IHostedService и зарегистрировать с помощью метода ConfigureService() в контейнере DI.

Пример класса сервиса:

public class CustomService : IHostedService
{
  public void Start() { }

  public void Stop() { }
}

Сервис MonitorService

Вся основная логика приложения размещается в сервисе MonitorService. Рассмотрим объявленные переменные в классе и конструктор класса.

Файл MonitorService.cs:

internal class MonitorService : IHostedService
{
  private ISensorsService _sensorsService { get; }
  private IDisplayService _displayService { get; set; }
  private IKeyboardService _keyboardService { get; }
  private Thread _handlerThread;
  private CancellationTokenSource _cs;

  public MonitorService(ISensorsService sensorsService, IDisplayService displayService, IKeyboardService keyboardService)
  {
    _sensorsService = sensorsService;
    _displayService = displayService;
    _keyboardService = keyboardService;
  }

В конструкторе класса присутствует композиция объектов, с которыми доступно взаимодействие. Как видим, вместо класса KeyboardSingleton присутствует интерфейс IKeyboardService. Сам класс MonitorService не завязан на реализации конечных используемых датчиков, таким образом, реализуется концепция слабосвязанного приложения. Подобным образом строится взаимодействие с датчиками интерфейс ISensorsService, и LCD дисплеем интерфейс IDisplayService.

Далее метод Start() запускает поток, в задачу которого входит считывание состояния клавиатуры, показаний датчиков и отправка данных на LCD дисплей.


Используя интерфейс, получаем показания датчиков:

sensorsResult = _sensorsService.GetSensorsResult();  

Далее, считываем код кнопки:

key = _keyboardService.ReadKey();

В зависимости от нажатой кнопки отправляем на интерфейс дисплея необходимые данные для отображения. Где Screen.DateTime_1 и Screen.TempHum_2 тип экрана для отображения, второй параметр тип object данные для отображения.

switch (currentScreen)
      {
        case Screen.DateTime_1:
          DateTime currentDateTime = DateTime.UtcNow + TimeSpan.FromHours(3); // +3 GMT
          _displayService.Show(Screen.DateTime_1, currentDateTime);
          break;
        case Screen.TempHum_2:
          _displayService.Show(Screen.TempHum_2, sensorsResult);
          break;
...

Для завершения работы сервиса вызывается метод Stop().

public void Stop()
{
  Debug.WriteLine("MonitorService stopped");
  _cs.Cancel();
  Thread.Sleep(2000);
  if (_handlerThread.ThreadState == ThreadState.Running) _handlerThread.Abort();
}

Теперь перейдем к основному host builder.

Generic Host

Для создания хоста запускается построитель хоста (host builder), в задачу которого входит создание контейнера сервисов, т.е. создается ServiceProvider содержащий коллекцию сервисов.

Основная функция Main(), файл Program.cs:

public static void Main()
{
  //////////////////////////////////////////////////////////////////////
  // when connecting to an ESP32 device, need to configure the I2C GPIOs
  Configuration.SetPinFunction(21, DeviceFunction.I2C1_DATA);
  Configuration.SetPinFunction(22, DeviceFunction.I2C1_CLOCK);
  //////////////////////////////////////////////////////////////////////            
  IHost host = CreateHostBuilder().Build();
  // starts application and blocks the main calling thread 
  host.Run();
}

До использования датчиков на шине I2C необходимо объявить соответствующие контакты 21-pin и 22-pin.

Затем построитель хоста создает host и затем его запускаем методом Run().

Регистрация сервисов выполняется в отдельной функции CreateHostBuilder():

public static IHostBuilder CreateHostBuilder() =>
Host.CreateDefaultBuilder()
  .ConfigureServices(services =>
  {
    //Receiving data from sensors
    services.AddSingleton(typeof(ISensorsService), typeof(SensorsSingleton));
    //Data output to the display
    services.AddSingleton(typeof(IDisplayService), typeof(DisplaySingleton));
    //Keyboard
    services.AddSingleton(typeof(IKeyboardService), typeof(KeyboardSingleton));
    //MonitorService
    services.AddHostedService(typeof(MonitorService));
    //Connecting to WiFi and time synchronization
    services.AddHostedService(typeof(ConnectionService));
  });

Необходимо обратить внимание, что жизненный цикл Singleton начинается только тогда, когда они вызывются из HostedService.

Последним из сервисов вызывается сервис подключения по беспроводному соединению Wi-Fi к сети Интернет для синхронизации времени. Рассмотрим его подробнее.

Классы BackgroundService и SchedulerService

Дополнительно в библиотеке есть классы SchedulerService и BackgroundService, образованные от IHostedService.

Класс SchedulerService

Данных класс предназначен для выполнения повторяющихся действий с заданным интервалом времени. Класс содержит объект Timer и запускает в указанное время с заданным интервалом асинхронный метод ExecuteAsync(). Таймер выключается вызовом метода Stop().

Пример сервиса на базе класса SchedulerService:

public class DisplayService : SchedulerService
{
  // represents a timer control that involks ExecuteAsync at a 
  // specified interval of time repeatedly
  public DisplayService() : base(TimeSpan.FromSeconds(1)) {}

  protected override void ExecuteAsync(object state)
  {   
  }
}

Класс BackgroundService

Класс предназначен для выполнения долгоработающей фоновой задачи. Для запуска сервиса вызывается асинхронный метод ExecuteAsync(). Работа ExecuteAsync() должна завершиться сразу после вызова CancellationRequested для корректного завершения работы сервиса.

Пример сервиса на базе класса BackgroundService:

public class SensorService : BackgroundService
{
  protected override void ExecuteAsync()
  {
    while (!CancellationRequested)
    {
      // to allow other threads time to process include 
      // at least one millsecond sleep in loop
      Thread.Sleep(1);
    }
  }
}

На основе класса BackgroundService реазизована задача подключения к беспроводной сети Wi-Fi.

Сервис ConnectionService

В задачу сервиса входит подключение к беспроводной сети с последующей синхроизацией времени. После подключение к сети отправляется запрос точного времени на сервер «0.fr.pool.ntp.org», адрес NTP-сервера времени можно выставить любой.



Исходный код приложения: GitHub — nanoframework-esp32-di-weatherstation

Доработка библиотеки для дисплея SSD1306 OLED

В прошлый раз библиотека nanoFramework.Iot.Device.Ssd13xx была доработана для поддержки 7-pin контатного варианта дисплея, Pull requests #550. Но на этом работа с дисплеем оказалась не закончена. Во время написания приложения обнаружился неприятный эффект в виде большой паузы во время перерисовки экрана при выводе времени. Перерисовка экрана выполнялась 1 раз в секунду. Проблема заключалась в неверном подходе работы с дисплеем. Рассмотрим текущий алгоритм работы с дисплеем:

using Ssd1306 device = new Ssd1306(I2cDevice.Create(new I2cConnectionSettings(1, Ssd1306.SecondaryI2cAddress)), Ssd13xx.DisplayResolution.OLED128x64, 18);

device.ClearScreen();
device.Font = new BasicFont();
device.DrawString(2, 2, "nF IOT!", 2);//large size 2 font
device.DrawString(2, 32, "nanoFramework", 1, true);//centered text
device.Display();

Метод ClearScreen() очищает экран от изображения. Далее методами DrawString() выполняется формирование изображения в буфере дисплея. Метод Display() формирует изображение на дисплее исходя из матрицы данных в буфере. Таким образом, видна очевидная проблема при повторной отрисовки изображения, которая заключается в том, что в интервал времени между вызовами методов ClearScreen() и Display() дисплей заполнен черным цветом.

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

Для упрощения реализации, в методе ClearScreen(), просто была закомментирована строка вызова метода Display() для перерисовки экрана дисплея.

Файл Ssd13xx.cs, метод ClearScreen():

public void ClearScreen()
{
  Array.Clear(_genericBuffer, 0, _genericBuffer.Length);

  //---> Display();
}

Ресурсы

• .NET nanoFramework Dependency Injection Library — Github
• .NET nanoFramework Generic Host Library repository — Github
• nanoFramework team code samples — Github