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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

аналоговые:

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

цифровые:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То есть форт пробрасывается через UART? Где подробнее почитать можно?

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

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

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

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

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

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

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

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

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

CAN?

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

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

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

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

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

Инфа 146%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А почему не UART?

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

У нас подобная аритектура. Два контроллера, между ними просто SPI с опторазвязкой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мда...

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

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

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

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

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

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

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

А на чем развязка SPI сделана?

А зачем 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...

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

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

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

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

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

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

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

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

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

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

две оптопары скорее всего. там же miso/mosi

А SCK кто будет развязывать? Три получается.

Да, клок забыл.

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

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

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

Блок питания

http://www.mean-well.ru/store/PS-05-15/

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

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