LINUX.ORG.RU

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

 , ,


1

3

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

Вроде получается намного проще поставить 2 микроконтроллера с отдельными питаниями, и соединить цифровым каналом (тогда надо всего 2 опторазвязки). Один контроллер на силовую часть, и второй на ручки-кнопочки. Звучит странно, но проще и по деталям и по размерам.

А теперь вопрос - есть ли для C и/или Rust решения, чтобы прозрачно прокидывать пины, АЦП и UART в подобных связках? То есть, чтобы дергать в коде регулятора HAL и не заморачиваться, что данные на самом деле берутся из буфера, куда они прилетели от другого микроконтроллера.

Можно конечно на коленке это все накостылять, но что-то мне подсказывает, что подобное должны были давно сделать и как следует отладить.

★★★★★

Минут пять пытался понять, что имеется в виду. Если настоящий вопрос звучит как «существуют ли протоколы удаленного доступа к устройствам по непонятного вида цифровым каналам», то мне такие неизвестны. Если «цифровой канал» нестандартный, костылить транспорт придется по-любому.

tailgunner ★★★★★ ()

То есть, чтобы дергать в коде регулятора HAL и не заморачиваться, что данные на самом деле берутся из буфера, куда они прилетели от другого микроконтроллера.

Пахнет жутким извратом. Когда я добавлял ПИД-регулятор на МК к контроллеру бесколлекторного двигателя (высоковольтная часть), развязывал оптопарами лишь сигналы обратной связи (3 датчика Холла, цифровой сигнал) + сигнал управления (аналоговая оптопара).

Кстати, есть изолирующие ОУ, если сигнал обратной связи слаб.

TwisteR ★★ ()
Ответ на: комментарий от tailgunner

«существуют ли протоколы удаленного доступа к устройствам по непонятного вида цифровым каналам»

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

Есть возможность поставить 2 одинаковых контроллера, и хотеть «если я читаю ADC1, то чтобы читался ADC1 с другого микроконтроллера». Еще более абстрагированного (когда скрещиваются разные девайсы произвольным образом) удаленного доступа не надо.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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

Однонаправленный? Как минимум один из нас ничего не понимает.

tailgunner ★★★★★ ()
Ответ на: комментарий от TwisteR

Ну вот посчитай, сколько деталек набежит, особенно если вместо датчиков холла надо мерять back EMF. И потом сравни с «один контроллер, один кварц и один оптрон»

Vit ★★★★★ ()
Последнее исправление: Vit (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Однонаправленный? Как минимум один из нас ничего не понимает.

Ну, например, UART прокатит (там раздельные линии Rx и Tx), а 1-Wire или I2C — нет.

TwisteR ★★ ()
Ответ на: комментарий от tailgunner

Например TX + RX от UART. Каждая линия однонаправленная, изолируется через оптрон. Канал - двунаправленный.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

И потом сравни с «один контроллер, один кварц и один оптрон»

Ну это если совсем без защиты входов, что, конечно, не ок...

Получается, вам надо нечто вроде прозрачной сериализации/десериализации периферии. Увы, мне ничего из этой области не попадалось.

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

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

А зачем USB со стороны контроллера мотора? Разве не регулятор вырабатывает управляющий контроллером сигнал?

TwisteR ★★ ()
Последнее исправление: TwisteR (всего исправлений: 1)

Ты хочешь неправильного. Время доступа к пинам, АЦП и UART локально и на удалённом контроллере будет, мягко говоря, несколько различаться. Тебе надо не устройства прокидывать, а более высокоуровневую логику.

Begemoth ★★★★★ ()
Ответ на: комментарий от TwisteR

Насчет USB переборщил, да. Но в общем случае выходит так:

аналоговые:

- 3 вывода мотора
- питание
- токовый шунт

цифровые:

- 3 сигнала на драйверы

Итого - нужна оптоизоляция 5 аналоговых сигналов и 3 цифровых. Посчитай обвес, и тогда идея со вторым микроконтроллером покажется не такой уж и некрасивой :). А еще прикинь, насколько проще собирать в хоббийных условиях, когда меньше деталей.

Vit ★★★★★ ()
Ответ на: комментарий от Begemoth

Ты всерьез считаешь, что надо особенно быстро реагировать на нажатие кнопки и поворот ручки :) ?

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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

Если в твоём случае время отклика не важно, то это частный случай. Если потеря связности системы в твоем случае не важна - это тоже частный случай.

Begemoth ★★★★★ ()
Ответ на: комментарий от Begemoth

Я просто ищу оптимальное решение для конкретной задачи, а не изобретаю теорию всеобщего всего. Конкретная задача - всегда частный случай.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Так и контроллер мотора и регулятор проектируются с нуля?

Ведь обычно как делают: контроллер находится в «высоковольтной» части и заведует коммутацией обмоток и считыванием обратной ЭДС (по которой и синхронизируется коммутация).

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

Получается чёткое разграничение полномочий:

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

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

Изоляция между ними тривиальна, хватит и двух оптопар для UART (в сторону контроллера улетает нужная на данный момент частота вращения, а от него принимается уже оцифрованный текущий уровень обратной ЭДС).

