Светодиодные фонари и световые приборы. Всё о светотехнике.
Вернуться   Форум FONAREVKA.RU Мастерские светотехников Мастерская: INFERION
Расширенный поиск
Забыли пароль? Регистрация

  • О нашем проекте
  • Светотехника и световые приборы
  • Правила форума
Проект FONAREVKA.RU специализируется на предоставлении всей необходимой информации по светотехнике:

— светодиодные фонари;
— различные источники питания;
— разнообразные зарядные устройства;
— освещение помещений и наружное освещение;
— световые приборы для личного, пассажирского и грузового транспорта;
— специальные световые приборы для медицины, для растений, для аквариумов, для террариумов, а также аварийно-сигнальные световые приборы;
— альтернативные источники света;
— лазеры и лазерная техника.

Если у вас есть вопросы по выбору фонарей, аккумуляторов и зарядных устройств ознакомьтесь с FAQ от наших экспертов:

F.A.Q. по выбору фонарей различных типов;
F.A.Q. по выбору аккумуляторов;
F.A.Q. по выбору зарядных устройств.
Ответ  Создать новую тему
Просмотров в теме 27714   Ответов в теме 57   Подписчиков на тему 4   Добавили в закладки 0
Опции темы Поиск в этой теме
Старый 07.12.2020, 16:47   21
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от INFERION :
Вот если ОУ подаст больше чем нужно "микросхеме" - будет возбуд. Внутри микросхемы штатная ОС всегда немного недорегулирует, поэтому на условые 0.1А отклонения "микросхема" отреагирует только условными 0.07А. А затем на оставшиеся 0.03А отреагирует изменив ещё на 0.03*0.7=0.021А, и так пока не выйдет на режим. Тут имеем усиление ошибки 0.7. Если оно будет >2 - "микросхема" начнёт промахиваться больше, чем было до этого. Вместо стабилизации получим генерацию. При усилении 1...2 - будет заметен звон - затухающие колебания.
Откуда взяли в расчётах усиление ошибки, почему именно такое, и откуда оно в реальности берётся?
Это из особенностей работы микросхемы стабилизатора напряжения, т.к. она сначала компенсировала 0.07 из 0.1?
Но раз вы говорите штатная ОС всегда немного недорегулирует, т.е. всегда меньше 1 коэффициент, то откуда возьмётся >2?
Artik555 вне форума   Ответить с цитированием Вверх
Старый 08.12.2020, 06:07 Автор темы   22
INFERION

 
Аватар для INFERION
 
Регистрация: 07.04.2013
Последняя активность: 13.06.2023 02:24
Адрес: Украина, Полтава
Сообщений: 5774
Сказал(а) спасибо: 340
Поблагодарили: 8154 раз(а) в 2385 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Откуда взяли в расчётах усиление ошибки, почему именно такое
Я его просто взял от балды, а как его получить на практике - это уже и есть проектирование схемы. "Микросхема" рассчитана на определённый уровень сигнала на FB, но мы своими цепями вносим в него дополнительную задержку, и это нужно компенсировать снижением усиления этого сигнала.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Это из особенностей работы микросхемы стабилизатора напряжения, т.к. она сначала компенсировала 0.07 из 0.1?
Это из основ теории автоматического управления. Вот картинка из гугла по PID регуляторам:

Ti (постоянная времени интегратора) может рассматриваться как 1/усиление ошибки. Интегратор есть в любой системе управления, явный или не явный. Инерция есть везде. Так вот он накапливает ошибку (добавляет к тем самым 0.07 те самые 0.021+0.0147+0.01...), и если усиление будет единичное, то это значит, что он сразу же к текущему состоянию добавит все 0.1, и пока преобразователь будет добавлять эти 0.1 к реальному выходу - интегратор ошибки уже успеет "улететь в стратосферу". Регулятор не должен бежать впереди исполнительной системы, он должен трезво оценивать скорость её реакции на воздействие регулятора. Этот Ti уже зашит в "микросхему", мы на него повлиять можем только внешним усилением сигнала на FB. Вот это относительное усиление я и называю сейчас усилением ошибки.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Но раз вы говорите штатная ОС всегда немного недорегулирует, т.е. всегда меньше 1 коэффициент, то откуда возьмётся >2?
У штатной - ниоткуда. Но мы же обсуждаем совсем не штатную? Он один только шунт на полупроводниковой нагрузке в 5 раз увеличивает эти самые условные 0.7 (из-за того, что дифференциальное сопротивление такой нагрузки раз в 5 ниже за сопротивление штатного делителя напряжения), снижая Ti в "микросхеме" в 5 раз, а ещё усилитель токового шунта вносит задержку в контур регулирования, что требует дополнительного увеличения Ti.

[Исправлено: INFERION, 08.12.2020 в 06:27]
INFERION вне форума   Ответить с цитированием Вверх
Поблагодарили: 1 раз
Artik555 (16.12.2020)
Старый 16.12.2020, 05:55   23
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от INFERION :
Прямая связь, предикативная ОС, управление с разомкнутой петлёй, фильтр Калмана... Я периодически натыкаюсь на описание одного и того же механизма под разными названиями и разного уровня сложности, и как правильно этот тип связи назвать - не знаю. Но идея шикарная, и благодаря цифре внедряется всюду. Суть в том, что некий "чёрный ящик", написанный сумрачным гением, изучает управляемую цепь, строит её виртуальную модель, и прежде чем сделать какой-то шаг - гоняет эту модель в виртуальной среде и выясняет что же она сделает ещё до того, как это произойдёт в реальности. Звучит громоздко и ресурсожруще, правда? Да вот нифига, несколько строк кода и мы симулируем RC-фильтр, колебательный контур, или целый динамик. На AVR в реальном времени. Я вот даже фотку у себя нашел, как тинька рисует 16 бит синус виртуальным колебательным контуром, затрачивая 4 байта на переменные и порядка 20-ти тактов на семпл:
Перечитал пару раз то что было до этого момента, и как-то не увидел... а зачем это нужно? Моделировать, просчитывать наперёд и предугадывать поведение системы прямо в микроконтроллере блока питания.
Ладно понимаю какая-то "резкая-шальная" нагрузка, у которой очень сильно, очень быстро и очень часто скачет потребление, для максимального поддержания напряжения питания постоянным, без провалов сильных и резких последующих перескоков выше желаемого..
Хотя, тут вроде о стабилизации тока речь.. ну допустим нагрузка с тем же самым резко скачащим потреблением, но которая должна питаться постоянным током.

