Easyelectronics.ru

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

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



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

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

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
Mirmik писал(а):
Да. Это слабое место. Тут приходится чем-то жертвовать. Я вот раздумываю сейчас над тем, должен ли класс сервопривода работать с единицами скорости и положения, естественными для системы, или должен работать в системе си. Если мы работаем в системе си, упрощается отладка, но опять же снижается быстродействие.

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


У нас все модули регулирования работают в относительных единицах в формате Q8.24 - в motorcontroldemo от НИИЭТ подсмотрели. Просто есть таблица приведения к системе СИ - по ней данные в контроллере с АЦП и энкодеров переводятся в относительные единицы, там обрабатываются и подаются на ШИМ. А по сетевому протоколу потом прибегают в компьютер или контроллер верхнего уровня, где по такой же точно таблице приводятся в системе СИ уже как требуется. В итоге, почти все расчеты - с int32 без лишних преобразований.


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

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 856
Регуляторы тоже в int32 работают?


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

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
Mirmik писал(а):
Регуляторы тоже в int32 работают?

Да, больше вроде бы никогда и не требовалось пока.


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

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 856
Используете арифметику с фиксированной запятой?


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

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
Mirmik писал(а):
Используете арифметику с фиксированной запятой?

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


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

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 856
sdv_cyborg писал(а):
Mirmik писал(а):
Используете арифметику с фиксированной запятой?

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


Теперь я знаю, что это означает :).


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

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


Управление рассчитывается в обработчике прерывания, которое привязано к работе таймера ШИМ и АЦП. Там строгая диаграмма работы. А в задачах RTOS неспешно читаем температуру, обрабатываем команды по USART, медленные управляющие сигналы (кнопки). Это упрощает написание приложений.

Основные интерфейсы (PPM, STEP/DIR, QEP, HALL, CAN) так же работают на прерываниях в обход RTOS.


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

Зарегистрирован: 28 янв 2010, 20:18
Сообщения: 591
По поводу соединения входов и выходов. Начну с того, что я подхватил идею регистрового файла от протоколов CAN. То есть весь интерфейс с уровнем регуляторов и железа сводим к обращению к регистрам. Каждый регулятор может выставлять свои регистры для настройки, указания текущего заданного значения или еще чего-то. Такой интерфейс можно использовать из кода, можно из командного интерфейса по USART а можно пробросить и через CAN. Что еще интересного это дает.
1) Одну переменную можно представить несколькими регистрами, например скорость в разных единицах измерения (рад/с, об/мин, % от максимальной);
2) Все настройки оказываются в регистрах и легко сохраняются/восстанавливаются разными способами;
3) Можно добавить механизм связывания, регистры - указатели, при обращении к которым получаем значение того, на что они указывают; Это используется например для того, чтобы назначить каким параметром будем управлять, модуль входного интерфейса читает длину импульса, преобразуем к величине скорости и записываем в регистр заданной скорости, или может быть не скорости а заданного момента, как пользователь сконфигурирует;

Show

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

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


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

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 503
Да, собственно на данный момент у нас тоже используется протокол наподобие CANOpen - только объектный словарь хранит в себе не регистровый файл, а указатели прямиком на элементы требуемых структур. Не знаю, все ли реализации CANOpen делают так, или в других объектный словарь является расшаренным регистровым файлом, из которого потом драйвера и управляющие структуры собирают данные, но в той реализации, из которой мы подсмотрели было именно так: в словаре лежат указатели на элементы глобальных структур. Остального мы не видали, реализация самого протокола закрыта (как я понял это из-за платного членства авторов кода в сообществе CANopen), но наподобие того сделали также.

Применение RTOS на пользовательском уровне - идея неплохая, но пока вроде бы обходились. Хотя, возможно, и понадобится так сделать.

Но пока, из того, что увидел у тов. Mirmik и Amaora плюс своих размышлений, идеология выстраивается такая:

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

У меня все на этом. Идеи для себя выяснил, а вот как это все реализовать - еще вопрос. Пока буду делать по старинке: набор глобальных структур, единый регистровый файл, все имеют доступ ко всему и могут друг за другом поправлять как пожелают. Будет время - буду думать, как реализовать фреймворк...


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


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


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

Сейчас этот форум просматривают: KPG


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

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

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