Вкатываюсь в embedded как хобби. Arduino vs STM32

Что значит «нет нифига»? Самый общепринятый способ общения: отправляешь идентификатор, а затем — данные. Вуаля! Тупо строка данных, как и по RS-232. Только в 485 нельзя мультимастер.

Как ни странно, но тут я везде согласен с Эдиком. Беспровод – зло. CAN наше всьо. Ну… На крайняк LoRa можно попробовать, если хочешь железяками на другом конце города рулить. RS-485 тоже не слушай, зачем это говно мамонта кому нужно, когда в любом STM чипе есть аппаратный CAN ?

Трехсотрублевый переходник CAN-USB с гальваноразвязкой. Сейчас, правда, т.к. чипы на порядок подорожали, а остальные компоненты — в 2-3 раза, получится подороже…

Как говорится, знал бы прикуп! Надо было хотя бы пятьсот STM32F072CBT6 прикупить 2 года назад, пока они еще по 65-75 рублей за штучку были!

Надо было хотя бы пятьсот STM32F072CBT6 прикупить 2 года назад, пока они еще по 65-75 рублей за штучку были!

... и барыжить ими сегодня через закладки!

Как бы и да, но колхоз же.

Линукс - это не про реалтайм. Но таки да, да примеров см. Lichee Pi и статьи про линукс на визитке.

даже 100 миллисекунд для робота это реалтайм, а там 4 ядра на гигагерцовых частотах

Cortex с линуксом сейчас стоит копейки

И пока-пока реальное время. Отлично просто.

Да все в наличие https://www.nxp.com/assets/images/en/block-diagrams/IMX8X-BD.png, + 2 гигабитных эзернета

С другой стороны, те же «апельсинки-нуль» — отличная штука для того, чтобы добавить ethernet к своей плате на STM32! Я так уже кучу железок наделал разнообразных: железяки своим делом занимаются, по USB сбрасывают данные «апельсинке», а та уже обеспечивает торчащий наружу сокет и при необходимости - статический веб на nginx’е или самописном серваке.

И это будет дешевле полутора тысяч рублей?

Человек хочет программировать робота. В питоне есть такие вещи:

Achieve high performance for articulated dynamic systems using Lie Group representation and Featherstone hybrid algorithms. Enforce joints between body nodes exactly using generalized coordinates.

Provide comprehensive API for dynamic quantities and their derivatives, such as mass matrix, Coriolis force, gravitational force, other external and internal forces. Support both rigid and soft body nodes.

Model viscoelastic joint dynamics with joint friction and hard joint limits.

Support various types of actuators. Handle contacts and collisions using an implicit LCP to guarantee non-penetration, directional friction, and approximated Coulomb friction cone conditions.

Support ”Island” technique to subdivide constraint handling for efficient performance.

Support various Cartesian constraints and provide extensible API for user-defined constraints.

Provide multiple constraint solvers: Lemke method, Dantzig method, and PSG method.

Support dynamic systems with closed-loop structures.

Давай Эдик, за сколько ты это напишешь на сишечке, баран упертый?

Ардуина, конечно. Ну, если с бутстрапами не наигрался, то валай, натив поднимай. А так, для ардуины поддержка почти всего на свете есть, свой софт таскать между платформами очень просто. У меня есть пример AVR -> другой AVR -> ARM (Due) -> ESP32 -> другой ARM (Teensy).

отличная штука для того, чтобы добавить ethernet к своей плате на STM32!

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

И пока-пока реальное время. Отлично просто

https://habr.com/ru/company/ruvds/blog/529388/

меньше 100 микросекунд, если верит графику

если верит

Блажен кто верует. linux-rt не относится к ОС жесткого реального времени.

Робота на питоне? Это ж каким дебилом надо быть??? Да этот робот вечно тупить будет и подвисать!..

О началось, жосткое, мягкое. Речь изначально шла про робота. Я программировал технологических роботов на линуксе и питоне, и нихера, все прекрасно работает.

Тупишь Эдик только ты, возраст берет уже свое. Пожалте примерчик на питоне:

http://dartsim.github.io/dartpy_examples_operational_space_control.html

У систем управления компонентов робота вообще-то несколько уровней с совершенно разными задачами и разными требованиями к времени отклика и задержке.

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

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

Вот это яркий пример того, о чем я пишу в посте выше.

меньше 100 микросекунд, если верит графику