Но светодиод... для чего тут эти моделирования поведения системы в реальном времени, неужели для стабльного питания светодиода не хватило бы просто отслеживающего ток микроконтроллера и игнорирующей всё программы(возможные всплески, шуми, ошибки), лениво изменяющей напряжение(на выходе микросхема стабилизатора напряжения, или на выходе из ЦАПа из rc цепочки, тут как посмотреть), раз в секунду, или по-другому сказать изменяющей раз в секунду частоту шима формирующей напряжение на вход обратной связи TPS, для компенсации теплового изменения сопротивления светодиода.(если заметила изменение тока допустим на заданный процент, меньше которого просто игнорирует)
(если не произошло переключение режимов)

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

[Исправлено: Artik555, 16.12.2020 в 05:57]
Artik555 вне форума   Ответить с цитированием Вверх
Старый 17.12.2020, 00:13 Автор темы   24
INFERION

 
Аватар для INFERION
 
Регистрация: 07.04.2013
Последняя активность: 13.06.2023 02:24
Адрес: Украина, Полтава
Сообщений: 5774
Сказал(а) спасибо: 340
Поблагодарили: 8154 раз(а) в 2385 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Перечитал пару раз то что было до этого момента, и как-то не увидел... а зачем это нужно?
Для подавления паразитных ПОС в схеме. Конкретно в этой схеме ПОС находится между источником питания и управляющей цепью преобразователя. Что произойдёт, если преобразователь нагрузит батарею - сильнее? -Просядет напряжение. Что за этим последует? -Просядет напряжение на выходе МК. А что последует за этим? -Преобразователь получит команду ещё сильнее нагрузить батарею (поднимет ток нагрузки)... И всё, привет возбуд... Как с этим бороться, если обычная ООС физически не успевает подкручивать заполнение ШИМ быстрее, чем эта ПОС работает? Ведь и её и ПОС замедляет один и тот же компонент - конденсатор на выходе ШИМ МК. Но в отличии от ПОС - ООС контролируется программой и сигнал можно программно доработать, компенсировав влияние этого конденсатора. Так ООС становится быстрее ПОС.
Хорошее развитие этой идеи получилось вот тут: https://forum.fonarevka.ru/...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
неужели для стабльного питания светодиода не хватило бы просто отслеживающего ток микроконтроллера и игнорирующей всё программы(возможные всплески, шуми, ошибки), лениво изменяющей напряжение(на выходе микросхема стабилизатора напряжения, или на выходе из ЦАПа из rc цепочки, тут как посмотреть)
А ЦАП что использует в качестве своего ИОН? А как это "что-то" реагирует на преобразователь? А как этот преобразователь реагирует на реакцию ЦАПа на реакцию этого "чего-то"?.. Добро пожаловать в схемотехнику! )
INFERION вне форума   Ответить с цитированием Вверх
Поблагодарили: 1 раз
Artik555 (24.12.2020)
Старый 24.12.2020, 04:39   25
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от INFERION :
Для подавления паразитных ПОС в схеме. Конкретно в этой схеме ПОС находится между источником питания и управляющей цепью преобразователя. Что произойдёт, если преобразователь нагрузит батарею - сильнее? -Просядет напряжение. Что за этим последует? -Просядет напряжение на выходе МК. А что последует за этим? -Преобразователь получит команду ещё сильнее нагрузить батарею (поднимет ток нагрузки)... И всё, привет возбуд... Как с этим бороться, если обычная ООС физически не успевает подкручивать заполнение ШИМ быстрее, чем эта ПОС работает? Ведь и её и ПОС замедляет один и тот же компонент - конденсатор на выходе ШИМ МК. Но в отличии от ПОС - ООС контролируется программой и сигнал можно программно доработать, компенсировав влияние этого конденсатора. Так ООС становится быстрее ПОС.
Но ведь это всё-таки в случае аналоговой ОС, которая реагирует условно сразу, и на всё, или в случае ОС реализованной программно и микроконтроллером, если она запрограммирована вести себя в точности как аналоговая.
Но ведь раз она программная, и если знаешь что и питание и потребитель стабильные, без резких частых изменений питания и потребления, то знаешь что все возможные помехи которые возможно словит "ОС из микроконтроллера" это точно именно помехи, и их можно просто программно заставить контроллер игнорировать? И/или усреднять замеры. Допустим RC фильтр на выходе мк просто стабильно выдаёт свои 0.5В опорного напряжения для микросхемы плевав на всё, допустим за 1 секунду делается 10 измерений тока, и если усреднённо по ним ток немного уплыл то мк также раз в 1 секунду после замеров плавно и немного изменяет выходное напряжение.
В случае питания такой стабильной постоянной по потреблению нагрузки как светодиод и от аккумуляторов такая реализация "простого игнорирования" по-идее должна хорошо работать? Тем более вы в какой-то теме вроде говорили что мк способен чётко поддерживать частоту шима даже уходя в сон или типа того и снижая потребление практически до нуля...
А такая сложная с расчётами будущего поведения системы в реальном времени нужна именно для сложной нагрузки, и/или нестабильного питания, так получается?
Или я опять чего-то не вижу)


Цитата:
Посмотреть сообщение Сообщение от INFERION :
А ЦАП что использует в качестве своего ИОН? А как это "что-то" реагирует на преобразователь? А как этот преобразователь реагирует на реакцию ЦАПа на реакцию этого "чего-то"?.. Добро пожаловать в схемотехнику! )
Ах да... я забыл что "мы" в обсуждаемом случае вообще обрезали микросхеме её заводскую обратную связь... Я-то продолжал думать что она спокойно работает себе выдавая примерно нужные вольты и сама стабилизируя это напряжение, а мы измеряя ток только немного вносим коррективы в ОС...
Да хорошо бы так и делать наверное, оставлять микросхему настроенную на выходные допустим 2.5 вольта, и только немного вмешиваться в работу её стандартной ОС согласно току в цепи.

