Easyelectronics.ru

Электроника для всех
Текущее время: 20 сен 2020, 20:20

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/5шт. два слоя. $5/5шт. четыре слоя
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 14:42 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
Доброго времени суток.

Ох, возможно, тема холиварная будет, но все-равно задам вопрос: совесть меня мучить не станет, а, глядишь, некоторую истину узнаю все же.

В общем, в процессе изысканий с управлением движками на своей текущей работе созрела мысль попробовать сляпать простенький motor control фреймворк, который можно было бы предоставлять в виде сырцов или завернуть в библиотеку и отдать кому нужно. Причины на такие извраты две:
1) чтобы будущие пользователи не возились с переписыванием и разбором сниппетов, из которых можно слепить прошивку, а взяли проект, вокруг него написали обертку и через какой-нибудь интерфейс загнали параметры используемых датчиков, число используемых каналов АЦП, масштабирующие коэффициенты, структуру регулятора и т.д., а фреймворк сам бы уже пережевывал, на откуп юзеру выдавая лишь по сетевому протоколу характеристики системы и ввод требуемых параметров;
2) чтобы, в случае чего, внутренний слой можно было сбилдить в .lib и оставить от него только интерфейсы в исходниках.

Так-то не было нужды вообще так извращаться, поэтому брал, как и большинство, сниппеты свои и чужие да из них прошивку собирал. Поэтому плоховато представляю, как такое можно сделать и чтобы оно совсем не превратилось в ардуину.
Требования к своему поделию предъявляю такие:
1) должно быть реализовано на голых сях;
2) код, ответственный за управление приводами должен быть производительным, с минимумом перетаскиваний массивов и структур по ОЗУхе в критичных по времени исполнения процедурах;
3) гибкость и простота настройки: пользователь должен настроить все датчики и регуляторы без лишних телодвижений, при этом не влезая в алгоритм обработки.
Для простоты будем считать, что алгоритм платформозависимый, и все усилия по портированию на другую платформу я беру на себя. В качестве примера - взять хотя бы опрос АЦП. Во "внутреннем" слое фреймворка есть обработчик АЦП со своими переменными, в которых он обрабатывает показания. В это же время, пользователь должен иметь возможность каждому каналу назначить все требуемые параметры (коэффициент масштабирования, смещение, единицы измерения и т.д.) во "внешнем" слое и потом только через сетевой протокол опять-таки из "внешнего" слоя - собирать данные. И так со всем остальным: структуры регуляторов квадратурные энкодеры, прочие датчики.

Кто-нибудь может подсказать, какие существуют подходы к реализации подобного дела? Или может быть даже в пример носом ткнуть? А то так-то я в качестве примера сейчас разглядываю исходники первокваки, но все-равно это очень отдаленный от реалий управления приводом пример.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 16:44 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Идея масштабная, увенчана благими намерениями.
Однако. Чем больше универсальности, тем тяжелее код и неоптимальнее работа. Возьмите для примера CubeMX. Штука универсальная, но жутко тяжелая, неповоротливая. Так же и у вас получится. А ведь моторчики - вещь весьма скоростная, требует быстрой соображаловки от микроконтроллеров.
Цитата:
код, ответственный за управление приводами должен быть производительным,

а самый производительный код - это узкоспециализированный, писанный под конкретный МК или серию МК, и для конкретного типа мотора - коллекторный, шаговик, трехфазный частотник.

Цитата:
без лишних телодвижений, при этом не влезая в алгоритм обработки.

а для этого есть готовые контроллеры (без приставки "микро") моторов. Там ничего не нужно знать, достаточно дать команду "вперед", остальное сделает контроллер.
Как правило, моторами управляет отдельная электроника. Получает входные команды от блока управления, остальное делает сама. Нет такого, чтобы центральный микроконтроллер устройства работал с клавиатурой и дисплеем пользователя и он же управлял работой ходового электромотора.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 17:01 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
Собственно, из своих размышлений к тому я и прихожу, что как ни крути - получается CubeMX. А такое совсем не нужно для motor-control МК.
Разве что только под конкретный контроллер сделать всевозможные программные модули, а потом собирать вместе в зависимости от нужд, как и было раньше. Только, может, модули сложить в .lib отдельный, чтобы не повадно было править отработанные исходники модулей, а просто брать и пользоваться модулями.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 17:24 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Чтобы меньше времени затрачивать на паписание девайса, нужно иметь:
1. низкоуровневые драйверы, работающий с "железом" микроконтроллера,
2. среднее звено, реализующее алгоритмы работы с мотором, в зависимости от его типа,
3. набор команд управления.

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