TwisteR ★★ ()
Последнее исправление: TwisteR (всего исправлений: 2)
Ответ на: комментарий от TwisteR

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

TwisteR ★★ ()

Насколько я знаю нет.

Но ты можешь взять форт, вытащить через развязку uart и командовать фортом из контроллера.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от TwisteR

Так и контроллер мотора и регулятор проектируются с нуля?

С нуля. Под хоббийные задачи. С упором на хорошую повторяемость. Вот тут можно временно посмотреть мои влажные фантазии https://gist.github.com/puzrin/6fb783460ce1c3b07777bca6f0e069b5

Ведь обычно как делают: контроллер находится в «высоковольтной» части и заведует коммутацией обмоток и считыванием обратной ЭДС (по которой и синхронизируется коммутация).

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

Наверное мы в терминах расходимся. У меня реалтаймавая часть - это микроконтроллер с ПИД-регулятором, драйверами ключей и самими ключами.

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

Если подумать, и индикатор брать типа nextion, то в «контроллере кнопочек» все сведется к пробросу uart + пары кнопок и ручки. Довольно просто.

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

Vit ★★★★★ ()
Ответ на: комментарий от curufinwe

у тебя на uart висит интерпретатор форт, чего ещё надо? написал себе слов которые оборачивают отсылку команд в другой контроллер и программируй себе почти как единую систему.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от anonymous

Вот то же самое подумал. А ТС чего-то непонятного хочет.

Кстати, CAN умеют даже 50-рублевые STM8 (правда, там он не совсем полноценный) и STM32 (а здесь все ОК; STM32F042 одновременно может и CAN, и USB!)!

anonymous ()
Ответ на: комментарий от anonymous

почему на лоре ещё анонимусов не забанили?

Большинство регистранты, кто то бывшие, кто то текущие.

Инфа 146%.

ТС, у тебя там сильно высокие килловольты? Может оптический кабель поможет?

burato ★★★★ ()
Ответ на: комментарий от anonymous

Использовать CAN для соединения _двух_ устройств, всего двух, это, конечно же, признак исключительного ума, куда уж регистрантам до вас ))) Хорошо что не Ethernet.

curufinwe ★★★★★ ()
Ответ на: комментарий от Vit

Посмотри в сторону I2C переферии. Для этого интерфейса есть АЦП, ЦАП и ШИМ как минимум (представляю, что может потребоваться для твоих задач, на самом деле I2C устройств гораздо больше). Если скорости хватит - то по двухпроводной шине получишь всё, что хочешь.

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

АЦП, ЦАП и ШИМ как минимум

Но зачем? Это все реализует второй контроллер, копеечный и один. Смысл заменять его на ворох отдельных устройств. Нужно просто с минимальными затратами связать два контроллера через гальваническую развязку, чтобы прошивка второго контроллера, внутри изоляции, видела UART и порт GPIO внешнего как родные, через слой абстракции. Есть такие готовые программные решения?

То, что можно все сделать вручную на своем собственном протоколе обмена между контроллерами, и так понятно. Пробросить UART с одного контроллера на другой тоже тривиально, но тут вместе с ним еще GPIO нужен. Изначальный вопрос, есть ли готовое решение.

curufinwe ★★★★★ ()
Ответ на: комментарий от anonymous

STM32F042 одновременно может и CAN, и USB!

Не всякий. В мелких корпусах (36 ног) - не могут одновременно.

Beewek ()

есть ли для C и/или Rust решения

А чой-то не на JS? Тебе самое то будет.

anonymous ()
Ответ на: комментарий от Vit

Если схема будет произведена в единственном экземпляре, то стоит поставить 5 каналов аналоговой гальваноразвязки и все будет отлично. ну и три оптрона в обратку.

я ставил IL300 несколько лет назад в один заказ(4 приборчика всего, думать многА не хотелось). они конечно стоили каких-то денег, но все развязки запустились с полпинка, точность была отличная, и до сих не вылетели (по крайней мере не было требований ремонта). поставил - забыл.

ну а если думать над отдельным процом около движка, то на мой взгляд стоит тогда все управление движком вынести на него, и с главного проца лишь посылать «высокоуровневые» команды управления. вот такую готовую систему уже можно найти в тырнете.

pfg ★★★★ ()
Ответ на: комментарий от curufinwe

Использовать CAN для соединения _двух_ устройств, всего двух, это, конечно же, признак исключительного ума, куда уж регистрантам до вас ))) Хорошо что не Ethernet.

как бе, почитай спеку..: CAN лучше себя чувствует от меньшего количества устройств.

а поциент хочет меньше проводов, которых в CAN - по минимуму.

так что, таки так: CAN - идеальный кандидат под данные условия.

anonymous ()

Вообще, звучит так, что тебе нужны контроллеры TI на управление током, и stm - на UI.
И тогда ты только команды с ui развчзываешь.

Shadow ★★★★★ ()
Ответ на: комментарий от Shadow

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

anonymous ()
Ответ на: комментарий от Shadow