100? Ваще жоска! Только в том же HFT всё вкусное уже как 98.5 микросекунд назад купили/продали, пока твой рилтайм раздуплится. И это было 10+ лет назад.

Ты настоящим роботом поуправляй на пытхоне, а не эмуляцией в опенгле!

И честно: чтобы никаких линуксовых прослоек между пытхоном и железом!!!

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

Аноним путает красивые картинки, чтобы школоту развлекать, с реальным применением. Да хотя бы двигать со скоростью в пару сантиметров в секунду фрезу по сложной траектории с точностью не хуже 10мкм. Т.е. одновременно нужно управлять тремя (а то и четырьмя - если это четырехосевой станок) шаговиками с делением шага 1:32, и на каждые несколько микрошагов участка линейной аппроксимации вычислять требуемые скорости движения по каждой координате + контролировать текущее положение (а вдруг фреза застряла или еще чего) по энкодерам.

Среди STM32 даже F0 справляется с подобной задачей (хоть там не то, что флоатов, а делений даже нет). Посмотреть бы, как этот умник будет ее решать в своем питоне =D Если что, для трех осей нужно шесть таймеров: три таймера для сигналов STEP, три таймера — для энкодеров.

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

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

А линуксоиду змеюка не нужна: для скриптов отлично подходит баш, а все остальное пишется на С или С++. Питону просто нет места!

Человек хочет программировать робота. В питоне есть …

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

Что мешает использовать modbus поверх CAN? Эдик, ты вообще понимаешь о чём говоришь?

Есть profibus, например. И миллиард чуть менее стандартизированных протоколов. Ты в общем-то любой master-slave протокол можешь использовать по 485-ому. Это всего лишь транспорт.

Только в 485 нельзя мультимастер.

Можно. См. например, профибас.

Если хочешь быть прям совсем Ъ, бери risc-v. GD32VF103 был. М.б. что по-новее появилось. А так всё правильно делаешь.

Ну и каким нужно быть ушлепком, чтобы вкорячивать модбас поверх CAN?

Какой вообще смысл? Ты хоть об этом-то думал?

Твой профибас - тупо софтовое решение поверх 485. Говно, одним словом. А в CAN все делается аппаратно, не тратя ресурсы ядра!

P.S. Поверх CAN’а любители забивать гвозди микроскопом и лизать яйца вместо того, чтобы работать, придумали еще одну дебильную затею — CANopen. Как же все матерятся на это, но, что поделать? Типа «стандарт», мать его! И приходится мириться с тем, что у тебя в CAN-шине нет-нет, а какой-то мусор начинает бегать.

Я - за честный CAN, в пакеты от 0 до 8 байт длиной можно впихнуть очень многое. Я себе пару протоколов придумал, вполне обхожусь. Получилось что-то вроде CANopen, но без нужды идентификаторы направо-налево раскидывать и без резерва такого дикого количества команд.

Кстати, я так и не понял, как в профибасе решают коллизии на уровне CAN: ведь в 485 нельзя одновременно слушать, что ты в линию передаешь! Получается, передал пакет — жди ответ. Не дождался — видать, косяк какой-то, надо опять повторять. Черезжопное решение, когда линия не рассчитана на мультимастера!

Прочел про профибас. Ну это ж полный ахтунг: фактически-то в сети всегда только один мастер, а остальные мастеры сидят и помалкивают, пока тот им «маркер» не передаст. Круто, блин! А если вдруг нужно экстренное сообщение отправить? Скажем, какой-то движок перегрелся и хочет знать, что делать: тормозить, плавно обороты снижать или пахать до смерти? Он может этого маркера пару секунд ждать, если там куча устройств в сети.

Ну, жееесть... Где, блин, логика?

Какой вообще смысл?

Ну вот есть у тебя транспорт CAN, и есть протокол modbus. Берёшь и вкорячиваешь. И никаких проблем. Зачем? Чтобы данные передавать, очевидно же.

Modbus - протокол прикладного уровня. Он от транспорта практически не завит.

CAN, rs485 - протоколы транспортного уровня. К модбасу они отношения никакого не имеют.

Твой профибас - тупо софтовое решение поверх 485. Говно, одним словом. А в CAN все делается аппаратно, не тратя ресурсы ядра!

Офигительная история.

фактически-то в сети всегда только один мастер

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

Он может этого маркера пару секунд ждать, если там куча устройств в сети.

Для этого существует проектирование профибас сети. Устанавливается максимальное время владения и т.п.