Последний раз редактировалось BusMaster 23 янв 2019, 17:34, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 17:34 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
Цитата:
Кто-нибудь может подсказать, какие существуют подходы к реализации подобного дела? Или может быть даже в пример носом ткнуть?

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

классика жанра. умные пацаны, с богатым опытом в С/С++ посидели подумали и сделали Cargo - the Rust package manager.

это такая утилитка, запускается из командной строки в директории проекта.
в каждом проекте есть файл манифест Cargo.toml выглядит примерно так с предопределенным форматом
он содержит в себе метаниформацию о проекте и какие у проекта зависимости (секция [dependencies])

в зависимости от того куда указаны пути к либам, CARGO утилита либо сдувает код с репозитория Github, либо с CRATES.IO, либо из указанной папки.

Rust это не только мощный язык но и продуманная, мультиплатформенная, инфраструктура управлениями зависимостями...

Вот как это должно выглядеть в идеале. Вероятно можно попытаться использовать CARGO и для нужд чисто Си проектов.

_________________
unirail.org


Последний раз редактировалось cheblin 23 янв 2019, 17:49, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 17:36 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
BusMaster писал(а):
Чтобы меньше времени затрачивать на паписание девайса, нужно иметь:
1. низкоуровневые драйверы, работающий с "железом" микроконтроллера,
2. среднее звено, реализующее алгоритмы работы с мотором, в зависимости от его типа,
3. набор команд управления.

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


Собственно, я про пункт 3 и говорю. А пункт 1 и пункт 2 чтобы были жестко "прибиты" к железу конкретного контроллера. Лишь с возможностью из пункта 3 настраивать последовательность работы пункта 2 с пунктом 1, что-то вроде коммутационной матрицы, которая бы, например, показания определенных датчиков передавала в регуляторы, а из регуляторов - на блоки ШИМ.
Собственно, речь сейчас даже не идет о кроссплатформенности, а больше о том, чтобы данная связка на одном применяемом МК для электроприводов работала, но была легкоизменяемой под нужны новой платы управления или может даже одной универсальной платы под разные нужды.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 17:37 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Цитата:
классика жанра

...понятно, с появлением китайца все дальнейшее обсуждение опустится до уровня рекламы этого ебнутого хРуста. Пиздец котенку.
Чоблин - как поручик Ржевский из анекдотов - пришел и всё опошлил, едва успев появиться


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 17:46 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
а ты перечитай, по ссылкам походи...подумай.

топикстартер правильные вопросы про модульность кода задаёт. только ответ не совсем прост.

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 17:50 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
BusMaster писал(а):
Цитата:
классика жанра

...понятно, с появлением китайца все дальнейшее обсуждение опустится до уровня рекламы этого ебнутого хРуста. Пиздец котенку.
Чоблин - как поручик Ржевский из анекдотов - пришел и всё опошлил, едва успев появиться


Собственно в итоге я этого и ожидал...)))
Впрочем, ясно, что такие фреймворки мало кто делает. А если и делают, то либо стоят они в итоге очень дорого, либо превращаются в CubeMX. Лучше сниппеты отточить и потом, если очень захочется их зажопить от работодателя или еще кого, в .lib собрать и все.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 17:53 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Хорошо. По третьему пункту у вас получится еще больше многообразия. Датчики? Окей. Делая привод координатного стола для 3дэ принтера мне из датчиков, по сути, нужны только концевики, чтобы "отбится" по начальной точке. Проскальзывание шаговика исключено. А если я буду на том же шаговике делать руку-манипулятор, мне нужны уже датчики величины перемещения для коррекции ошибок. А еще понадобится датчик потребляемого тока, чтобы избежать перегрузки и проскальзывания.
Датчики перемещения могут быть самого разнообразного типа - от магнитной линейки до лазерной телеметрии.

