[uni 6]

Требования для выбора набора мк:

- возможность приобретения (n x 100 шт);
- максимальная переносимость кода на другой комплект мк;
- наличие SDK для Linux, RTOS и No OS;
- наличие отладочных плат в конфигурации для запуска Embedded Linux;
- наличие FPU, промышленное исполнение (CAN'ы, Ethernet, много UART'ов, ADC, наличие свободных GPIO).

Задачу можно представить как программный ПЛК и модули ввода-вывода, т.е. автоматизация и управление. Один вычислительный модуль, некая внутренняя шина и много подчинённых модулей. Графики нет, рисовать ничего пока не надо. Предполагается использование одного вычислительного модуля как основного, так и управляемого. 

Я пока выбрал следующих кандидатов:

1. STM32MP15x.
2. NUC97x/NUC98x.
3. Allwinner T113-s3.
4. XC7Z020.

Отладки идут, но хотелось бы узнать у более опытных товарищей, есть ли что-то из этого ряда похожее под задачу. Хочется писать под Linux, но также иметь возможность использовать модуль и без оного.

 

[Forger 20]

1 hour ago, uni said:

максимальная переносимость кода на другой комплект мк;

Это зависит прежде всего от программистов, камень и среда в таком случае - вторичны :)

[uni 6]

Хочу попробовать частично уменьшить требования к программисту: Что Должно Быть в Каждом FirmWare Pепозитории . Или хотя бы перевести их на уровень повыше, где меньше китайской документации и количества периферийных регистров.

[mantech 42]

1 час назад, Forger сказал:

Это зависит прежде всего от программистов

Это было до вражеских санкций, теперь уже и выбор проца влияет сильно. Я выбирал бы из 2 и 3 пункта...

[GenaSPB 11]

Nuc  без fpu если что...

Когда-то еще можно было выбирать... renesas rza1  удобный в применении был. Линукс на нем плохо поднимать, мало встроенной памяти

[mantech 42]

25 минут назад, GenaSPB сказал:

Когда-то еще можно было выбирать...

ИМХО, на ближайшие годы про джапоевропиндосов лучше забыть, чтоб не добавлять и без того огромного гемора снабженцам, особенно, если есть китайские аналоги...

27 минут назад, GenaSPB сказал:

Nuc  без fpu если что...

Ну и скорость по сравнению с аллвиннером раза в 4 меньше, общее только то, что ОЗУ встроено и корпус.

Изменено 27 сентября, 2022 пользователем mantech

[uni 6]

Я, честно говоря, Линукс и на STM32F429I-DISC1 поднимал. Еле упихнул ядро в 2 МБайта флеши. Но оно как-то не очень на фоне остального, хотя тоже может и сгодилось бы. Жаль померла виртуалка со сборочным окружением. 

FPU иногда нужен. Жаль, но это не так страшно. 

[jcxz 217]

1 час назад, uni сказал:

Я, честно говоря, Линукс и на STM32F429I-DISC1 поднимал.

Вот только не надо ля-ля. Линух не возможен на Cortex-M. Из-за отсутствия виртуальной памяти.

[mantech 42]

1 час назад, uni сказал:

Но оно как-то не очень на фоне остального, хотя тоже может и сгодилось бы.

Потому что не надо путать linux  и uclinux...

[uni 6]

Это да, но даже в варианте uClinux'а для задач управления и работы по последовательным интерфейсам, включая Ethernet, он вполне подходит. Когда-то давно писал под uClinux (см. картинку). Управлял клавиатурой, LCD экраном 128x64, модемом, 4-мя RS-ами, Ethernet'ом, sd-картой, плюс само ПО ещё. Реально проще, чем всё это хозяйство поднимать на очередном мк. Сейчас, конечно, кое-что изменилось, но всё равно порог вхождения больше для мк.

Изменено 28 сентября, 2022 пользователем uni

[mantech 42]

1 час назад, uni сказал:

Управлял клавиатурой, LCD экраном 128x64, модемом, 4-мя RS-ами, Ethernet'ом, sd-картой, плюс само ПО ещё. Реально проще, чем всё это хозяйство поднимать на очередном мк.