[Исправлено: Artik555, 24.12.2020 в 05:03]
Artik555 вне форума   Ответить с цитированием Вверх
Старый 24.12.2020, 06:25   26
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от INFERION :
Я его просто взял от балды, а как его получить на практике - это уже и есть проектирование схемы. "Микросхема" рассчитана на определённый уровень сигнала на FB, но мы своими цепями вносим в него дополнительную задержку, и это нужно компенсировать снижением усиления этого сигнала.
Это из основ теории автоматического управления. Вот картинка из гугла по PID регуляторам:

Ti (постоянная времени интегратора) может рассматриваться как 1/усиление ошибки. Интегратор есть в любой системе управления, явный или не явный. Инерция есть везде. Так вот он накапливает ошибку (добавляет к тем самым 0.07 те самые 0.021+0.0147+0.01...), и если усиление будет единичное, то это значит, что он сразу же к текущему состоянию добавит все 0.1, и пока преобразователь будет добавлять эти 0.1 к реальному выходу - интегратор ошибки уже успеет "улететь в стратосферу". Регулятор не должен бежать впереди исполнительной системы, он должен трезво оценивать скорость её реакции на воздействие регулятора. Этот Ti уже зашит в "микросхему", мы на него повлиять можем только внешним усилением сигнала на FB. Вот это относительное усиление я и называю сейчас усилением ошибки.
У штатной - ниоткуда. Но мы же обсуждаем совсем не штатную? Он один только шунт на полупроводниковой нагрузке в 5 раз увеличивает эти самые условные 0.7 (из-за того, что дифференциальное сопротивление такой нагрузки раз в 5 ниже за сопротивление штатного делителя напряжения), снижая Ti в "микросхеме" в 5 раз, а ещё усилитель токового шунта вносит задержку в контур регулирования, что требует дополнительного увеличения Ti.
Я вот всё думаю насчёт этого, а разве если бы в микросхеме стабилизатора напряжения была зашита "коррекция ошибки" с коэффициентом меньше 1, например 0.7, разве это не была бы панацея от всех проблем и неважно какое усиление ошибки мы бы сделали?

Т.е. допустим произошёл какой-то скачок, ПОС шунт+ОУ его бы усилила, а микросхема бы просто отработала бы его постепенно как "коррекция на 0.7, затем коррекция на 0.7 от остатка, затем опять на 0.7 от остатка и опять..." и плавненько бы всё погасила? Или нет?
Вроде если после ПОС, не важно с каким усилением стоит такой... ну мне он по логике работы похож на "интегратор последовательных приближений" больше чем на ООС, разве вообще может случиться возбуд?




Ну и ещё, вот думаю я об этом, а есть ли вообще смысл об этом думать? Разве не единственное решение которое можно делать если что-то не работает-это просто добавлять больше ёмкости конденсатора? Мы что-то ещё можем сделать?
Ах да, темы же про программно-микроконтроллерное решение этого вопроса, извиняюсь)
Но если в случае ОС на ОУ?

[Исправлено: Artik555, 24.12.2020 в 06:27]
Artik555 вне форума   Ответить с цитированием Вверх
Старый 25.12.2020, 00:42 Автор темы   27
INFERION

 
Аватар для INFERION
 
Регистрация: 07.04.2013
Последняя активность: 13.06.2023 02:24
Адрес: Украина, Полтава
Сообщений: 5774
Сказал(а) спасибо: 340
Поблагодарили: 8154 раз(а) в 2385 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Но ведь это всё-таки в случае аналоговой ОС, которая реагирует условно сразу, и на всё, или в случае ОС реализованной программно и микроконтроллером, если она запрограммирована вести себя в точности как аналоговая.
Но ведь раз она программная, и если знаешь что и питание и потребитель стабильные, без резких частых изменений питания и потребления, то знаешь что все возможные помехи которые возможно словит "ОС из микроконтроллера" это точно именно помехи, и их можно просто программно заставить контроллер игнорировать?
Я ничего не понял...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Допустим RC фильтр на выходе мк просто стабильно выдаёт свои 0.5В опорного напряжения для микросхемы плевав на всё
Ага, и как он будет плевать на своё опорное напряжение, которым и задаёт эти 0.5V? Ну вот есть на входе 4V, ШИМ делит их на 8 и получает 0.5V, и вот вдруг аккум просел на 0.5V - ШИМ посылает нахер всё и продолжает делить на 8, ага?.. И мы должны по прежнему получать 0.5V? С какой это радости?
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
допустим за 1 секунду делается 10 измерений тока, и если усреднённо по ним ток немного уплыл то мк также раз в 1 секунду после замеров плавно и немного изменяет выходное напряжение.
Которое к этому моменту просело так, что привело к перегрузу и отключению схемы? И выгоранию диода, если он - лазерный. Ну потому что никто не следил за ростом тока из-за просадки напряжения питания и снижения этих самых 0.5V...
Напомню, что нет никакой стабильности на входе. Это искусственное надуманное условие, не имеющее ничего общего с реальностью. Всегда есть какое-то выходное сопротивление у источника. И эта нестабильность - коррелирована с работой преобразователя, а не просто какой-то там случайный шум.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
В случае питания такой стабильной постоянной по потреблению нагрузки как светодиод и от аккумуляторов такая реализация "простого игнорирования" по-идее должна хорошо работать?
Как генератор? Нагрузка вообще находится за аппаратной ОС преобразователя и нас мало волнует. В отличии от напряжения питания, которое влияет на всё и в противную сторону...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
А такая сложная с расчётами будущего поведения системы в реальном времени нужна именно для сложной нагрузки, и/или нестабильного питания, так получается?
Для ненулевого выходного сопротивления источника питания. Т.е. для любого, если это не сверхпроводниковый генератор или не специальный 4-х проводной лабораторный источник питания.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Я-то продолжал думать что она спокойно работает себе выдавая примерно нужные вольты и сама стабилизируя это напряжение, а мы измеряя ток только немного вносим коррективы в ОС...
Так и есть. Только вот что и как мы вносим то? Описанные эффекты проявляются ведь не на рабочих частотах ОС микросхемы, а значительно ниже - на рабочих частотах ОС МК.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Да хорошо бы так и делать наверное, оставлять микросхему настроенную на выходные допустим 2.5 вольта, и только немного вмешиваться в работу её стандартной ОС согласно току в цепи.
Тогда нужно строить ЦАП со своим ИОН. Или использовать цифровой потенциометр. Только вот мне проще всё же несколько строк кода дописать, чем дополнительные чипы распаивать.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Я вот всё думаю насчёт этого, а разве если бы в микросхеме стабилизатора напряжения была зашита "коррекция ошибки" с коэффициентом меньше 1, например 0.7, разве это не была бы панацея от всех проблем и неважно какое усиление ошибки мы бы сделали?
Это как? 0.7x10=0.7? При чём тут x10? - ну так мы же можем внешне усилить и в x100, что мешает?
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
а микросхема бы просто отработала бы его постепенно как
Т.е. с какого-то перепугу она должна догадаться, что сопротивление её внутреннего интегратора нужно увеличить в 10 раз? И как-то его, собственно, увеличить там. А зачем такие сложности? Чем не нравится внешний вывод для таких задач в контроллерах, которые предназначены для таких извращений?
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Разве не единственное решение которое можно делать если что-то не работает-это просто добавлять больше ёмкости конденсатора?
Даже если это - >1000мкФ?
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Мы что-то ещё можем сделать?
Да - поднять полосу пропускания ОС, чтоб она успевала работать с меньшей ёмкостью. Что я у себя и сделал...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Но если в случае ОС на ОУ?
С токовым монитором? Я ведь с самого начала написал что так - делают. Лепят ёмкости побольше, дроссели пожирнее, и оно вроде бы работает.
INFERION вне форума   Ответить с цитированием Вверх
Поблагодарили: 1 раз
Artik555 (25.12.2020)
Старый 25.12.2020, 01:04   28
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от INFERION :
Это как? 0.7x10=0.7? При чём тут x10? - ну так мы же можем внешне усилить и в x100, что мешает?
Так ведь мы подбираем усиление не просто так, а чтобы получить как раз те самые стандартные для микросхемы 0.5 В после усиления...
Усиливаем мы ведь не напряжение выходное, а падение напряжения, которое допустим в эти 100 раз и ниже напряжения.
Микросхема ведь смотрит напряжение приходящие к ней на пин, а не какое там усиление чего-то там...
Если усиление ОУ подобрано так, чтобы напряжения на его выходе было равно обычному опорному напряжению микросхемы, и изменяется в тех же пределах, в каких оно изменяется в случае обычного для этой микросхемы делителя напряжения, то есть ли вообще какой-то смысл говорить что мы что-то там усилили?