Да, как бы алгоритмы уже написаны, настроены, отточены. Но никто не будет валить в одну кучу, в одну библиотеку все эти алгоритмы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 18:03 
Старожил
Аватара пользователя

Зарегистрирован: 28 янв 2010, 20:18
Сообщения: 591
Делайте просто. Структура с входными параметрами, структура с выходными. Функция обновления. А в документации расписать диаграмму работы, и в каких единицах должны быть измерения.

Код:
      fb.current_A = m.ADC_IA;
      fb.current_B = m.ADC_IB;
      fb.voltage_U = m.ADC_US;

      /* PM update.
       * */
      pm_feedback(&pm, &fb);


Вложение:
diag2.png
diag2.png [ 144.35 Кб | Просмотров: 1291 ]


Но проще, мне кажется, добавлять прикладной код в готовый контроллер мотора, чем наоборот пытаться втащить управление мотором в проект, который вероятно не приспособлен к этому.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 18:15 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
amaora писал(а):
Но проще, мне кажется, добавлять прикладной код в готовый контроллер мотора, чем наоборот пытаться втащить управление мотором в проект, который вероятно не приспособлен к этому.


Так речь как раз об прикладном коде в контроллере мотора, только с возможностью перестраивать под разные случаи жизни.
Цель простая: назревает не один проект по управлению двигателями, причем самыми разношерстными. Плата непосредственно контроллера уже отработана. Платы драйверов могут быть различными. Мысль в том, чтобы одну и ту же плату контроллера по возможности переиспользовать, не меняя особо ее схему, ну и заодно программный код организовать таким образом, что от пользователя будет лишь задача проинициализировать нужную периферию и собрать цепь регуляторов из готовых блоков. Пока все это делалось таким образом, что под каждый модуль периферии была "рыба" программного модуля с большой структурой и несколькими ее обработчиками - и под каждый случай она переделывалась. Пока таких случаев всего два было. Дальше будет больше.

С раздельными структурами входных и выходных параметров - вполне вариант, можно уже придумать какую-никакую унификацию.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 18:32 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Вообще же, по теме темы очень хорошим вариантом будет приложентие-генератор кода, в котором будет база исходный кодов и они будут собираться в целевой комплект, исходя из выбранных пунктов. Аналог CubeMX, только более оптимально составленный. Автогенератор наборов - это очень правильный. Вариане


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 18:38 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
BusMaster писал(а):
Вообще же, по теме темы очень хорошим вариантом будет приложентие-генератор кода, в котором будет база исходный кодов и они будут собираться в целевой комплект, исходя из выбранных пунктов. Аналог CubeMX, только более оптимально составленный. Автогенератор наборов - это очень правильный. Вариане


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 19:05 
Старожил
Аватара пользователя

Зарегистрирован: 28 янв 2010, 20:18
Сообщения: 591
sdv_cyborg писал(а):
Так речь как раз об прикладном коде в контроллере мотора, только с возможностью перестраивать под разные случаи жизни.
...


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

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

Show


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 19:09 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
Цитата:
приложентие-генератор кода,

Цитата:
Мать собирает сына в поход:
- Вот, положила тебе масло, хлеб и килограмм гвоздей.
- Зачем???
- Ну чего же тут непонятного? Масло намажешь на хлеб и сьешь.
- А гвозди???
- Ну так вот же ж положила!


на выходе С99. лучше не придумать.

там, прям в коде, любое представление возможно. никаким кубам не снилось.
и такое
Изображение
и такое
Show

и такое
Show

остальное тут

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 19:25 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Ну от китайца "мяса" - как от козла молока :)))
Приложение-генератор кода - это своего рода человеческий интерфейс базы кодов с параметрическим поиском. По сути, чел в приложении-генераторе выбирает из списка тип мотора, желаемый алгоритм управления, набор датчиков, целевую платформу (МК), какие-то особенности целевой платформы, возможные варианты размещения, нажимает кнопочку "Сотворить" ( :-) ) и получат на выходе комплект сишных исходников или закрытую библиотеку с единообразным интерфейсом.
Вот такой вариант - наиболее правильный с точки зрения конечного пользователя. Правда, писать приложение-генератор - это тоже задача. Да и наполнение базы исходных кодов тоже. В этом плане CubeMX представляет правильную концепцию, просто базовый код слишком индусский и чрезмерно универсален в силу очень большого охвата. В чем преимущества Куба, в том же и его недостатки.

