ARM, RISC-V контроллеры

Вначале отвечу по существу, а потом как обычно. Использование именно bash в embedded системах несколько абсурдно. bash предназначен как оболочка для работы человека в основном. Даже не в embedded для исключительно скриптов существуют менее тяжеловесные sh-интерпретаторы, хотя и не на 100% совместимые с bash. Но надо понимать, что это bash на самом деле "не стандартен", ибо вносит свои ни с чем несовместимые расширения для sh. Кроме того, bash требует очень больших объёмов памяти. ash или dash существенно легче и их используют на серверах и т.п. Для embedded-систем обычно используют busybox и его встроенный shell. Из-за требований к памяти (как к оперативной, так и к месту на диске). Но использование sh вообще, для программирования, то-есть создания относительно сложных программ, например больше 1000 строк -- не оправдано. Эффективность sh для таких программ уже низка, а большое число ошибок и низкая эффективность собственно программы начинают сказываться. Сколько-нибудь большие программы следует писать с использованием языков программирования, а не языков служащих для диалога пользователя с компьютером (sh). Это могут быть как интерпретируемые языки, так и компилируемые. И тут следует провести чёткую грань. Я имею мнение, подтверждённое негативным опытом, действительно сколько-нибудь крупные программы необходимо создавать только с использованием компилируемых языков -- из-за статической проверки кода компилятором, наличия системы типов и т.п. В противном случае все необнаруживаемые компилятором ошибки придётся вылавливать во время исполнения, что гораздо труднее. В данном случае (embedded) это вряд ли будет Java (хотя, моё мнение, это хороший в чём-то язык, особенно если нет опыта), а скорей вероятно таки C или C++. Сюда бы я ещё отнёсь lisp или scheme, хотя это скорей интерпретаторы байткода. Для более простых проектов более эффективны могут быть языки с динамической типизацией, вроде python, perl, tcl... в том смысле, что они дают своего рода Rapid Application Development. Я бы на вашем месте, в конкретном случае, использовал perl, если вы умеете его использовать (увы, но C может оказаться проще). Да, какие-то простые вещи можно сделать и на sh, но это не расширяемое одноразовое решение. Если вы имеете "опыт на тысячах серверов", то азы perl-программирования наверное всяко известны.