Реализация собственного SDK

Впервые передо мной встала задача разработать набор инструментов для работы и управления с ПК готовым устройством. Задача не из простых, и “с места в карьер” не прыгнешь! Ход мыслей и о пути проектирования будущей библиотеки я рассуждаю в этой статье.

Я уже более года работаю в отделе разработок небольшой, но успешной компании, занимающейся разработкой источников питания. В мои обязанности входит разработка “мозгов”, написание прошивки для них, отладка и написание ПО для компьютера, которое позволяет управлять источником с ПК. Время идёт, продукция выходит на новый уровень и старое ПО уже не отвечает своим требованиям. Поэтому передо мной встала задача разработки SDK библиотеки для управления устройством. Сейчас для этого используется LabView либо софт на Visual C#, однако у обоих решений есть свои проблемы. Во-первых, оба решения не являются универсальными, да, мне и моим коллегам приходится писать свою версию софта для каждого устройства. Это, мягко говоря, не очень удобно, и не эффективно. Во-вторых, софт на вижуал си уже стар, имеет глюки на новых системах (писался ещё под ХР), и его невозможно портировать на другие ОС. Софтина для LabView достаточно сложна в реализации и трудна для понимания принципов работы другим людям.

Да, я совсем забыл сказать Вам, что не все клиенты используют наше ПО, некоторые пишут своё ПО или встраивают наше оборудование в свои системы, поэтому клиенту помимо софта передаётся ещё и описание протокола взаимодействия с устройством. Все устройства (блоки) связаны через виртуальный com-порт, реализованный в виде usb или rs232. Второй протокол более распространён среди наших устройств, так сложилось исторически, но потихоньку usb будет внедряться в больше и большее число устройств, по крайней мере, я на это надеюсь!

Поэтому я ставлю перед собой и буду освещать их здесь следующие задачи:

  1. Осмысление имеющегося интерфейса (связи) и продумывание наперед возможных функций и вектора его дальнейшего развития. Это необходимо для того, чтобы понимать как выглядит интерфейс сейчас, какие команды устаревают и умрут, какие могут появиться и чего ожидать.
  2. Выбор библиотеки для GUI. Критерии отбора: open source, кроссплатформенная, C++.
  3. Изучение лицензионного соглашения на предмет возможности использовать библиотеку и распространять ПО в желаемом виде.

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