Show the fucking chinese shit!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 19:30 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
если ты научишься не только читать, но и осмысливать прочитанное - это тебе будет только в плюс...
а пока как всегда... газификация водоемов.

_________________
unirail.org


Последний раз редактировалось cheblin 23 янв 2019, 19:30, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 19:30 
Старожил

Зарегистрирован: 26 ноя 2012, 10:28
Сообщения: 4729
Откуда: КЧР, поселок Нижний Архыз
Знаем, проходили. Мужики еще лет 15 назад решили сделать "универсальные модули" для двигателей. И что? Каждый раз, как мне нужно управление шаговиками, я все равно развожу новую плату и практически с нуля фигачу управление! Потому что невозможно это универсализировать. Да и не стоит трудов: быстрей полдня потерять, да заново набросать управлялку, чем сношаться с тоннами быдлокода (выше уже привели хорошие два примера, которые категорически нельзя допускать: калокуб и педеrust)!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 19:35 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Чоблин, нах мне читать твое китайское барахло? Слухай, я и сам учить могу, и книги могу писать, епта. Нах бы я читал твои потуги. Не читал, не читаю, и не буду читать. Так и передай своим китайским корешам - да срал я на них с высоты птичьего полета.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 23:39 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
amaora писал(а):
sdv_cyborg писал(а):
Так речь как раз об прикладном коде в контроллере мотора, только с возможностью перестраивать под разные случаи жизни.
...


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

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