Это системы для немного разных вещей. Profibus не предназначен для мгновенного реагирования. Задержка в десятые секунды там вполне допустима, зато он позволяет гонять без геморроя большие объёмы данных.

С can тебе придётся или ограничиваться 8-байтными пакетами, или увеличивать тайминги и собирать один пакет из нескольких.

В этом плане, кстати, один из лучших вариантов, которые я видел - это lon. Но это довольно сложная в реализации проприетарщина от топливников. Вещь с весьма ограниченным применением, хоть и удобная.

Нет, в CAN-сети фактически все устройства - мастеры. И они в любой момент могут передать данные. Без необходимости что-то там ждать. Если одновременно несколько передают — да, приоритет будет распределяться по старшинству идентификаторов.

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

Когда я хочу изображения по сети гонять, я ethernet использую…

Проприетарных протоколов - гора. С теми же приводами: SEW свою фигню придумал поверх 485 и CAN (но то, что поверх CAN, сильно похоже на CANopen), сименс - свою…

Вот, чего понять не могу, так это с какого перепуга внезапно пропал сегмент дешевых CAN-based приводов для двигателей? Недавно вот понадобилось управлять скоростью вращения четырех движков. Самое дешевое, что нашли на CAN — у SEW! Дык, там, блин, двигатели в несколько раз дешевле… Но я никогда с силовой электроникой не работал, чтобы свое разрабатывать. Вот управление шаговиками - другое дело, я на этом уже собаку съел.

Без необходимости что-то там ждать. да, приоритет будет распределяться

Ты определись, приоритет будет распределяться, или без необходимости ждать?

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

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

В промышленности уже давно есть промышленный ethernet, да и оптоволокно никто не отменял, если уж совсем треш творится вокруг.

Но дело в том, что зачастую никому не нужно передавать изображения и видео между устройствами, чаще всего это - элементарные команды вида «вращайся со скоростью 300об/мин», которые в легкую вмещаются в 8 байт. Поэтому-то CAN в таких случаях — отличный выбор. Вот, у нас телескопы на CAN-шине и работают уже много лет. Да и там нужно обеспечивать более-менее рилтайм, а не то, что гуляет пакет по сети 30 миллисекунд, никак до потребителя не дойдет…

Хотя, честно говоря, вся рилтаймовость вычислений для современного телескопа настолько проста, что ею и Cortex-M4 (а то и вообще M3) спокойно сможет заниматься. А вычисление новых поправок на гнутия и т.п. - штука значительно менее требовательная и может хоть раз в минуту выполняться.

В промышленности уже давно есть промышленный ethernet

Есть, конечно. Тот же profinet (profibus over ip). Но он, как правило, как межсегментный транспорт используется, а в пределах одного участка всё по 485-ому делают. Ну по-крайней мере то, что я видел.

да и оптоволокно никто не отменял

Это будет прям сильно дороже 485-го.

чаще всего это - элементарные команды вида «вращайся со скоростью 300об/мин», которые в легкую вмещаются в 8 байт.

Мы всё ещё про промышленное оборудование говорим? Или это чаще всего при управлении телескопом?

Да и там нужно обеспечивать более-менее рилтайм

Рилтайм - это про гарантии, что что-то будет сделано в определённый промежуток времени, а не про то, что этот промежуток времени обязательно должен быть маленьким. Я, если что, не призываю тебя переводить телескопы на профибас. Если тебя can устраивает, то и прекрасно, он в общем-то для этого и создан.

Я профибас вообще чем-то хорошим не считаю. Но того факта, что он мультимастер поверх rs485 это не отменяет.

Мы всё ещё про промышленное оборудование говорим?

А что, там нужно что-то намного сложней? Даже на том же конвейере…

Я в этом по верхам немного нахватался. Суть примерно такая. STM32 тупо лучше всех этих AVR-ов вообще по всем параметрам, включая энергоэффективность (если брать соотв. версии). Да и вообще тупо лучше всех остальных МК. Включая цену.

Единственный минус STM32 - это мелкие ножки, которые задолбаешься паять. AVR есть в корпусах для нубов, которые можно паяльником припаять, даже если ты паять не умеешь, как я.

смотря какой конвейер.

ныне там куча распознования, так тупо проще, не нужно строить безумную механику

Эээ, это где то мелкие ножки? На evaluation board? Или ты прямо чип паяешь куда-то? Кто ж голый микроконтроллер куда-то паяет, там можно вроде если припечет PCB заказать.

James_Holden, кто там ещё, не помню.

Assembler :))