Цитата:
Посмотреть сообщение Сообщение от INFERION :
Ага, и как он будет плевать на своё опорное напряжение, которым и задаёт эти 0.5V? Ну вот есть на входе 4V, ШИМ делит их на 8 и получает 0.5V, и вот вдруг аккум просел на 0.5V - ШИМ посылает нахер всё и продолжает делить на 8, ага?.. И мы должны по прежнему получать 0.5V? С какой это радости?

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


Цитата:
Посмотреть сообщение Сообщение от INFERION :
Да - поднять полосу пропускания ОС, чтоб она успевала работать с меньшей ёмкостью. Что я у себя и сделал...
А в случае аналоговости это как?)


Цитата:
Посмотреть сообщение Сообщение от INFERION :
дроссели пожирнее
Не, дроссель же нельзя, он оптимальным размером индуктивности строго регламентирован, иначе всё повалится...
Выходит только ёмкостью... ну или чем-то ещё.

[Исправлено: Artik555, 25.12.2020 в 01:27]
Artik555 вне форума   Ответить с цитированием Вверх
Старый 25.12.2020, 01:07   29
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

А вот в повышающих микросхемах с обратной связью по току, да и к применённой TPS63020 это тоже относится, она ведь тоже в том числе и повышающая.
В них во всех есть "мягкий/плавный старт"?
Ведь в начальный момент времени ток 0, и напряжение она должна выдать максимальное в момент включения.
Если микроконтроллер не включится раньше и не начнёт до включения схемы уже ей давать сигнал нужный.
Микроконтроллер быстро включается после подачи напряжения в схему?
Какая-то задержка используется для микросхемы?
Artik555 вне форума   Ответить с цитированием Вверх
Старый 25.12.2020, 04:53 Автор темы   30
INFERION

 
Аватар для INFERION
 
Регистрация: 07.04.2013
Последняя активность: 13.06.2023 02:24
Адрес: Украина, Полтава
Сообщений: 5774
Сказал(а) спасибо: 340
Поблагодарили: 8154 раз(а) в 2385 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Так ведь мы подбираем усиление не просто так, а чтобы получить как раз те самые стандартные для микросхемы 0.5 В после усиления...
Усиление постоянному току - да, а обсуждаем при этом - усиление по переменному току... Какой прирост сигнала будет на FB при изменении напряжения на выходе с 4V до 5V? Если делитель напряжения - на резисторах (источник напряжения). А теперь заменим верхний резистор на светодиод (источник тока) - какой будет прирост?.. Что, резкая ВАХ светодиода никак не усиливает ошибку?
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
и изменяется в тех же пределах, в каких оно изменяется в случае обычного для этой микросхемы делителя напряжения, то есть ли вообще какой-то смысл говорить что мы что-то там усилили?
Зачем тогда вообще в схеме этот ОУ, если это - типовая схема из даташита? Обычный источник напряжения с обычным резисторным делителем. А иначе какой смысл это утверждать? Я думал, мы источник тока обсуждаем. А ещё - хитрости обхода его проблем через использование преобразователя как регулируемого источника напряжения. Но потом откуда-то вылезли ОУ, токовые ОС через них и прочее, что отклоняется от этой концепции. При этот продолжаются странные вопросы, имеющие отношение к предыдущей концепции. Тут всё в кучу уже намешано - разбирайтесь...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
А в случае аналоговости это как?)
А в случае "аналоговости" задержка и так - небольшая, а усиление - избыточное (т.к. источник тока же?). Его нужно как-то давить по переменному току. Ссылки на частотную коррекцию я выше уже приводил.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
он оптимальным размером индуктивности строго регламентирован, иначе всё повалится
Почему? В документации приводится рекомендуемый диапазон. Я видел индукторы на 2.2мкГн и вроде даже на 3.3 вместо 1.5. И батарею конденсаторов в несколько раз больше. В источнике тока на TPS63020.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
В них во всех есть "мягкий/плавный старт"?
А понижающим он что, не нужен? Он есть даже в линейных регуляторах.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Ведь в начальный момент времени ток 0, и напряжение она должна выдать максимальное в момент включения.
Ну так есть же ограничение на максимальное заполнение импульсов и ограничение реактивного тока ключа. Ничего катастрофического не произойдёт. Если это не какой-нибудь ZXSC400, конечно...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Микроконтроллер быстро включается после подачи напряжения в схему?
А кто разрешит работу преобразователю то? Пока МК не зарядит RC-цепь, не откалибрует свой шунт, и не проверит всё на допустимость (питание, температура, и т.д.) - никакого сигнала на EN преобразователя не будет.
INFERION вне форума   Ответить с цитированием Вверх
Старый 25.12.2020, 06:43   31
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от INFERION :
Усиление постоянному току - да, а обсуждаем при этом - усиление по переменному току... Какой прирост сигнала будет на FB при изменении напряжения на выходе с 4V до 5V? Если делитель напряжения - на резисторах (источник напряжения). А теперь заменим верхний резистор на светодиод (источник тока) - какой будет прирост?.. Что, резкая ВАХ светодиода никак не усиливает ошибку?
Цитата:
Посмотреть сообщение Сообщение от INFERION :
Зачем тогда вообще в схеме этот ОУ, если это - типовая схема из даташита? Обычный источник напряжения с обычным резисторным делителем. А иначе какой смысл это утверждать? Я думал, мы источник тока обсуждаем. А ещё - хитрости обхода его проблем через использование преобразователя как регулируемого источника напряжения. Но потом откуда-то вылезли ОУ, токовые ОС через них и прочее, что отклоняется от этой концепции. При этот продолжаются странные вопросы, имеющие отношение к предыдущей концепции. Тут всё в кучу уже намешано - разбирайтесь...
Мне до этого казалось что речь всегда была о том, якобы проблема именно в усилении которое создаёт ОУ, например стандартный делитель напряжения для этой схемы делит выходное напряжение в 10 раз, а мы поставили ОУ который что-то там наоборот усиливает в 100 раз, и якобы в этом вся проблема, поэтому и было непонятно.

Если речь о нелинейной ВАХ светодиода(или другой нагрузки) тогда всё понятно.
Выходит в том чтобы получать источник тока из источника напряжения заводя в микросхему падение на шунте через ОУ нет никаких проблем в случае с нагрузкой с линейной ВАХ?
Или основная проблема именно в проседании напряжения на питании..(вроде как нелинейная ВАХ светодиода наоборот должна гасить возбуд(если рассматривать случай с идеальным источником питания для схемы), напряжение скакнуло вверх, ток ещё сильнее скакнул вверх, и микросхема сильнее должна отреагировать на снижение напржения)
И получается источники тока которые вроде как хорошо работают с например нихромовой проволокой могут сума сходить при подключении светодиода?


Цитата:
Посмотреть сообщение Сообщение от INFERION :
Почему? В документации приводится рекомендуемый диапазон.
В даташите на TPS63020 видел конкретные номиналы индуктивности для разных ожидаемых токов потребления.(носящие естественно рекомендательный характер)
Думал с индуктивностью другого номинала сильно снижается КПД.

Цитата:
Посмотреть сообщение Сообщение от INFERION :
А понижающим он что, не нужен?
Перепутал, крутил некоторые понижающие микросхемки которые у меня есть, они с закороченным выходом на пин обратной связи минимум выдавали, а я когда сообщение набирал чёт думал что с оборванной обратной связью минимум выдавали...
А так да, и повышайки и понижайки с нулём на пине обратной связи максимум будут стараться выдавать(если каких защит не встроено), и для тех и для тех это плохо.


Цитата:
Посмотреть сообщение Сообщение от INFERION :
А кто разрешит работу преобразователю то?
А что помешает микросхеме преобразователя стартануть?
Если конечно микроконтроллер ключом вход не разрывает пока выключен.

[Исправлено: Artik555, 25.12.2020 в 07:01]
Artik555 вне форума   Ответить с цитированием Вверх
Старый 25.12.2020, 07:18   32
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Если речь о нелинейной ВАХ светодиода(или другой нагрузки) тогда всё понятно.
Выходит в том чтобы получать источник тока из источника напряжения заводя в микросхему падение на шунте через ОУ нет никаких проблем в случае с нагрузкой с линейной ВАХ?
Или основная проблема именно в проседании напряжения на питании..(вроде как нелинейная ВАХ светодиода наоборот должна гасить возбуд(если рассматривать случай с идеальным источником питания для схемы), напряжение скакнуло вверх, ток ещё сильнее скакнул вверх, и микросхема сильнее должна отреагировать на снижение напржения)
И получается источники тока которые вроде как хорошо работают с например нихромовой проволокой могут сума сходить при подключении светодиода?
Не стал удалять или редактировать то что тут понаписывал, я кажется понял как сформулировать вопрос о том что непонятно, спасибо за терпение
Иии, вот оно:
А откуда вообще берётся устойчивость? Даже просто в случае источника напряжения?
Да, знаю про ПИД, но мною оно воспринимается больше как програмная штука, его эти коэффициенты и действия математические с сигналом.
А в аналоговой схеме? Да, все математические действия можно аналогово реализовать, но вот как именно?(эти действия в схеме производятся, и откуда в ней берётся устойчивость)
В случае источника напряжения всё вроде как понятно, просто методом последовательных приближений корректируется разность между тем что есть и тем что нужно(например 0.7 от разности, затем 0.7 от остатка, и опять 0.7 от уже этого остатка)

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


П.с. ссылку про частотную коррекцию почитаю(только просматривал до этого), если там всё про что я опять и опять спрашиваю то можно лучше на всю эту писанину не отвечать, я прочитаю и перепрошу по-нормальному, если вопрос останется