Ну вот у меня сейчас тоже что-то наподобие того, только без ОС - читал мнение, что FreeRTOS плохо годится для нужд управления двигателями, особенно для векторного управления.
И как раз хотелось унификации низкого уровня, т.к. у motor-control контроллеров вроде C2000 или НИИЭТового ВК01Т очень развесистая периферия, с тучей настроек. Каждый раз их переделывать, конечно, накладно. С другой стороны - действительно с такими делами легко скатиться в CubeMX, тогда и толку никакого нет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 23 янв 2019, 23:43 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
РТОС не нужна для таких вещей, как датчики или исполнительные механизмы. В последнее время всплеск популярности РТОС продиктован исключительно её появлением в CubeMX и неумением кодописателей составлять схему работы проги.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 25 янв 2019, 13:30 
Старожил
Аватара пользователя

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 856
Я как раз сейчас нахожусь в процессе написания чего-то подобного, правда требование по сям изначально не выполняю. У меня си с классами, шаблонами и виртуальным наследованием. Сылку на прототип даю, но там пока шаром покати, так что не обессудьте (https://github.com/mirmik/ralgo).

Библиотека строга объектна. Например, объекты сервопривода и импульсного регулятора положения имплементируют интерфейс position_driver, благодаря чему верхний уровень и системы траекторного управления, например, интерполятор и расчет кинематики отвязаны от непосредственной реализации. С другой стороны объект сервопривода ссылается через указатели на объект датчика положения, объект, контролирующий мощность и объект регулятора. Эти объекты тоже упрятаны за интерфейсы, вследствие чего для создания сервопривода следует по отдельности прописать класс датчика мощности (например реализующий step-dir на аппаратный драйвер), класс датчика положения (например энкодера или потенциометра) и создать необходимый объект-регулятор. Если не нравится, например, класс сервопривода (ну, там, абстрактно, установки нулевой позиции нехватает), можно, не нарушая общей структуры, переписать один уровень абстракции.

У меня, вообще, планируется далеко не простенький motor control framework (Это для этого чуда несколькими темами ниже я запрашивал материалы по алгоритмам оптимальной настройки), но тем не менее, тело библиотеки я вижу именно таким, строго объектным, с продуманными (и достаточно академичными) интерфейсами взаимодействия.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 25 янв 2019, 14:00 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
Mirmik писал(а):
Я как раз сейчас нахожусь в процессе написания чего-то подобного, правда требование по сям изначально не выполняю. У меня си с классами, шаблонами и виртуальным наследованием. Сылку на прототип даю, но там пока шаром покати, так что не обессудьте (https://github.com/mirmik/ralgo).

Библиотека строга объектна. Например, объекты сервопривода и импульсного регулятора положения имплементируют интерфейс position_driver, благодаря чему верхний уровень и системы траекторного управления, например, интерполятор и расчет кинематики отвязаны от непосредственной реализации. С другой стороны объект сервопривода ссылается через указатели на объект датчика положения, объект, контролирующий мощность и объект регулятора. Эти объекты тоже упрятаны за интерфейсы, вследствие чего для создания сервопривода следует по отдельности прописать класс датчика мощности (например реализующий step-dir на аппаратный драйвер), класс датчика положения (например энкодера или потенциометра) и создать необходимый объект-регулятор. Если не нравится, например, класс сервопривода (ну, там, абстрактно, установки нулевой позиции нехватает), можно, не нарушая общей структуры, переписать один уровень абстракции.

У меня, вообще, планируется далеко не простенький motor control framework (Это для этого чуда несколькими темами ниже я запрашивал материалы по алгоритмам оптимальной настройки), но тем не менее, тело библиотеки я вижу именно таким, строго объектным, с продуманными (и достаточно академичными) интерфейсами взаимодействия.

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



Да в том-то и дело, что с появлением интерфейсов между низкоуровневыми драйверами и структурами управления, снижается быстродействие: будь это хоть С++ с шаблонами и классами, хоть голые си с имитацией классов. Главная проблема, по личным наблюдением - нарушение локальности переменных, с которыми весь расчет ведется: класс датчиков один, класс регулятора другой, класс исполнительного механизма третий - в итоге, добавляется возня с минимизацией перетаскивания одних и тех же данных по разным местам ОЗУ по поводу и без. Поэтому баланс трудновато соблюсти, по-крайней мере мне с моим небольшим пока еще опытом.

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

Я в итоге докатывался до совсем крамольных мыслей касательно одновременно эффективной организации алгоритма и удобства: сделать как в первокваке и ее последователях, свой выделятор памяти под структуры управления и интерфейсы драйверов. На старте контроллера статически выделяется большой сегмент памяти (он на языке quake 1 называется zone memory) и следом за этим, по конфигурации пользователя выделяется память под все необходимые структуры. И все! Т.к. в моей текущей реализации один хрен почти все обработчики регуляторов и прочих подобных делов обращаются к структурам через указатели, а потом локализуют все параметры внутри тела процедур, то по сути реальные накладные расходы будут только на выделение места в самом начале программы - и дальше, в процессе работы, все это дело крутится себе и больше никогда не меняется. А драйверы периферии - АЦП, ШИМ, энкодеров - перебрасывают из своих локальных обработчиков данные в структуры интерфейсов. Как-то так. Но это все вилами по воде, надо проводить эксперименты на предмет того, насколько это надежно и какое у этого всего дела быстродействие.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация фреймворка для микроконтроллеров
СообщениеДобавлено: 25 янв 2019, 14:10 
Старожил
Аватара пользователя

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 856
sdv_cyborg писал(а):
Да в том-то и дело, что с появлением интерфейсов между низкоуровневыми драйверами и структурами управления, снижается быстродействие: будь это хоть С++ с шаблонами и классами, хоть голые си с имитацией классов. Главная проблема, по личным наблюдением - нарушение локальности переменных, с которыми весь расчет ведется: класс датчиков один, класс регулятора другой, класс исполнительного механизма третий - в итоге, добавляется возня с минимизацией перетаскивания одних и тех же данных по разным местам ОЗУ по поводу и без.


Да. Это слабое место. Тут приходится чем-то жертвовать. Я вот раздумываю сейчас над тем, должен ли класс сервопривода работать с единицами скорости и положения, естественными для системы, или должен работать в системе си. Если мы работаем в системе си, упрощается отладка, но опять же снижается быстродействие.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу 1, 2  След.


Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB