[rloc 49]

2 часа назад, _pv сказал:

место около ЧПУ станка экономят, или энергопотребление?

Есть контроллеры, встроенные в ручной пульт. И автономность не повредит, чтобы не потерять, на каком месте остановился станок после пропадания питания.

 

2 часа назад, _pv сказал:

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

Можно копнуть немного глубже и окажется, что не все Ethernet контроллеры умеют так быстро работать, главным образом со стороны хоста. Видел много рекомендаций по читингу настроек драйверов, но подходит эта процедура далеко не всем. Есть черные списки по чипам, не рекомендованные к применению с LCNC. Но речь не об этом, были времена, когда SOC стоили в разы дороже, ситуация понятна.

[MDD 0]

Помнится автор топика начинал с "защиты прошивки".

Она возможна во всех этих вариантах х86 и т.д.? А то потом окажется, что на плату придется ставить и маленький STM32 в качестве донгла :)

[MX_Master 1]

Наверняка, защиты там есть. В атомах ещё и сопроцессор был, я помню. Но я всё равно не вижу ощутимых преимуществ. Особенно, если контроллер не будет рисовать графику на экран сам. Обычные STM'ки и программировать легче, и, банально, припаять проще. 

[MX_Master 1]

Параллельно данному проекту прикидываю на будущее вариант контроллера, который всю RT логику и расчёт траекторий будет держать внутри. А снаружи будет не RT интерфейс пользователя на отдельном ПК или на дисплее с физ. кнопками, подключёнными прямо к контроллеру. 

Не могу определиться, что из STM32 ставить на такой контроллер. Однозначно, должно быть что-то быстрое и, желательно, с двумя ядрами. Одно ядро будет на лету парсить gcode файлы с внешней USB/MicroSD флэхи, превращая сие в траекторию, другое ядро будет заниматься подсчётом и выводом сигналов. Сам контроллер - продукт не массовый, закупать под него тысячи чипов не нужно. Пока кризис на дворе, можно, просто, поскрести по сусекам китайцев 

Собсна, выбор - или ставить что-то двуядерное (кортекс М7+М4, A7+M4) или ставить два чипа (М4+М4, М7+М4, М7+М7). И в том, и в другом случае - свои плюсы и минусы. К примеру, когда всё в одном чипе - обвязки надо меньше, обмен данными между ядрами проще, обновление прошивки через свой загрузчик проще. Но линейка таких чипов небольшая, быстро заменить на какой-то аналог и перестроится не получится + цены на такие чипы кусаются. Если ставить два чипа, с ценами и заменяемостью будет порядок, аппаратной периферии в 2 раза больше, но коммуникация между чипами и обновление прошивок будут явно непростыми. Возможно, есть и другие плюсы/минусы, которые я не увидел. Советы крайне приветствуются 

[haker_fox 60]

2 hours ago, MX_Master said:

Однозначно, должно быть что-то быстрое и, желательно, с двумя ядрами.

Мир не вращается вокруг одних STM32. Посмотрите на LPC4337.

2 hours ago, MX_Master said:

Одно ядро будет на лету парсить gcode файлы с внешней USB/MicroSD флэхи, превращая сие в траекторию, другое ядро будет заниматься подсчётом и выводом сигналов.

Это всё круто звучит: два ядра. А как Вы взаимодействие между ними наладите? Есть у Вас опыт написания приложений для нескольких ядер?

2 hours ago, MX_Master said:

Советы крайне приветствуются 

Зачем Вам вообще два ядра? Вы бы посчитали нагрузку на эти ядра. Может быть окажется, что двух ядер будет недостаточно. Кстати, есть микроконтроллеры и с тремя ядрами. Почему бы не выбрать их? А может быть с вашими требованиями справится один Cortex-M7.