Ты не поверишт, видел, как в транспорте CAN заменяли на ethernet.

Случаем, не на EtherCAT? Очень крутая идея в основе, про подмешивание данных на лету в пролетающий мимо слейва пакет :)

TwisteR ★★ ()
Последнее исправление: TwisteR (всего исправлений: 1)
Ответ на: комментарий от anonymous

так что, таки так: CAN - идеальный кандидат под данные условия.

А почему не UART?

curufinwe ★★★★★ ()
Ответ на: комментарий от TwisteR

Нет, там can засунули в rs485 который засунули в moxa девайс в военном исполнении. Причем, расстояние было достаточное для rs485.

Shadow ★★★★★ ()

Чё-т я совсем ННП. Чем так принципиально избитая и проверенная вариация SPI с опторазвязкой не подходит?

Oberstserj ★★ ()
Ответ на: комментарий от Vit

Вот тут можно временно посмотреть мои влажные фантазии

читаю и вижу следующее:

  • бормашинками
  • сверлилками и пилилками

-это на обычных DC-моторах?

  • всякими поделками на моторах от стиралок
  • старыми станками (асинхронники?)

-это уже другая опера, другие движки

  • модельных бесколлекторников.

- еще одни другой тип двигателя.

Ты можешь конкретнее определеиться с типом двигателей, которыми ты хочешь управлять? У тебя в фантазиях устройство, которым ты хочешь управлять разными типами двигателей с разными номиналами и родами тока? Или я чего-то не понял?

Хочется чтобы проекты «взлетели». Для этого они должны быть доступными в своей простоте

Спорное утверждение.

лично я предпочитаю aliexpress, но навязывать выбор не буду.

С каких пор на алях хоть что-то стоящее стали продавать? Чем так принципиально не нравится дигикей?

Простота важнее цены.

Если делается обновление прошивок - желательно вообще без программ. Например, перезаписью файла на USB-диске.

Мда...

Надо подумать над самотестированием и индикацией, например светодиодиком мигать о битом ключе.

Это должно быть отдельное устройство.

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

Эмм...очередное спорное требование.

Просто ручка, крутить скорость, без индикации

С контролем прегрузки

Опять противоречия. Мда-2.
В общем до постановки нормального ТЗ еще далеко.

Oberstserj ★★ ()

А зачем 2 развязки? Одной же хватит. И 2 микроконтроллера - тоже излишество. Оставь один контроллер, развяжись от силовой или от интерфейсной части гальваническими развязками и все.

Готовые развязки у Analog посмотри, если двигатель будешь изолировать, то что-то из этого подойдет

http://www.analog.com/en/products/interface-isolation/isolation/isolated-gate...

если кнопки и интерфейсы - то

http://www.analog.com/en/products/interface-isolation/isolation/spisolator.html

http://www.analog.com/en/products/interface-isolation/isolation/standard-digi...

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

aiqu6Ait ★★★ ()
Последнее исправление: aiqu6Ait (всего исправлений: 1)
Ответ на: комментарий от aiqu6Ait

Спасибо за ссылки. Я думал ADUM1201 на UART воткнуть, не знал что есть для SPI и т.п.

Насчет того, почему 2 микроконтроллера - подсчеты давал тут Посоветуйте как прокинуть периферию между микроконтроллерами. (комментарий).

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

Может знаешь другие способы как по простому с развязкой обмерять 5 сигналов?

Vit ★★★★★ ()
Ответ на: комментарий от Vit

5-канальный (условно) АЦП запитать через развязанный источник, данные по SPI снимать через развязку. Если сигналы не быстро изменяющиеся - все будет работать.

Есть еще гальванически развязанные АЦП у того же Аналога.

aiqu6Ait ★★★ ()
Последнее исправление: aiqu6Ait (всего исправлений: 1)
Ответ на: комментарий от aiqu6Ait

Так он ровно то же самое и предлагает. Только вместо АЦП микроконтроллер. Который имеет больше 16 каналов АЦП, плюс аппаратный ШИМ для управления силовыми транзисторами параллельно с измерением. Плюс процессор для реализации ПИД-регулятора, что снимает вообще необходимость прокидывать измеренные сигналы через развязку целиком и решает кучу проблем.

И все это стоит дешевле отдельного АЦП.

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

curufinwe ★★★★★ ()
Ответ на: комментарий от aiqu6Ait

Дык по деталькам посчитай, что выйдет. Тут предлагается целиком дополнительный STM32 засунуть с отдельным источником и развязанным каналом (SPI или UART через ADUM). На все сразу.

IMHO обычная арифметика. Выгодно со всех сторон кроме программирования. Но с программированием трудности не фатальные.

Кстати, а ты случайно не можешь подсказать модули AC-DC 15v? Есть очень распространенные hilink и tsp, но они только до 12 вольт, а мне надо именно 15. На крайний случай есть такие, но хотелось бы менее махрового китая.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Драйверы у тебя сколько стоят?

АЦП можно и обычный за SPI через ADUM засунуть, а драйвера взять гальванически развязанные. Зато никаких проблем с программированием и с отладкой.

aiqu6Ait ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.