Гибкость быстрой не бываетAAN писал(а):Гибкость.
Согласен. Насчёт энтузиазма и подъёмности - обдумаем.verser писал(а):Цена комплектухи ничто, по сравнению с объемами программирования для доведения прошивки до конкурирующего с mesa уровня.
На одном энтузиазме тема вряд ли подъемная.
Ничего такого ни на сайте, ни в лицензии, ни в доках не нашёл. Только фразу типа "вы сами можете писать какие угодно плагины".MX_Master писал(а):Я точно не знаю, но, вроде, разработчики Мач4 далеко не всем дают доступ к инструментам разработки плагинов к Мач4. Там, вроде, драйвер должен быть как-то подписан, иначе он с Мач4 не будет работать. Или ситуация поменялась?
Надо посмотреть доки к их API и попробовать сделать простейший плагин. Но тут есть и другая сторона медали - пользователей Mach4 у нас очень мало. А 'бесплатный' Mach3 есть почти у каждого (:UAVpilot писал(а):Ничего такого ни на сайте, ни в лицензии, ни в доках не нашёл. Только фразу типа "вы сами можете писать какие угодно плагины".MX_Master писал(а):Я точно не знаю, но, вроде, разработчики Мач4 далеко не всем дают доступ к инструментам разработки плагинов к Мач4. Там, вроде, драйвер должен быть как-то подписан, иначе он с Мач4 не будет работать. Или ситуация поменялась?
Не соглашусь. По производительности pyboard даже на чистом Micropython-е (без сишных вставок) кроет массовые 8-битные Ардуины как бык овцу, просто удивительно, как множество народа продолжают кушать кактуСи. С учётом не бесплатности времени разработчика, Питон на контроллере - пушка.MX_Master писал(а):Гибкость быстрой не бывает
Любой интерпретатор - это всегда дополнительные накладные расходы по памяти и производительности просто по определению. Для встроенных приложений это один из главных параметров. Напомню, что в среде программеров STM32 всё ещё много тех, кто считает даже библиотеку HAL непозволительной роскошью.AAN писал(а):Не соглашусь. По производительности pyboard даже на чистом Micropython-е (без сишных вставок) кроет массовые 8-битные Ардуины как бык овцу, просто удивительно, как множество народа продолжают кушать кактуСи.
Есь такое. Я хоть и молодой STM'описатель, но знаю, что в некоторых требовательных местах HAL функции создают, хоть и небольшие, но задержки. Когда речь идёт о микросекундах и меньше, вплоть до тактов проца, использую прямую работу с регистрами.UAVpilot писал(а):Напомню, что в среде программеров STM32 всё ещё много тех, кто считает даже библиотеку HAL непозволительной роскошью.
Дополнительные расходы памяти и производительности не позволят управлять тормознутой механикой? Вы - серъёзно? Мегабайта встроенного флеша и 192кВ оперативы https://store.micropython.org/product/PYBv1.1 Вам мало?UAVpilot писал(а): Любой интерпретатор - это всегда дополнительные накладные расходы по памяти и производительности просто по определению. Для встроенных приложений это один из главных параметров. Напомню, что в среде программеров STM32 всё ещё много тех, кто считает даже библиотеку HAL непозволительной роскошью.
Опять не соглашусь. Вы мыслите в Си-шной парадигме, которая выросла из крайней дороговизны всех ресурсов, кроме времени разработчика. Времена меняются, Micropython напрямую работает со всем железом, всё придумано до нас, например, работа с Eternet: https://github.com/micropython/micropyt ... conf.h#L59UAVpilot писал(а): Ну и чтоб запустить Micropython на каком-то устройстве типа платы развязки для LinuxCNC (Ethernet + STM32) сначала надо будет на том-же С понаписать функций для поддержки всей периферии в Micropython...
Ну если для вас это насилие мозга, то нормальным программистам совершенно без разницы на каком языке писать.AAN писал(а):Можно, конечно, и дальше наСИловать мозг, только в 99,9% случаев это стрельба из пушки по воробьям.
Но вы почему-то даёте ссылку на С код...AAN писал(а):Времена меняются, Micropython напрямую работает со всем железом, всё придумано до нас, например, работа с Eternet: https://github.com/micropython/micropyt ... conf.h#L59
Не нужно мне рассказывать про сферических программистов в вакууме, которым всё равно, на каком языке писать. Пытались мы нанять специалистов или контору, чтобы добавить нужные нам функции в ПО, написанное на Perl со вставками на CUAVpilot писал(а): Ну если для вас это насилие мозга, то нормальным программистам совершенно без разницы на каком языке писать.
Типичный ответ был: "Мне проще аналогичную прогу с нуля написать." Это - к вопросу о "количестве пробелов в строке"/лёгкости поддержки-модификации кода. Интерпретатор Micropython написан на C - авторы славно поработали на благо пользователя, теперь бери да пользуйся, экономя тучу времени. Тот же модбас: https://github.com/riptideio/pymodbus/t ... r/pymodbusUAVpilot писал(а): Но вы почему-то даёте ссылку на С код...
Мне вот в нынешнем проекте нужна работа с modbus, для C есть несколько вариантов готовых библиотек - бери и пользуйся. А как с этим в Micropython?..
А ещё для управления люминицентными дисплеями есть очень хорошие чипы PT6315 (собственно им даже алтернативы нет) - так вот у них SPI, но нестандартный. Писать на С драйвер в Micropython? А нафик тогда Micropython нужен, если всё равно на C писать?..
Для задач реального времени этого может быть недостаточно, в любом случае интерпретатору нужно время на интерпретированиеAAN писал(а):Дополнительные расходы памяти и производительности не позволят управлять тормознутой механикой? Вы - серъёзно? Мегабайта встроенного флеша и 192кВ оперативы
Это верно для модулей stepgen и encoder. А вот передача/приём состояний входов/выходов должна быть намного чаще. В идеале за время основного цикла.alex1816 писал(а):Например один раз в сервоцикл обращение из линукса к плате(происходит обмен).
Здесь конечно может и выиграш будет в производительности, но я бы не откидывал так сразу этот вариант. В затратах времени - плюс неоспоримый. РТОС не даст таких задержек как к примеру интерпретатор.MX_Master писал(а): FreeRTOS - нет.
Здесь очень заманчиво, но .... есть много но... особенно финансово, хотя я этот вопрос до конца не изучал... похоже за ним(или подобным) будущее..... Драйвер в LinuxCNC есть, а вот slave ....MX_Master писал(а):EtherCAT - нет.
не отрицается конечно (протокол без подтверждения, но самый быстрый в этом уровне).MX_Master писал(а):UDP - скорее всего.
Вот в этом и основной вопрос: как это организовать получше.....MX_Master писал(а): Это верно для модулей stepgen и encoder. А вот передача/приём состояний входов/выходов должна быть намного чаще. В идеале за время основного цикла.
В точкуalex1816 писал(а):наверное не на питоне:)
32 выходных бита (4 байта) шлём вперёд, 32 входных бита (4 байта) шлём назад. Чем быстрее - тем лучше. UDP пакеты - быстрый и простой вариант. Со стороны LinuxCNC это будет выглядеть так: в самом начале базового цикла отсылаем 32 выходных бита, это будет сигналом к отправке 32 входных битов назад; ближе к концу базового периода получаем эти 32 входных бита; далее делаем с ними, что нужно. Но это только в теории. Как подойду к конкретной реализации, станет ясно.alex1816 писал(а):А если входы/выходы - как это можно организовать а уровне протоколов?
Мне всё равно на каком языке писать.AAN писал(а):Не нужно мне рассказывать про сферических программистов в вакууме, которым всё равно, на каком языке писать.
Но и я за такое не возьмусь, особенно не глядя - программисты бывают разные и разбираться в коде некоторых действительно может оказаться сложнее, чем написать заново, причём на любом языке.AAN писал(а):Пытались мы нанять специалистов или контору, чтобы добавить нужные нам функции в ПО, написанное на Perl
Вот вы лепите ссылки даже не вникая о чём они...AAN писал(а):Тот же модбас: https://github.com/riptideio/pymodbus/t ... r/pymodbus
Вопрос по Modbus был с подвохом - pymodbus в Микропитоне не будет правильно работать, ибо Микропитон заметно отличается от настоящего Питона.Я даже писал на нём.AAN писал(а):почитайте, наконец, про Python/Microputhon
И рассматривал его как инструмент для создания некритичных приложений. но в итоге отказался от его использования.Только вот на PC этот модуль на скоростях выше 230400 bps на современном компе уже начинает терять байты, а порт-то умеет работать аж на 10Mbps...AAN писал(а):тот же питоновский модуль PySerial целиком на Питоне и написан: https://github.com/pyserial/pyserial/tree/master/serial
Там только MAC, а сам стэк tcp/ip программный (lwip) - 40кб кода в самом минимальном варианте + от 2кб RAM на каждое соединение (socket).alex1816 писал(а):к примеру у чипа 407GTx или подобных в кубе сразу есть поддержка ip... то есть прямо в кубе настраиваешь ртос и там же IP(затраты на программирование минимальные).
W5X00 - вся физика и tcp/ip стэк уже внутриюalex1816 писал(а):А в других вариантах цепляешь плату на SPI(дешевую) и пишешь код сам(гемороя много). По википедии SPI 20мбит/сек.
А скорость SPI теоретически неограничена, например общение с оптическими трансиверами (телекомуникации) происходит по SPI на скорости 80Gbit/s. Я на макетке с stm32 делал пробный вариант - работает.alex1816 писал(а):Драйвер в LinuxCNC есть, а вот slave ....
На сеансовом уровне подтверждений нет, но на уровне приложения никто не мешает сделать, причём именно в тех местах где надо.alex1816 писал(а):протокол без подтверждения
Делай наоборот и две отдельные команды - одна для чтения входных данных, другая для записи выходных, потом спасибо скажешь.MX_Master писал(а):в самом начале базового цикла отсылаем 32 выходных бита, это будет сигналом к отправке 32 входных битов назад
Спасибо. Да, надо наоборот. Вот, что значит ночью сообщение писать. Сначала желательно получить входящие 32 бита. На их основе другие realtime компоненты сделают свою работу, попутно меняя выходные пины. Ну и в самом конце (базового периода) нужно отправить выходные 32 бита в STM32.UAVpilot писал(а):Делай наоборот и две отдельные команды - одна для чтения входных данных, другая для записи выходных, потом спасибо скажешь.MX_Master писал(а):в самом начале базового цикла отсылаем 32 выходных бита, это будет сигналом к отправке 32 входных битов назад
RTOS может быть удобно, делал на stm32f107 машет ногами (14шт) по расписанию, сетка времени и минимальный интервал 1мкс, общение с компьютером UDP, получение времени от GPS с разрешением 1мкс. + дисплей от nokia ..., экран без RTOS просто не прикрутить.MX_Master писал(а):У устройства будет свой IP, который можно будет поменять на HTML странице системных настроек.
На этой же странице можно будет поменять и прошивку (будет свой загрузчик).
FreeRTOS - нет.
EtherCAT - нет.
UDP - скорее всего.
Это верно для модулей stepgen и encoder. А вот передача/приём состояний входов/выходов должна быть намного чаще. В идеале за время основного цикла.alex1816 писал(а):Например один раз в сервоцикл обращение из линукса к плате(происходит обмен).
Что в дисплее от телефона такого сакрального, что без RTOS ну никак?sergx99 писал(а):экран без RTOS просто не прикрутить
Немножко не понял. Имеется в виду, что стек (который из куба слишком много кода имеет? или ??)UAVpilot писал(а):alex1816 писал(а):
к примеру у чипа 407GTx или подобных в кубе сразу есть поддержка ip... то есть прямо в кубе настраиваешь ртос и там же IP(затраты на программирование минимальные).
Там только MAC, а сам стэк tcp/ip программный (lwip) - 40кб кода в самом минимальном варианте + от 2кб RAM на каждое соединение (socket).
Спасибо за наводку.UAVpilot писал(а):W5X00 - вся физика и tcp/ip стэк уже внутрию
Тогда тебе уже прощеUAVpilot писал(а):alex1816 писал(а):
Драйвер в LinuxCNC есть, а вот slave ....
Я на макетке с stm32 делал пробный вариант - работает.
Думаю в таком случае не нужно UDP или TCP(разве что для некритичных по времени операций). Мало что о нем вычитал, но с первого взгляда штука хорошая.