upd. перечитываю первую страницу, теперь это намного лучше, когда понимаешь чего именно не понимаешь( а читать что-то когда даже не понимаешь чего не понимаешь очень не очень...)
Цитата:
Посмотреть сообщение Сообщение от INFERION :
3. Обратная связь по току O_o.
Спойлер "ос по току", сначала идёт очень хорошо про П, ПИ, ПИД, но потом как-то всё резко скатывается к программной реализации а затем вообще к одним осцилограммам...

По итогу, если без того резкого перехода от вступления про П, ПИ и ПИД к "чёрному ящику", у нас есть конденсатор, и есть зашитая в микросхему "последовательное приближении на 0.7 за шаг" пошагово компенсирующее ошибку
это как бы и есть составляющие ПИД? ПИ? Д есть в каком-то виде в аналоговой схеме?

И про конденсатор, он сглаживает скачки, но "сохраняет тренд", т.е. если был скачёк, то он его сгладил, но напряжение на нём всё-таки поднялось за счёт скачка.
Но вроде это не мешает приходу к устойчивости если есть то самое "пошаговое корректирование ошибки на 0.7"

Есть ещё дроссель, но вроде как это то же самое что конденсатор.. в том смысле если его рассматривать как составляющую ПИД.
Ещё конденсатор и другие элементы не идеальны(есть вообще резисторы), и в них сигнал переходит в нагрев, это тоже часть ПИД?

[Исправлено: Artik555, 25.12.2020 в 07:55]
Artik555 вне форума   Ответить с цитированием Вверх
Старый 25.12.2020, 08:37   33
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

В итоге понял что мне непонятен переход от "принципа" "ПИД" к реальной схеме.
Понял что разницы особой нет, какая реальзация, аналоговая или програмная, когда речь идёт о реальной схеме, а не о простенькой симуляции на компьютере, где кроме этих трёх составляющих "П", "И" и "Д" и собственно самого сигнала над которым этими составляющими оказывается воздействие нету.
В реальной схеме есть не один компонент, иногда целая куча, по оказываемому воздействию соответсвующие какой-то из составляющих ПИД.

Много линейных и нелинейных взаимосвязанных изменющихся переменных, тут и питание с просадками, и нагрузка и микросхема приобразователя, и ос надстаиваемая над ним по току, индуктивность, конденсаторы..
Без полной симуляции модели похоже никак не понять будет устойчивость или не будет и "откуда она там берётся".
Ну или подгонкой долгой.. Или частичной симуляцией и не такой долгой подгонкой если повезёт.
Artik555 вне форума   Ответить с цитированием Вверх
Старый 25.12.2020, 23:24 Автор темы   34
INFERION

 
Аватар для INFERION
 
