Перейти к содержанию
    

Сомнения: доверять или не доверять AVR управление H-bridge

У меня в 2 экземплярах внутренний хреновил при -10. Поэтому предпочитаю на серъезные вещи кварц ставить.

Насчет применений в БП в мостах и проч где имеем дело с мощными помехами, я солидарен с Rst7 - никаких кварцев!

насчет -10 разве это проблема? МК может сам себя нагревать, портом об землю вот вам уже -10 а +30. :)

 

PS: если серьезно думаецо не RC хреновил, а что-то другое хреновило.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

еще советую дроссель на выходе

Изменено пользователем Paulina

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Насчет применений в БП в мостах и проч где имеем дело с мощными помехами, я солидарен с Rst7 - никаких кварцев!
+1000

На "горячей" стороне никаких кварцев быть не должно...

Внутренний RC рулит, если нужно при этом связь с компомпом, тогда что-нить типа как предложил

Rst7 в посте N 5, только я бы коррекцию не делал в прерывании, неправильно это ИМХО...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Тут несколько выше решили, что аппаратную защиту от одновременного открывания верхнего и нижнего полумоста нужно оставить. Т.о. КЗ исключается. Оно может возникнуть лишь при пробоях транзисторов. Конечно остается только надеяться, что в этот момент не зависнет МК. Но если он даже и завис, есть еще предохранитель. Да и сам БП, ссылку на который я приводил выше, имеет защиту от перегрузок. Но вообще над этим пунктом нужно конечно подумать.

 

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

Ну тогда LC фильтр и супрессоры.

Читаю, думаю... но и здесь консультируюсь.

 

Чтож, Вы

Насчет применений в БП в мостах и проч где имеем дело с мощными помехами, я солидарен с Rst7 - никаких кварцев!

и Вы

 

+1000

На "горячей" стороне никаких кварцев быть не должно...

окончательно меня убедили! Никаких кварцев!

Rst7 в посте N 5, только я бы коррекцию не делал в прерывании, неправильно это ИМХО...

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

 

 

 

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

 

И еще: Всем, абсолютно Всем спасибо за Ваши советы, рекомендации и здоровую критику!!! Я очень Вам благодарен!!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

 

1.Товарисч со странным именем ПИПЕЦ недоговорил - он явно использовал независимый верхний и нижний драйвера в одном корпусе - там deadtime и не пахнет.

2. Мне все-таки оч. интересно, зачем в хозяйстве этом, в данном конкретном случае гальваническая развязка :lol:

3. Про внутренний RC с внешним синхрогенератором +1000.

4. Продолжение - в исходной теме :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тут несколько выше решили, что аппаратную защиту от одновременного открывания верхнего и нижнего полумоста нужно оставить. Т.о. КЗ исключается. Оно может возникнуть лишь при пробоях транзисторов. Конечно остается только надеяться, что в этот момент не зависнет МК. Но если он даже и завис, есть еще предохранитель. Да и сам БП, ссылку на который я приводил выше, имеет защиту от перегрузок. Но вообще над этим пунктом нужно конечно подумать.

Читаю, думаю... но и здесь консультируюсь.

Дедтайм защищает не от КЗ, а от сквозного тока. Нет никакой гарантии, что в момент КЗ (в нагрузке, интереснее всего в ёмкостной) от броска тока (ЭМИ) процессор не зависнет. У меня была важна живучесть и надежность (приборы ушли на серьёзный борт).

 

1.Товарисч со странным именем ПИПЕЦ

Есть и более странные - _ПАША, например...

недоговорил - он явно использовал независимый верхний и нижний драйвера в одном корпусе - там deadtime и не пахнет.

Проверил (вчера не было под рукой архивов, а дело происходило лет пять назад) - я применил одновходовый драйвер с внутренним расщепителем. Тоже из серии IR21xx.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Почему? Ведь прерывание как раз гарантируем нам, что синхронизация будет происходить в любом случае каждые n секунд, и не какой процесс не сможет помешать этому, если конечно не выключит прерываыния глобально.
ИМХО, не очень правильно подстраивать частоту во время передачи по UART,

а это иногда будет происходить, хотя наверное и будет работать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

ИМХО, не очень правильно подстраивать частоту во время передачи по UART,

а это иногда будет происходить, хотя наверное и будет работать.

 

Обоснуйте? Я же меняю не UBRR, а немного подстраиваю частоту задающего RC-генератора. В даташитах (особенно последних) есть указание, что за один раз не следует менять частоту более чем на сколько-то процентов. 1 у.е. регистра OSCCAL - это меньше этого порога, посему никакого криминала нет. Кстати, не так давно появился апнот у атмела с аналогичным содержанием (я то пользуюсь данной фичей уже много лет). Можете найти там все ответы на интересующие Вас вопросы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Обоснуйте? Я же меняю не UBRR, а немного подстраиваю частоту задающего RC-генератора. В даташитах (особенно последних) есть указание, что за один раз не следует менять частоту более чем на сколько-то процентов. 1 у.е. регистра OSCCAL - это меньше этого порога, посему никакого криминала нет. Кстати, не так давно появился апнот у атмела с аналогичным содержанием (я то пользуюсь данной фичей уже много лет). Можете найти там все ответы на интересующие Вас вопросы.
Мне просто не очень нравится перестройка частоты мк во время приема по UART(+-2% в

худшем случае), конечно для маленьких скоростей UART это явно не критично,

HO, учитывая изначальную ошибку для больших скоростей на 8Мгц тактовой

и учитывая что ошибка на 2 стороне тоже может присутствовать,

ИМХО, перестройку тактовой нужно делать не в моменты передачи, и

возможно лучше путем мониторинга времянок на UART(тогда и низкоскоростной кварц вроде как и не

нужен).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

конечно для маленьких скоростей UART это явно не критично,

 

Это не критично для любых скоростей - шаг настройки менее 1 процента. Вопрос не в абсолютном изменении частоты, а в относительном.

 

ИМХО, перестройку тактовой нужно делать не в моменты передачи

 

Повторяю - не важно, в какой момент происходит подстройка частоты. Главное, чтобы за время между двумя перестройками частота не изменилась более чем на 2% - тогда все будет пучком. А т.к. частота зависит в основном от температуры (питание от любого вменяемого стабилизатора уже мало влияет), то (из-за медленного изменения температуры по сравнению с циклом подстройки) подстройка частоты всегда будет обеспечивать требуемый результат.

 

и возможно лучше путем мониторинга времянок на UART(тогда и низкоскоростной кварц вроде как и ненужен).

 

Такой вариант тоже допустим - АПЧ по длительности битов в UART. Только сложнее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

грубо говоря, если скачок произошел на первом бите то и все последующие

будем ловить со сдвигом... а если было изначальное несоответствие частот +

%ошибки на 2 стороне...

Повторяю - не важно, в какой момент происходит подстройка частоты. Главное, чтобы за время между двумя перестройками частота не изменилась более чем на 2% - тогда все будет пучком. А т.к. частота зависит в основном от температуры (питание от любого вменяемого стабилизатора уже мало влияет), то (из-за медленного изменения температуры по сравнению с циклом подстройки) подстройка частоты всегда будет обеспечивать требуемый результат.
Я согласен с тем что в нужный диапазон мы вписываемся, мне

просто не очень нравится метод...

Такой вариант тоже допустим - АПЧ по длительности битов в UART. Только сложнее.

Сложнее, но ИМХО правильнее, а еще лучше для связи с "горячей" частью использовать

совсем не UART.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

если скачок произошел на первом бите то и все последующие будем ловить со сдвигом... а если было изначальное несоответствие частот + %ошибки на 2 стороне...

 

Ну тут конечно допустимая ошибка на другой стороне должна быть не более обычной максимальной ошибки (это примерно 4% для 10 бит) минус неточность нашей подстройки (не более 1%) - т.е. грубо говоря 3%. Следовательно, даже 2 устройства с подстраиваемыми RC-генераторами будут работать при любых условиях.

 

мнепросто не очень нравится метод...

 

Не нравится - не пользуйтесь. Главное - неправильные посылы в неокрепшие умы не закладывайте :)

 

Сложнее, но ИМХО правильнее,

 

Ингода сложность реализации может пересилить все прелести... А прелесть одна - минус одна линия связи (референсная частота). Все остальное - тоже самое или сложнее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну тут конечно допустимая ошибка на другой стороне должна быть не более обычной максимальной ошибки (это примерно 4% для 10 бит) минус неточность нашей подстройки (не более 1%) - т.е. грубо говоря 3%. Следовательно, даже 2 устройства с подстраиваемыми RC-генераторами будут работать при любых условиях.
По своему опыту, закладываться можно не более чем на 1,5% на одной стороне.

да и в конечном итоге, сделать так чтобы подстройка частоты в Вашем варианте была

не во время передачи, это всего лишь 1 лишний флаг и одна проверка...

Не нравится - не пользуйтесь. Главное - неправильные посылы в неокрепшие умы не закладывайте :)

Ингода сложность реализации может пересилить все прелести... А прелесть одна - минус одна линия связи (референсная частота). Все остальное - тоже самое или сложнее.

Ну вроде как я предлагаю неокрепшим умам просто дополнительные варианты...

Наверное я подстрекатель... :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По своему опыту, закладываться можно не более чем на 1,5% на одной стороне.

 

Нет проблем. Особенно, с учетом того, что можно подстоиться не на ровно 8МГц, а на частоту, хорошо делящююся для UARTа - например для 115200 - 7.3728 МГц или 9.216МГц. Или, что ближе, использовать 2X, и настроиться на частоту 8.2944МГц.

 

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

 

Предлагаю данный флуд прекратить, или попросим модераторов вынести наше обсуждение в отдельный тред.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...