Ой, так ли, с таким-то бэкграундом?? Это стандартные устройства, причем драйверы под них как правило предоставляет сам производитель, они хорошо документированы, в лучшем случае их нужно внимательно просмотреть на предмет стабильности, и взаимодействия с основной программой. А вот копаться в недолинуксах - сомнительная затея, ИМХО...

Изменено 28 сентября, 2022 пользователем mantech

[jcxz 217]

4 часа назад, uni сказал:

Реально проще, чем всё это хозяйство поднимать на очередном мк. Сейчас, конечно, кое-что изменилось, но всё равно порог вхождения больше для мк.

Пока дело ограничивается готовыми драйверами стандартной периферии - может быть. Но как только дело касается чего-то нестандартного, требующего разбираться с чем-то низкоуровневым, или не дай бог - реалтаймовым(!), как такой "разбиратель" сразу же безнадёжно увязает по самые помидоры. И проваливает проект. Знаем живые примеры.

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

 

PS: Микроконтроллеры - они для того и существуют, чтобы делать на них что-то близкое к железу и реалтаймовое. А для линухов всякие малины и иже с ними есть. Не надо к нашей шустрой блохе пудовые чугунные подковы приклёпывать!

[uni 6]

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

А вот копаться в недолинуксах - сомнительная затея, ИМХО...

Да, когда я писал под uClinux около 7 лет назад, то имел некоторые проблемы. Это про сомнительность затеи. Они были следующие:

- отсутствие отладки (в моём SDK), там нельзя было использовать GDB отладчик для отладки Linux приложения (из-за того, что окружение разработчика было недоработано), пользовался только printf() и ibaPDA в качестве анализатора (очень помог при тестировании) сигналов (в основном был modbus-rtu, у меня было 4 RS'а, поэтому проблем с отладочными интерфейсами не было);
- кривая поддержка C++ из-за опять же недоработки SDK (был собран для C-кодинга), там похоже чего-то не хватало (наличие virtual в классе приводило к SIGSEGV), но я этот C++ частично победил путём "ручной" компоновки (подбирал ключи, пересобирать SDK не умел);
- кривая (устаревшая) сборочная Linux виртуалка, которую еле настроил, чтобы она принимала код из Visual Studio (это сейчас с 2017-версии разработка под Linux встроена, а раньше даже VisualGDB с трудом можно было настроить для моего случая);
- особенность однозадачности uClinux'а, кто знает, внешний процесс запускается в синхронном режиме, т.е. ждёшь пока не отработает (к примеру, настройка модема через pppd).

Это можно было бы назвать мазохизмом, но со стороны разработчика процесс выглядел как обычное программирование под Linux в Visual Studio. Deploy и прочее сделано cmd-скриптами и вставлено в студию.
 

2 минуты назад, jcxz сказал:

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

Бывает. У меня были RS-ы, Ethernet, LCD-экран (через фреймбуфер), кнопки, светодиоды и бипер. Для последних нужна была небольшая настройка, а так всё типовое. Это же "модуль CPU" в мире ПЛК. Он только команды внешним модулям транслирует, телеметрию в SCADA отдаёт и имеет небольшой графический интерфейс :) (см. картинку).

У меня есть плата с NUC97x и виртуальная машина со сборочным окружением, я посмотрел Linux примеры на github и да, свои драйверы и прочее. Будем смотреть.

[mantech 42]

4 часа назад, uni сказал:

Они были следующие:

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

4 часа назад, uni сказал:

Это же "модуль CPU" в мире ПЛК. Он только команды внешним модулям транслирует, телеметрию в SCADA отдаёт и имеет небольшой графический интерфейс :) (см. картинку).

Я как-то раньше думал, что ПЛК - это в основном среда исполнения, а не менюшки типовые и сд карта)))  Вот среду исполнения как правило поставляют в виде бинарной либы, остальное там мелочевка...

[uni 6]

С тех пор как некоторые ПЛК стали объединять с HMI панелями (последние лет 7), от народа требуют уже уметь не только алгоритмы рисовать, но и изобразительным искусством заниматься. В одном лице. SD-карта очень важна, если архив ведётся локально (системы малой автоматизации и панели оператора). Заказчик может не принять систему, если в ней нет истории всех нужных сигналов за последний месяц. Как потом назначать крайнего?