Регистрация: 07.04.2013
Последняя активность: 13.06.2023 02:24
Адрес: Украина, Полтава
Сообщений: 5774
Сказал(а) спасибо: 340
Поблагодарили: 8154 раз(а) в 2385 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Мне до этого казалось что речь всегда была о том, якобы проблема именно в усилении которое создаёт ОУ
Каким он тут местом к этой проблеме, если он всего лишь согласует уровни сигналов? С самого начала речь шла об усилении сигнала нелинейной нагрузкой на токовом шунте, когда источник напряжения используется как источник тока...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Выходит в том чтобы получать источник тока из источника напряжения заводя в микросхему падение на шунте через ОУ нет никаких проблем в случае с нагрузкой с линейной ВАХ?
В случае с нагрузкой в виде резистора. Только зачем ей такие сложности, если источник напряжения будет проще и эффективнее для питания такой нагрузки?
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Или основная проблема именно в проседании напряжения на питании..(вроде как нелинейная ВАХ светодиода наоборот должна гасить возбуд(если рассматривать случай с идеальным источником питания для схемы), напряжение скакнуло вверх, ток ещё сильнее скакнул вверх, и микросхема сильнее должна отреагировать на снижение напржения)
Короче, фейспалм. Я думал, мы уже обсудили что такое перерегулирование и почему оно приводит к возбуждению...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
И получается источники тока которые вроде как хорошо работают с например нихромовой проволокой могут сума сходить при подключении светодиода?
Да, только зачем ТЭН питать источником тока?
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
А что помешает микросхеме преобразователя стартануть?
Это троллинг? Резистор на 10k, тянущий EN к массе, не должен помешать? Да, он таки есть в схеме... А в новых драйверах я его выкинул за счёт быстрого старта МК.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Да, знаю про ПИД, но мною оно воспринимается больше как програмная штука, его эти коэффициенты и действия математические с сигналом.
Это изначально аналоговая штука. И вообще ВСЕ аналоговые процессы и есть "математические действия с сигналом". А ОУ - это аналоговый вычислительный юнит, на котором строят - аналоговые вычислительные системы: интеграторы, дифференциаторы, сумматоры, вычитатели, умножители, делители, и даже нелинейные функции. И изначально ОУ был придуман именно для аналоговых ЭВМ. Это их логический элемент. И старенький ламповый телевизор или какой-нибудь супергетеродинный приёмник - тоже аналоговая вычислительная машина...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
В случае источника напряжения всё вроде как понятно, просто методом последовательных приближений корректируется разность между тем что есть и тем что нужно
Только во времени этот процесс - непрерывный. И оперировать нужно не дискретами как в цифре, а постоянными времени переходных процессов, и вообще сложными функциями. АЧХ, ФЧХ, полюсами там всякими и т.д. Но суть - та же. Дискретами объяснить проще. Это когда искусственно непрерывный процесс разбиваешь на временные интервалы и сравниваешь точки между ними. Но при этом важно помнить о непрерывности процесса на самом деле. И даже в цифре он на самом деле - непрерывный, и теорема Найквиста это подтверждает. От того, цифровой у нас PID или аналоговый - физика в мире не меняется, и формулы - одни и те же.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
А в случае источника тока откуда устойчивость берётся?
Оттуда же, откуда и в источнике напряжения. Какая разница что контролируется следящей системой? Да хоть скорость автомобиля, хоть температура в холодильнике, хоть ток, хоть напряжение, хоть мощность, хоть положение спутника на орбите - принцип ровно один и тот же...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
В случае источника напряжения получается боремся только с просадкой питания
Нет. Следящая система ничего об источнике питания не знает. Она следит только за выходом и устраняет все возмущения на нём. Не важно из-за чего они - из-за напряжения питания, из-за нелинейностей в самом преобразователе, из-за резкого изменения потребления нагрузкой... Следящая система видит только ошибку регулирования и крутит только один параметр на своём выходе - заполнение ШИМ.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
По итогу, если без того резкого перехода от вступления про П, ПИ и ПИД к "чёрному ящику", у нас есть конденсатор, и есть зашитая в микросхему "последовательное приближении на 0.7 за шаг" пошагово компенсирующее ошибку
это как бы и есть составляющие ПИД? ПИ? Д есть в каком-то виде в аналоговой схеме?
Не пошагово, а условно, за единицу времени. Я не знаю что зарыто под капотом у чипа. Я туда и не лезу, и пишу только о том, что закапываю под капот МК. В этом драйвере две ветки ОС - местная в "микросхеме" и общая через МК, о которой я и пишу. Структурная схема такого преобразователя сложнее чем просто один какой-то регулятор...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Но вроде это не мешает приходу к устойчивости если есть то самое "пошаговое корректирование ошибки на 0.7"
А "микросхема" тут устойчивость и не теряет - теряет общая ОС через МК...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Есть ещё дроссель, но вроде как это то же самое что конденсатор.. в том смысле если его рассматривать как составляющую ПИД.
Это субъект управления, он к следящей системе никакого отношения не имеет. Им следящая система - управляет... И в этой схеме две следящие системы - одна в "микросхеме", вторая в МК. Одна управляет второй, а вторая уже управляет питанием. В таком случае говорят "одна следящая система поверх второй". Вторая система отвечает за быстрые процессы, а первая - за точные.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
В реальной схеме есть не один компонент, иногда целая куча
По хорошему, эта вся куча нейтрализуется так, чтоб для регулятора всё было понятно и линейно. Т.к. регулятор - штука линейная, в отличии от реальной схемы. Вот в этом примере так была нейтрализована RC-цепь на выходе ШИМ. Но, к примеру, с ростом тока усиление ошибки будет расти из-за нарастающей крутизны ВАХ нагрузки, и получается что на больших токах можно потерять устойчивость (перерегулирование), тогда как на малых будет слишком медленная реакция на возмущения (недорегулирование). К примеру, в квадрокоптерах это хорошо заметно при попытке снизиться - на малой тяге КПД винтов сильно растёт и ПИД полётного контроллера начинает колбасить от перерегулирования. При этом на большой тяге он может потерять устойчивость и опрокинуться из-за медленной реакции на крен. А вот делали бы там компенсацию этого эффекта, чтоб ПИД управлял не заполнением ШИМ на моторе, а тягой (в ньютонах, исключив зависимость от скорости, напряжения батареи, температуры двигателя, ветра) - было бы всё гораздо лучше, т.к. оптимальные коэффициенты не зависели бы от конкретных текущих условий. И реализуется это одной ОС поверх другой через линеаризующую функцию. BLDC-контроллер двигателя может самостоятельно следить за током обмоток, а полётный контроллер может управлять этим током. Тяга имеет определённую зависимость - от тока обмоток, а обороты уже как-нибудь сами подстроятся по сопротивлению винта (ветер, скорость и т.п.). При этом контроллер самостоятельно удержит ток вне зависимости от ЭДС мотора (оборотов), сопротивления его обмотки (температуры), напряжения батареи (уровня заряда, нагрузки, состояния и температуры батареи). И самостоятельно пересчитает заданную ему тягу в ток так, что с точки зрения полётного контроллера - привод всегда даёт определённый прирост тяги на сигнал воздействия. А если ещё и все единицы измерения будут системными (ток в реальных амперах, тяга в реальных ньютонах, масса в реальных килограммах и т.д.) - тогда не сложно дописать инерциальную модель всего дрона и полётник сам найдёт все необходимые коэффициенты, когда попытается поуправлять своей тушкой. Да ещё и закомпенсирует эту инерцию.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Много линейных и нелинейных взаимосвязанных изменющихся переменных, тут и питание с просадками, и нагрузка и микросхема приобразователя, и ос надстаиваемая над ним по току, индуктивность, конденсаторы..
С подключением ...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Ну или подгонкой долгой..
Это хрень. Проще рассчитать всё. При подгонке оно будет хорошо работать в одном режиме и плохо в другом, и попробуй пойми что не так и как заставить работать одновременно во всех режимах.

P.S. Я как-то с симуляторами не сдружился. Простое считаю калькулятором и бумажкой, более сложное описываю на Си в MS VS. Всё равно этот код потом копипастится в МК и точно так же симулирует уже реальную живую схему, в которой работает. На лету. Это необходимо для максимально полной компенсации всех косяков схемы. В итоге - мне даже подбирать коэффициенты не нужно - в ПИД вшит весь матан, который сам всё считает.

[Исправлено: INFERION, 26.12.2020 в 00:00]
INFERION вне форума   Ответить с цитированием Вверх
Поблагодарили: 2 раз(а)
Artik555 (26.12.2020), D'AVerk (25.12.2020)
Старый 26.12.2020, 00:09   35
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

INFERION, спасибо за подробное разъяснение
Artik555 вне форума   Ответить с цитированием Вверх
Старый 26.12.2020, 00:38   36
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от INFERION :
1. Шум АЦП.
Скажите, а под этим спойлером всё так страшно, потому что управляющая программа пишется на ассемблере?
Вроде как другие языки это условно говоря набор команд, вызывающие за одну команду целые готовые функции как из библиотек.

Я думал управляющая программа(этот её кусок) будет иметь вид что-то вроде "опросили ацп(если надо просто опросили несколько раз складывая результаты и разделили на количество замеров) прогнали то что получилось через математику ПИДа, основываясь на результате выдали шим который даст нужное напряжение на выходе RC-фильтра.
На других языках более высокого уровня оно так и будет, без спускания к настолько фундаментальной теории работы с АЦП и другими узлами?
Или точно так же придётся всё это в программе описывать?
Artik555 вне форума   Ответить с цитированием Вверх
Старый 26.12.2020, 02:11 Автор темы   37
INFERION

 
Аватар для INFERION
 