З.Ы. Я, вот, имею опыт работы с двухядерным МК LPC4337 с 2013 года. Задачи: сбор аналоговых и дискретных данных на частоте дискретизации до 1 МГц. Одновременно с этим: отображение данных на графическом дисплее, работа с Ethernet (web/ftp/modbus), MMC/SD, что-то ещё на шинах висело, modbus rtu (RS485/Ethernet). Я тоже сначала думал, что нужно задействовать помимо основного Cortex-M4F второе Cortex-M0. А вот и нет. Всё прекрасно улеглось на одно ядров в окружении FreeRTOS. Ещё раз: смотрите не только на ядра, но и на периферию микроконтроллера. У некоторых она весьма впечатляющая. Почти "полуплисины" приделаны.

З.Ы.Ы. Кстати, два ядра задействовал в своё время для изучения. На Cortex-M0 вертелся USB-стек, а на Cortex-M4F графический интерфейс пользователя + сбор и обработка данных.

[MX_Master 1]

Провентилировал данные по LPC4337.. Я понимаю, что Вы с ним давно знакомы и успешно работаете.. Но цена сейчас на них кусается и у китайцев еле еле можно найти в закромах. По требуемой периферии - чуток недостаточно аппаратных таймеров/счётчиков, маловато SRAM. 

Опыт работы с двумя ядрами есть, совсем небольшой, но, вроде, успешный. 

В целом мои задачи похожи на ваши. Графика, активная работа по сети (web), активное чтение с флэшек SDMMC/USB, активные расчёты с плавающей точкой. Это всё - работа с данными пользователя. Работа с устройствами - это неторопливый обмен по RS485 c частотниками (VFD), не менее 5-ти отдельных счётчиков для ABZ энкодеров/линеек (от 1 МГц и выше), не менее 5-ти отдельных ШИМ генераторов для управления приводами осей (от 1 МГц и выше), ещё один низкочастотный (до 20 КГц) ШИМ генератор для аналогового управления частотниками (VFD). Причём, работа с вводом и выводом сигналов частично программная. Для управления приводами крутится (на прерываниях) цикл с периодом 50мкс, в нём идёт правка, ВКЛ и ВЫКЛ параметров таймеров, обновление позиций и иногда ручное подергивание GPIO. Для нулевой метки (Z) энкодеров есть программные прерывания для сброса счётчиков в нуль (важна скорость реакции).

И с пользователем, и с устройствами надо, стессна, работать одновременно. Оба направления имеют загрузку проца как минимум на половину. Если всё на одно ядро (даже М7) повесить, загрузка будет приличная, на два ядра (или два разных чипа) - уже намного комфортнее. 

У китайцев, кстати, завалялось довольно много STM32H750VBT6, ещё по малым ценам. Но флэшу маловато, нужна внешняя. Что-то из H743VIT6 (пин-, флэш-, код-совместимое) у китайцев тоже есть, но в мало. Двуядерное в стоке, что-то ничего и нет. 

[haker_fox 60]

1 hour ago, MX_Master said:

Но цена сейчас на них кусается

Она на все микроконтроллеры кусается, за исключением уж совсем простых. Китайцев не рассматриваю, т.к. не доверяю.

1 hour ago, MX_Master said:

недостаточно аппаратных таймеров/счётчиков

Есть SGPIO, который может помочь в сборе данных с тех же энкодеров (сам обрабатываю три штуки на частоте 1 МГц). Возможно, что-то и выводить сможет.

1 hour ago, MX_Master said:

маловато SRAM

136 кБайт, ЕМНИП)

1 hour ago, MX_Master said:

У китайцев, кстати, завалялось довольно много STM32H750VBT6, ещё по малым ценам

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

1 hour ago, MX_Master said:

Если всё на одно ядро (даже М7) повесить, загрузка будет приличная

Гм...

1. Неторопливый обмен по RS-485. Если USART у выбранного МК имеет FIFO, можно сцепить с ПДП, то процессор будет тратить время на парсинг входящих пакетов и формирование исходящих. Скорее всего загрузка будет малозаметной.

