USB выбран потому что он дает дежурное питание для приводов моторов. А основное силовое питание приводов выключается цепью безопасности в случае аварии. Таким образом и работа узлов не прекращается вместе с диагностикой при авариях и требования сертифицируемости удовлетворяется без необходимости сертификации фирмваре узлов. И объем диагностики значительно больше чем это можно было бы позволить с CAN. И узлы дешевле. Ведь для USB не нужна даже микросхема драйвера.
Сейчас создаю манимулятор с локальной сетью на USB. На самом деле USB в микроконтроллерах работает надежнее чем Ethernet. Поскольку разбиение на логические каналы там производится на аппаратном уровне, а в Ethernet на программном. Поэтому USB работает надежней и быстрее. Так же как CAN работает в микроконтроллерах надежнее и быстрее чем MODBUS на RS485.
Опторазвязка в пром контроллерах не для надежности, а для универсальности. В моих распределенных системах моторов сигналы от узлов передаются без гальваноразвязки. Правильная кабельная система избавляет от избыточной гальваноразвязки. А при плохой архитектуре даже двойная гальваноразвязка не помогает.
Но то мощный годами проверенный компьютер на i7. А здесь платформа не то что слабая, но нет никакой уверенности, что создатели доведут безглючность до нужного уровня. Все ли драйвера они проверили? Есть ли у них ресурсы на отладку драйверов? Располагают ли они вообще доступом к драйверам? Юзер мануала на процесор в открытом доступе нет, и в этом основное отличие от микроконтроллеров, которые по настоящему свободно программируемые.
С приходом ChatGPT уже не так важно на чем программировать. Важно на чем отлаживать. Отладка Node.js на уровне регистров периферии и вообще железа как-то сомнительно видится. Интерфейс SWD, как понимаю, не выведен.
Сам Rockchip RK3566 не имеет ни CAN, ни LIN, ни EtherCAT, ни Flash. Для промышленного ПЛК что-то совсем уныло. Было бы интересно услышать о минимальной гарантированной длительности основного цикла и сколько IO за цикл может быть обработано.
Ну тогда не "синтаксический сахар", а "графический сахар"
Хотя всплывающие по цепочке кликов окна параметров, загораживающие основную схему я бы сахаром не называл. В текстовых редакторах тоже можно накликать любую инфу, но сахаром там это не называют.
Графический сахар - это когда, например, сквозь блок немного видно что содержится внутри:
Согласен с вашим возмущением. Неприятно когда постят непроверенный код. Но знаете, интернет давно уже выработал рефлекс не верить никакому коду если нет сторонних источников доверия. Нет веры и авторам, даже если они клянуться, что всё проверили. С ChatGPT у меня очень счастливая история. А получаю от него просто класные безошибочные скрипты на Python, да и на C простые функции он отлично выдает. Генерил функции с API OpenSSL, тоже отлично. Да, там встречались опечатки в именах функций API, но такие очевидные, что грех жаловаться.
А вот так просто получить нужный код от ChatGPT не выйдет. Нужно точно и тонко задать вопрос или даже цепочку вопросов. В этом и проявляется компетенция.
Автор не спросил и не спросит у ChatGPT. Потому что тот ему не ответит нужным образом. А знаете почему? Потому что сама тема галюциногенная (какой-то раздутый граф инициализации периферии, рисуемый вручную). Такой проблемы, как в статье просто не существует в малых встраиваемых системах, если там сознательно её не культивировать.
Вы свой код привели без проверочных тестов и без тестовых данных и без понятного описания. И именно поэтому я обратился к ChatGPT. От человека не добиться такого подробного, структурированного и ясного описания. Вы свой код зачем выложили? Наверно чтобы немного просвятить автора. (я отметаю другие эгоистичные мотивы). Ну так ChatGPT это делает лучше. Вот и все. И не важно как ChatGPT устроен и для чего он нужен по чьему-то мнению.
Это и есть простая вещь. Только граница простых вещей у AI сдвигается вверх каждый день. ChatGPT напишет и проверочный код если надо и исправит ошибки если надо. А так приведенный код достаточно примитивен. Быть "экспертом" в этом алгоритме это в все равно что быть экспертом по арифмертике.
Я сейчас с помощью ChatGPT уже успешно осваиваю SDK от Infineon. Еще месяц назад такое трудно было представить.
Сегодня ChatGPT лагает, поэтому выложил первый же его ответ. И там все объяснено, просто я выложил не весь ответ. Полный ответ от ChatGPT потянет на хорошую статью. А так там можно тюнингировать код под любые хотелки. Человек так не сможет.
Ничего, скоро таких статей в интернете сильно поубавится.
ChatGPT Code Copilot гораздо понятней объясняет алгоритмы и пишет код
Вот пример сортировки (DAG - Directed Acyclic Graphs)
Топологическая сортировка графа выполняется только для ацикличных направленных графов (DAG - Directed Acyclic Graphs). Этот алгоритм упорядочивает вершины так, что для каждого ребра uv, вершина u предшествует вершине v в отсортированном порядке.
#include <stdio.h>
#define MAX_VERTICES 100
typedef struct {
int V;
int E;
int adj[MAX_VERTICES][MAX_VERTICES];
int indegree[MAX_VERTICES];
} Graph;
void createGraph(Graph* graph, int V, int E) {
graph->V = V;
graph->E = E;
for (int i = 0; i < V; i++) {
for (int j = 0; j < V; j++) {
graph->adj[i][j] = 0;
}
graph->indegree[i] = 0;
}
}
void addEdge(Graph* graph, int src, int dest) {
graph->adj[src][dest] = 1;
graph->indegree[dest]++;
}
void topologicalSort(Graph* graph) {
int V = graph->V;
int queue[MAX_VERTICES];
int front = 0, rear = 0;
int topOrder[MAX_VERTICES];
int index = 0;
for (int i = 0; i < V; i++) {
if (graph->indegree[i] == 0) {
queue[rear++] = i;
}
}
while (front < rear) {
int u = queue[front++];
topOrder[index++] = u;
for (int v = 0; v < V; v++) {
if (graph->adj[u][v] == 1) {
if (--graph->indegree[v] == 0) {
queue[rear++] = v;
}
}
}
}
if (index != V) {
printf("Граф содержит цикл\n");
} else {
printf("Топологический порядок: ");
for (int i = 0; i < index; i++) {
printf("%d ", topOrder[i]);
}
printf("\n");
}
}
int main() {
Graph graph;
int V = 6, E = 6;
createGraph(&graph, V, E);
addEdge(&graph, 5, 2);
addEdge(&graph, 5, 0);
addEdge(&graph, 4, 0);
addEdge(&graph, 4, 1);
addEdge(&graph, 2, 3);
addEdge(&graph, 3, 1);
topologicalSort(&graph);
return 0;
}
Хотя автор не показал, что он действительно имеет дело с DAG. И выбрал довольно сомнительный вариант применения сортировки графов.
Видимо от того что под Zephyr Project пишет тьма аутсорсеров со всего света там коментарии и документация для HAL уровня отсутствуют как класс. Классический кот в мешке.
Более запутанной и одновременно неюзабельной экосистемы я не видел.
Лучше посмотрите mbed. B как там органично применяют HAL-ы. Хотя тоже не идеал.
Вы изобразили скопление простейшей периферии. Задачу очередности включения периферии сейчас легко решают генераторы кода типа ModusToolbox, STM32CubeMX, e2studio и т.п. Тут как раз проблем нет.
Я говорил о задачах уровня middleware, которые надо поднимать после периферии. Такие как: стеки полевых шин, TCP стек и все прикладные протоколы поверх него, логеры, файловые системы и USB классы, BLE профили, GUI и проч. Там не построить каких-то простых однозначных графов. Поскольку эти задачи могут давать отказы на старте и их приходится деинициализировать и снова инициализировать. Какие-то, как файловые системы, могут уходить в долгое восстановление. Тут графы не работают, а массивы вредны. Только дебагинг и постоянный рефакторинг. Да еще не забыть, что задачи могут отключать, реинициализировать и включать периферию. Такой вообще не место в массивах.
Правильно, программист. А значит он должен долго дебажить все эти функции, пока не добъется правильного их порядка. Следовательно массив ему окажет медвежью услугу, превратив прямые вызовы в косвенные.
Вся инициализация идёт максимально параллельно в асинхронных функциях. И тогда мистический порядок вызовов не нужен и массив не нужен. А иначе будет не embedded дивайс, а черепаха с временем загрузки сравнимым с Windows.
Массивы удобны именно с точки зрения оформления кода, когда выровнены столбцы. И можно редактировать код блочными операциями. А в статье именно это удобство и не упомянуто, а в коде даже игнорируется.
Про "уровни отвественности" - какой-то непонятное определение. Если дивайс планируется для реально ответственных применений, то там вот такие делают схемы. В вашей архитектуре об ответственности явно думалось меньше всего.
Когда бывают разные напряжения питания, то сразу специфицируют верхнюю границу, делают аналоговые входы с делителями и работают во всем диапазоне.
Про удобство ремонта тоже не понял логику. Какое это удобство если надо заниматься двумя источниками вместо одного.
Вы там не нарастите так количестов выходов что прям понадобится более мощный источник для управления оптосемисторами или реле. Поставили источник на пару ампер и хватит за глаза для такой системы. Один пин на ваших разъемах специфицирован на 3 ампера.
"Грязное" питание по полной программе вы получите когда подключите два источника питания (особенно если они на разных фазах сидят) с двух концов этой этажерки. Даже оптроны не спасут от FTB помех. Кстати, не забывайте ставить резисторы и в подключенных к земле ногах оптронов.
Не нужен никакой внешний источник питания. Какой ток будут потреблять входы определяет сам контроллер, он же и ограничивает ток. Он же и контролирует замыкания во внешних цепях. Т.е. добавляет диагностику.
Диод в схеме управления реле не лучший вариант. Он замедляет отключение реле в 10 раз.
Все же такая многоплатная архитектура вызывает вопросы по цене владения. Тут дорого все. - Небольшая модификация межмодульной шины приведет к необходимости переделки всех плат. Либо дизайн быстро морально устареет. Уже сейчас восходит I3C и другие перспективные интерфейсы. - Узкая межмодульная шина удорожает дизайн из-за допролнительных микросхем расширителей IO - Такое количество плат обойдется дороже чем одна или две. - Печать уникального корпуса тоже дорого. - Собирать и разбирать такую сборку - трудоёмко. - Отлаживать осциллографом тоже нереально трудоемко. До промежуточных плат просто не добраться.
При всем при этом этом страдает помехоустойчивость, поскольку уже нет сплошного плэйна и помехи будут гулять непредсказуемыми путями. В цепи общей земли появляются существенные индуктивности вызванные разъемами. В догонку проприетарный медленный JTAG.
И только одинокий ESP32 как бы намекает, что по задумке наверно хотели сделать бюджетно.
Думаю если бы был конкурс на худшую архитектуру, то эта бы победила.
Есть очень разные места установки дисплеев. Например в одном нашем агрегате есть четыре дисплея, они не выведены наружу. Они внутри, их не видит юзер. Они только лишь для обслуживающего персонала, чтобы быстрее диагносцировать проблемы. Дисплеи настолько дешевы, что их дешевле ставить чем светодиоды. Но при этом они гораздо информативней.
Насколько там мелкий шрифт имеет мало значения. Гораздо важнее поместить максимум информации. Поэтому шрифт выбирается самый мелкий. Кому надо может посмотреть через камеру мобильника, он увеличит изображение.
Дисплей на I2C выносится в любое место и на любое расстояние на раз-два. Например дисплей моего ПЛК выносят на два метра. А он работает между тем по SPI на 20 МГц!
USB выбран потому что он дает дежурное питание для приводов моторов. А основное силовое питание приводов выключается цепью безопасности в случае аварии. Таким образом и работа узлов не прекращается вместе с диагностикой при авариях и требования сертифицируемости удовлетворяется без необходимости сертификации фирмваре узлов. И объем диагностики значительно больше чем это можно было бы позволить с CAN. И узлы дешевле. Ведь для USB не нужна даже микросхема драйвера.
Сейчас создаю манимулятор с локальной сетью на USB. На самом деле USB в микроконтроллерах работает надежнее чем Ethernet. Поскольку разбиение на логические каналы там производится на аппаратном уровне, а в Ethernet на программном. Поэтому USB работает надежней и быстрее. Так же как CAN работает в микроконтроллерах надежнее и быстрее чем MODBUS на RS485.
Опторазвязка в пром контроллерах не для надежности, а для универсальности. В моих распределенных системах моторов сигналы от узлов передаются без гальваноразвязки.
Правильная кабельная система избавляет от избыточной гальваноразвязки. А при плохой архитектуре даже двойная гальваноразвязка не помогает.
Риалтаймности на уровне 10 мс можно добиться на обычном PC с Windows 11.
Демонстрацию можно найти в этом проекте -
Быстрая разработка для микроконтроллеров в Simulink на примере полифункционального зарядника
Но то мощный годами проверенный компьютер на i7. А здесь платформа не то что слабая, но нет никакой уверенности, что создатели доведут безглючность до нужного уровня. Все ли драйвера они проверили? Есть ли у них ресурсы на отладку драйверов? Располагают ли они вообще доступом к драйверам? Юзер мануала на процесор в открытом доступе нет, и в этом основное отличие от микроконтроллеров, которые по настоящему свободно программируемые.
С приходом ChatGPT уже не так важно на чем программировать. Важно на чем отлаживать.
Отладка Node.js на уровне регистров периферии и вообще железа как-то сомнительно видится.
Интерфейс SWD, как понимаю, не выведен.
Сам Rockchip RK3566 не имеет ни CAN, ни LIN, ни EtherCAT, ни Flash. Для промышленного ПЛК что-то совсем уныло.
Было бы интересно услышать о минимальной гарантированной длительности основного цикла и сколько IO за цикл может быть обработано.
Ну тогда не "синтаксический сахар", а "графический сахар"
Хотя всплывающие по цепочке кликов окна параметров, загораживающие основную схему я бы сахаром не называл. В текстовых редакторах тоже можно накликать любую инфу, но сахаром там это не называют.
Графический сахар - это когда, например, сквозь блок немного видно что содержится внутри:
Согласен с вашим возмущением. Неприятно когда постят непроверенный код.
Но знаете, интернет давно уже выработал рефлекс не верить никакому коду если нет сторонних источников доверия. Нет веры и авторам, даже если они клянуться, что всё проверили.
С ChatGPT у меня очень счастливая история. А получаю от него просто класные безошибочные скрипты на Python, да и на C простые функции он отлично выдает.
Генерил функции с API OpenSSL, тоже отлично. Да, там встречались опечатки в именах функций API, но такие очевидные, что грех жаловаться.
А вот так просто получить нужный код от ChatGPT не выйдет. Нужно точно и тонко задать вопрос или даже цепочку вопросов. В этом и проявляется компетенция.
Автор не спросил и не спросит у ChatGPT. Потому что тот ему не ответит нужным образом. А знаете почему? Потому что сама тема галюциногенная (какой-то раздутый граф инициализации периферии, рисуемый вручную). Такой проблемы, как в статье просто не существует в малых встраиваемых системах, если там сознательно её не культивировать.
Но пока вы не нашли галюцинацию в приведенном мной коде.
И кто тогда тут галюцинирует по поводу галюцинаций?
Вы свой код привели без проверочных тестов и без тестовых данных и без понятного описания.
И именно поэтому я обратился к ChatGPT. От человека не добиться такого подробного, структурированного и ясного описания.
Вы свой код зачем выложили? Наверно чтобы немного просвятить автора. (я отметаю другие эгоистичные мотивы). Ну так ChatGPT это делает лучше. Вот и все. И не важно как ChatGPT устроен и для чего он нужен по чьему-то мнению.
Это и есть простая вещь. Только граница простых вещей у AI сдвигается вверх каждый день.
ChatGPT напишет и проверочный код если надо и исправит ошибки если надо.
А так приведенный код достаточно примитивен. Быть "экспертом" в этом алгоритме это в все равно что быть экспертом по арифмертике.
Я сейчас с помощью ChatGPT уже успешно осваиваю SDK от Infineon. Еще месяц назад такое трудно было представить.
Сегодня ChatGPT лагает, поэтому выложил первый же его ответ.
И там все объяснено, просто я выложил не весь ответ. Полный ответ от ChatGPT потянет на хорошую статью.
А так там можно тюнингировать код под любые хотелки.
Человек так не сможет.
Ничего, скоро таких статей в интернете сильно поубавится.
ChatGPT Code Copilot гораздо понятней объясняет алгоритмы и пишет код
Вот пример сортировки (DAG - Directed Acyclic Graphs)
Хотя автор не показал, что он действительно имеет дело с DAG.
И выбрал довольно сомнительный вариант применения сортировки графов.
Ну вы дали пример.
Видимо от того что под Zephyr Project пишет тьма аутсорсеров со всего света там коментарии и документация для HAL уровня отсутствуют как класс. Классический кот в мешке.
Более запутанной и одновременно неюзабельной экосистемы я не видел.
Лучше посмотрите mbed. B как там органично применяют HAL-ы.
Хотя тоже не идеал.
Вы изобразили скопление простейшей периферии. Задачу очередности включения периферии сейчас легко решают генераторы кода типа ModusToolbox, STM32CubeMX, e2studio и т.п. Тут как раз проблем нет.
Я говорил о задачах уровня middleware, которые надо поднимать после периферии. Такие как: стеки полевых шин, TCP стек и все прикладные протоколы поверх него, логеры, файловые системы и USB классы, BLE профили, GUI и проч.
Там не построить каких-то простых однозначных графов. Поскольку эти задачи могут давать отказы на старте и их приходится деинициализировать и снова инициализировать. Какие-то, как файловые системы, могут уходить в долгое восстановление. Тут графы не работают, а массивы вредны. Только дебагинг и постоянный рефакторинг. Да еще не забыть, что задачи могут отключать, реинициализировать и включать периферию. Такой вообще не место в массивах.
Правильно, программист.
А значит он должен долго дебажить все эти функции, пока не добъется правильного их порядка. Следовательно массив ему окажет медвежью услугу, превратив прямые вызовы в косвенные.
Факт в том, что массивы тоже иногда неуместны.
Что это !?
Спрашивается, как узнать из этого кода какой порядок вызовов правильный?
И где тут те макросы которые были тут
Чтобы такое неприличное шаманство не делать, первым вызовом идет запуск RTOS.
А последним на старте идет ожидание флагов инициализации всех задач периферии.
Вся инициализация идёт максимально параллельно в асинхронных функциях. И тогда мистический порядок вызовов не нужен и массив не нужен.
А иначе будет не embedded дивайс, а черепаха с временем загрузки сравнимым с Windows.
Массивы удобны именно с точки зрения оформления кода, когда выровнены столбцы. И можно редактировать код блочными операциями.
А в статье именно это удобство и не упомянуто, а в коде даже игнорируется.
Про "уровни отвественности" - какой-то непонятное определение. Если дивайс планируется для реально ответственных применений, то там вот такие делают схемы. В вашей архитектуре об ответственности явно думалось меньше всего.
Когда бывают разные напряжения питания, то сразу специфицируют верхнюю границу, делают аналоговые входы с делителями и работают во всем диапазоне.
Про удобство ремонта тоже не понял логику. Какое это удобство если надо заниматься двумя источниками вместо одного.
Вы там не нарастите так количестов выходов что прям понадобится более мощный источник для управления оптосемисторами или реле. Поставили источник на пару ампер и хватит за глаза для такой системы. Один пин на ваших разъемах специфицирован на 3 ампера.
"Грязное" питание по полной программе вы получите когда подключите два источника питания (особенно если они на разных фазах сидят) с двух концов этой этажерки. Даже оптроны не спасут от FTB помех. Кстати, не забывайте ставить резисторы и в подключенных к земле ногах оптронов.
Однако и тут опять выбран самый дорогой путь.
В промышленных устройствах делают так:
Не нужен никакой внешний источник питания. Какой ток будут потреблять входы определяет сам контроллер, он же и ограничивает ток. Он же и контролирует замыкания во внешних цепях. Т.е. добавляет диагностику.
Диод в схеме управления реле не лучший вариант. Он замедляет отключение реле в 10 раз.
Все же такая многоплатная архитектура вызывает вопросы по цене владения.
Тут дорого все.
- Небольшая модификация межмодульной шины приведет к необходимости переделки всех плат. Либо дизайн быстро морально устареет. Уже сейчас восходит I3C и другие перспективные интерфейсы.
- Узкая межмодульная шина удорожает дизайн из-за допролнительных микросхем расширителей IO
- Такое количество плат обойдется дороже чем одна или две.
- Печать уникального корпуса тоже дорого.
- Собирать и разбирать такую сборку - трудоёмко.
- Отлаживать осциллографом тоже нереально трудоемко. До промежуточных плат просто не добраться.
При всем при этом этом страдает помехоустойчивость, поскольку уже нет сплошного плэйна и помехи будут гулять непредсказуемыми путями. В цепи общей земли появляются существенные индуктивности вызванные разъемами. В догонку проприетарный медленный JTAG.
И только одинокий ESP32 как бы намекает, что по задумке наверно хотели сделать бюджетно.
Думаю если бы был конкурс на худшую архитектуру, то эта бы победила.
Есть очень разные места установки дисплеев. Например в одном нашем агрегате есть четыре дисплея, они не выведены наружу. Они внутри, их не видит юзер. Они только лишь для обслуживающего персонала, чтобы быстрее диагносцировать проблемы. Дисплеи настолько дешевы, что их дешевле ставить чем светодиоды. Но при этом они гораздо информативней.
Насколько там мелкий шрифт имеет мало значения. Гораздо важнее поместить максимум информации. Поэтому шрифт выбирается самый мелкий. Кому надо может посмотреть через камеру мобильника, он увеличит изображение.
Дисплей на I2C выносится в любое место и на любое расстояние на раз-два. Например дисплей моего ПЛК выносят на два метра. А он работает между тем по SPI на 20 МГц!