Регистрация: 07.04.2013
Последняя активность: 13.06.2023 02:24
Адрес: Украина, Полтава
Сообщений: 5774
Сказал(а) спасибо: 340
Поблагодарили: 8154 раз(а) в 2385 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Скажите, а под этим спойлером всё так страшно, потому что управляющая программа пишется на ассемблере?
Нет, потому что это всё и правда необходимо. Только пост старый, сейчас я делаю по другому. В простейшем случае это асинхронная работа АЦП и ШИМ с соотношением частот, равным простому числу, при этом частота ШИМ существенно выше частоты выборок АЦП. В фонариках работает хорошо. При высоких требованиях к SNR (в акустике, к примеру) - опять используется жесткая синхронизация, но применяются уже взрослые кодеки вместо хренового АЦП МК.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Вроде как другие языки это условно говоря набор команд, вызывающие за одну команду целые готовые функции как из библиотек.
Там то же самое. А делать ставку на готовые библиотеки у меня вообще ни разу ещё не получалось. Очень мало хороших либ. Могу вспомнить только ffmpeg и gnuplot. Может быть вот подружусь ещё с uIP или lwIP. В общем случае - если нужно что-то сделать хорошо - делать нужно самому. В среде программистов много мемов ходит про open source...
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
опросили ацп(если надо просто опросили несколько раз складывая результаты и разделили на количество замеров) прогнали то что получилось через математику ПИДа, основываясь на результате выдали шим который даст нужное напряжение на выходе RC-фильтра.
Приблизительно так программисты и делают, да. А потом героически воюют с проблемами или "и так сойдёт".
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
На других языках более высокого уровня оно так и будет, без спускания к настолько фундаментальной теории работы с АЦП и другими узлами?
Нет, не будет. Будут дополнительные усложняющие слои абстракции, через которые придётся пробираться, чтоб сделать что-то так, как тебе надо, а не как умеет инструмент в этом языке. Простые не требовательные задачи, или сложные но совсем попсовые (и хорошо отлаженные в их либах), на высоком уровне абстрагирования может быть и решаются проще и быстрее. Мне и Си слишком высокоуровневый, но с ним я воевать уже как-то привык, а кому-то и ардуины хватает.

[Исправлено: INFERION, 26.12.2020 в 02:14]
INFERION вне форума   Ответить с цитированием Вверх
Поблагодарили: 1 раз
Artik555 (26.12.2020)
Старый 26.12.2020, 17:25   38
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от INFERION :
Ага, и как он будет плевать на своё опорное напряжение, которым и задаёт эти 0.5V? Ну вот есть на входе 4V, ШИМ делит их на 8 и получает 0.5V, и вот вдруг аккум просел на 0.5V - ШИМ посылает нахер всё и продолжает делить на 8, ага?.. И мы должны по прежнему получать 0.5V? С какой это радости?
А в готовых микросхемах ЦАП разве нет встроенного источника опорного напряжения?

А в микроконтроллере есть встроенный источник опорного напряжения?
Где-то видел вы, или не вы, писали что он там что-то около 1.3 В, плюс ему нужна разница 1 В для надёжной работы, итого пока аккумулятор не просядет до 2.3 вольт всё должно быть хорошо по идее же?
Ну это если написать программу выдающую сигнал цап с помощью шим микроконтроллера, сверщуюся с собственным ион.
А вслучае использования отдельной микросхемы цап наверное и так всё должно быть хорошо, я думал их смысл и так в том и заключается, чтобы аыдавать стабильное необходимое напряжение на выходе, несмотря на изменение питания, в определённых пределах, естественно.
Artik555 вне форума   Ответить с цитированием Вверх
Старый 26.12.2020, 18:43 Автор темы   39
INFERION

 
Аватар для INFERION
 
Регистрация: 07.04.2013
Последняя активность: 13.06.2023 02:24
Адрес: Украина, Полтава
Сообщений: 5774
Сказал(а) спасибо: 340
Поблагодарили: 8154 раз(а) в 2385 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от Artik555 :
А в готовых микросхемах ЦАП разве нет встроенного источника опорного напряжения?
Смотря каких. Если нужен ЦАП с ИОН - ищите ЦАП с ИОН... Мы обсуждали ШИМ МК, а у него никакого ИОН - нет. Его чаще всего нет и у АЦП с ЦАП в МК.
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
А в микроконтроллере есть встроенный источник опорного напряжения?
У AVR есть у АЦП (и на том спасибо).
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Где-то видел вы, или не вы, писали что он там что-то около 1.3 В, плюс ему нужна разница 1 В для надёжной работы, итого пока аккумулятор не просядет до 2.3 вольт всё должно быть хорошо по идее же?
Это у AVR, и там 1.1V. У STM32, к примеру, ИОН нет, а если и есть - 2.5V. Ниже нельзя, но и АЦП имеет разрешение в 4 раза больше чем у AVR (и существенно выше частоту дискретизации и вообще больше аппаратных возможностей).
Цитата:
Посмотреть сообщение Сообщение от Artik555 :
Ну это если написать программу выдающую сигнал цап с помощью шим микроконтроллера, сверщуюся с собственным ион.
Это будет хуже и медленнее, чем выделить все ресурсы АЦП исключительно на ОС по току.
INFERION вне форума   Ответить с цитированием Вверх
Старый 27.12.2020, 06:05   40
Artik555
Увлеченный
 
Регистрация: 07.03.2020
Последняя активность: 18.06.2021 20:15
Сообщений: 302
Сказал(а) спасибо: 54
Поблагодарили: 5 раз(а) в 5 сообщениях

По умолчанию Re: Программная реализация драйвера на примере Indigo 3.0s

Цитата:
Посмотреть сообщение Сообщение от INFERION :
У AVR есть у АЦП (и на том спасибо).
А, т.е. это не общий какой-то ион мк, для всяких разных дел, а исключительно ион встроенного в мк АЦП, и его ни для каких других дел использовать не получится?
Artik555 вне форума   Ответить с цитированием Вверх
Ответ  Создать новую тему
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск





Copyright ©2007 - 2024, FONAREVKA.RU

Powered by vBulletin®
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd. Перевод: zCarot

Правила форума | Отказ от ответственности
Время генерации страницы 0.27381 секунды с 17 запросами