2. Пять счётчиков для энкодеров. Если они по=большей части аппаратно поддерживают Ваши энкодеры, то Вам остаётся только их читать, может быть даже через ПДП (пройтись по диапазону адресов счётчиков по связному списку) и иметь в память где-нить уже массив готовых данных.

3.Пять ШИМов. Тут только предположу, что ШИМы можно кормить тем же ПДП по связанному списку, чтобы писать данные непосредственно в регистры MATCH. И писать их из некого буфера в ОЗУ, куда Ваш алгоритм подкидывает рассчитанные значения.

4. Активное чтение с флэшек SDMMC/USB. А насколько активное? Прямо во время работы приводов с энкодерами? А что, если считать G-коды, или что-там сейчас используют, в память, распарсить, и предоставить в максимально готовом виде для расчётных алгоритмов? Тогда, может быть, и читать не придётся. Просто я сам машиностроитель по образованию, и представляю, как работает станок с ЧПУ, но не представляю что=там можно активно читать с флешки. Могу чего-то не знать)

5. Активная работа по сети (web). Вот прямо во время работы приводов и энкодеров?))) Ну подтормозит немного вебка, и ладно) Тем более, что при использовании ОСРВ с вытесняющим планировщиком, задаче веб-сервера можно дать приоритет ниже, чем тем, которые крутят привода.

6. Активные расчёты с плавающей точкой. А на сколько активные? Начиная с Cortex-M4F у Вас есть FPU. Для M4F это одинарной точности, а для M7 это двойной точности. Подозреваю, что двойная точность не сильно нужна, поэтому M7 только для больших частот и чего-то ещё, но точно не сопроцессора.

7. Графика. Хм... тут некомпетентен. Никогда не любил графику, и на работе ею занимаются коллеги. Но Что там сложного в целом? Вывод через ПДП... А окна... Ну для случая, когда работают приводы, сделать наипростейшее окно, и выводить туда цифры XYZ и других осей. Тогда отрисовка не займёт много процессорного времени.

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

 

ЗЫ. Я бы обрисовал задачу более детально. На это надо не стесняться потратить время. Затем подобрать нужную периферию, понять, что она может, а что не может. Подумать, а нельзя ли из двух "недо"-периферий сделать одну, но полноценную. Например, в младших семействах STM32F0 нет FIFO у USARTов. И при приёме пакетов иногда данные теряются, вызывая ошибку переполнения, OVERRUN. Вариант - присобачить один из каналов ПДП к приёмнику USART, и читать ПДП в память. Это как пример. Ибо из Ваших слов очень часто звучит "активно работать", но нет конкретных или приблизительных цифр. Поэтому трудно понять, сколько ядер и каких надо.

[dimka76 52]

16 minutes ago, haker_fox said:

Есть SGPIO, который может помочь в сборе данных с тех же энкодеров (сам обрабатываю три штуки на частоте 1 МГц). 

Не расскажите как вы это делаете ?

[haker_fox 60]

13 minutes ago, dimka76 said:

Не расскажите как вы это делаете ?

Шесть линий конфигурируются на вход. Затем, данные с этих линий собираются на тактовой частоте 1 МГц в два буфера по 25-бит (SS_REG, длина в битах настраивается). Один теневой, второй активный (см. документацию на периферию). Каждые 25 бит вызываются прерывания (тоже настраивается), и я получая пять отсчётов с фильтрацией по пять бит. Фильтрация табличная. Голосование идёт по большему количеству логических сигнал в отсчёте. Далее полученные три пары сигналов в виде текущего отсчёта и предыдущего (по 6 бит) подаю на таблицу пересчёта. Таблица огромная, около 16 кБайт. Зато я успеваю обработать три энкодера, сигналы с которых поступают на максимальной частоте 100 кГц. Вот и всё)

З.Ы. Возможно, какие-то нюансы опустил, но мне простительно. Эту работу я выполнил три года назад, и к ней не возвращался.

З.Ы.Ы. Там же, кроме энкодеров, обрабатываются другие дискретные сигналы. Линий-то у SGPIO 16. 

З.Ы.Ы.Ы. Модуль можно связать с GPDMA, который у LPCшек может работать по связанному списку. Поэтому, при наличии фантазии и тщательного ознакомления с документацией, можно что-то соорудить)

[dimka76 52]

2 minutes ago, haker_fox said:

Шесть линий конфигурируются на вход. Затем, данные с этих линий собираются на тактовой частоте 1 МГц в два буфера по 25-бит (SS_REG). Один теневой, второй активный (см. документацию на периферию). Каждые 25 бит вызываются прерывания, и я получая пять отсчётов с фильтрацией по пять бит. Фильтрация табличная. Голосование идёт по большему количеству логических сигнал в отсчёте. Далее полученные три пары сигналов в виде текущего отсчёта и предыдущего (по 6 бит) подаю на таблицу пересчёта. Таблица огромная, около 16 кБайт. Зато я успеваю обработать три энкодера, сигналы с которых поступают на максимальной частоте 100 кГц. Вот и всё)

Спасибо !

[mantech 40]

21.08.2021 в 20:33, rloc сказал:

Есть Linux, на который портируется LCNC.

Вот че-то я не догоняю, а линукс там вообще зачем? Ну я могу понять, когда нужен продвинутый сетевой стек, видеоускорители, на которые нет доков, какие-нибудь навороты с приложениями, которые трудно делать без ОС, но тут-то зачем, ради того, чтоб на питоне можно было че-то сляпать, ну е-мое, это уж как детский сад... ИМХО ОС здесь - это и есть самый большой костыль, к которому нужно делать подпорки из РТ-патчей, чтоб не упало совсем...

Изменено 25 августа, 2021 пользователем mantech

[rloc 49]

3 часа назад, mantech сказал:

линукс там вообще зачем?

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

[mantech 40]

56 минут назад, rloc сказал:

Для того, чтобы воспользоваться готовой программой управления

Что за "программа управления"?  Это типа стартового экрана мач3 что-ли? И ради этого тащить сюда Ось, которая явно не предназначена для реалтайма? Ну так себе задумка...

[rloc 49]

7 минут назад, mantech сказал:

И ради этого тащить сюда Ось

Разговор ни о чем. Автор взялся воплотить baremetal, идея хорошая.

[MX_Master 1]

25.08.2021 в 11:26, haker_fox сказал:

4. Активное чтение с флэшек SDMMC/USB. А насколько активное? Прямо во время работы приводов с энкодерами? А что, если считать G-коды, или что-там сейчас используют, в память, распарсить, и предоставить в максимально готовом виде для расчётных алгоритмов? Тогда, может быть, и читать не придётся. Просто я сам машиностроитель по образованию, и представляю, как работает станок с ЧПУ, но не представляю что=там можно активно читать с флешки. Могу чего-то не знать)

Текстовые файлы с G кодом бывают довольно увесистыми (сотни мегабайт). Особенно, для 3Д печати и каких-то нелинейных рельефов для фрезера. Поэтому чтение и разбор данных файла возможно только небольшими кусочками. Делать это надо прямо во время работы всех подключенных устройств и интерфейса юзера. Для, более менее, продуманной траектории надо читать и разбирать хотя бы 1 килобайт текста за 1 миллисекунду (1Мб/с). И чтение здесь не самый медленный процесс. Гораздо больше времени уйдёт на разбор текста. А для разбора как раз нужны большие мегагерцы процессора.

В нынешних условиях дефицита логичным смотрится выбор из одного или двух чипов H750VBT6 (может меняется на H743VIT6). На складах и руках сие пока есть. Мегагерцев и нужной периферии, вроде, достаточно.