Обсуждение. Нужен Форт для Android, но "нужен" не значит "скачать". Конкретная задача - сбор с датчиков по BLE, графики, обработка, и все это загружаемым скриптом (поэтому консоль на экране не особо нужна). Основные размышления на уровне выбора основы для такого приложения и пакетов/библиотек/и т.д.

А, к примеру, решение с испoльзованием Ардуино не подходит/рассматривалось или избыточно?

P.S. В gForth для Android, вроде были/есть какие то примеры и обработки датчиков.

А, так в тенденции развития Андроид становится закрытой экосистемой с поддержкой 'только" от Google.
Какой к использованию Андроид предполагается.

А какое решение на Ардуино заменит смартфон с Андроидом?


Я выше написал предполагаемый сценарий работы. Начинать с инструментов вообще неправильно, тем более когда инструмент - gforth, известный тем, что под выпуск продуктов он и не планировался. Соответственно, и искать в нем практически применимый код бессмысленно. Мне же не "прочитать с датчика", вопрос будет в том, как организовать все процессы измерения и обработки, распределив их между датчиком, смартфоном и ПК.


А что тут может быть принципиально важного? Самый старый из еще встречающихся, кроме случаев, когда обязательно нужна определенная функциональность, поддержанная только в более новых версиях. Это обычная практика.

Такое же как подцепляются к смартфону умные часы, браслеты, аудио колонки ... сделанные на
соответствующей элементной базе и на этих МК тоже Форт используют.

Вот ничего не понял. Еще раз - мне к смартфону подключать датчики. К обычному смартфону, которым пользуется много людей (которым можно будет такое приложение передать). Решение должно работать на смартфоне, а не "быть Фортом любой ценой". Форт в данном случае - подходящий архитектурный шаблон, потому что на его основе я хочу избавиться от постоянных пересборок основного приложения при необходимости мелких правок. Интерпретатор Форта в приложении сбора и визуализации данных должен позволять загрузить скрипт, который свяжет функции собственно приема данных, построения графиков, отсева или сохранения в память, передачи в ПК и проч.

Есть много вариантов использования скрипта на мобилке, тот-же Titanium SDK или cordova (aka phonegap). Даёт почти полный доступ ко всем устройствам телефона. Реализовать подгружаемый скрипт тоже наверное несложно. Но если хочется именно форт, то на javascript их тоже есть.

Для Titanium SDK есть TiShadow, фактически удалённая javascript консоль.

Скрипт - это не цель, а инструмент. Нет смысла начинать с Форта, поскольку внимание будет растащено по мелочам, а потом все равно придется реализовать то, что нужно в конкретном проекте. Лучше с этого нужного и начинать.
В конце концов, вот
https://en.wikipedia.org/wiki/Interpreter_pattern
И чем Форт не интерпретатор?

Возможно у вас очень специфический случай, я хоть и очумелый адепт Форта, но если у вас есть время и возможности, то конечно Форт на Андроиде и ещё с графиками ... это конечно мощно!
ЗЫ я правда сам "извращенец" и GUI-шные приложения пишу на Go + ещё умудрился и под Андроид смастырить GUI приложение, но .... возможно лучше "специально обученные" инструменты для этого использовать?

Так ведь не Форт с графиками, а графики и BLE на Андроиде, но под управлением встроенного туда Форта.

Я может чего не понимаю, но сделал приложение на Андроиде, но ессно усечённое по функциональности - я тупо "супер-стар" и смотреть на этот "6 экранчик и без очков - тот ещё экшн!
А, если хотите "графиков", то вот вам пример!
https://cloud.mail.ru/public/bLyj/xuaUgDgKi и это всё делается локально.

Да, примерно такое. Но дальше-то пойдет масса мелочей. Среднее? Т.е. скользящее среднее (за какой интервал времени?). Кроме среднего, есть и другие методы обработки. А еще их захочется сравнить - это несколько графиков рядом. Выделение фрагментов сигнала. Статистика по фрагментам. Фильтры. Частотно-временное представление. Фазовый портрет. "Ой, датчик отошел, надо перезапустить, а это стираем".

Это просто частный пример, а так-то есть специально-обученные инструменты - например Grafana (правда есть ньюанс - они ввели запрет на обновление для России ) + ещё БД нужна. По поводу БД, тут тоже интересно: традиционно использовал MySQL и иногда SQLite.
Когда я делаю запрос "статистики" за сутки, то у меня с MySQL запрос вполне выполнялся за > 2-х сек., сейчас перешёл на ClickHouse и аналогичный запрос выполняется за < 200 мс!

Глобально тут вопрос соотношения известного и неизвестного. Если нужно реализовать известную и понятную последовательность операций, то SQL + любой визуализатор будут вполне удобны, пусть даже избыточны исходя из каких-то абстрактных соображений (обычно нет специальной цели сделать сверхкомпактно на ПК). Но тут есть вопросы. Чуть в стороне - то самое обновление для России. Ну не лапки же кверху поднимать теперь. Как говорится, "спасибо за освобожденный сегмент рынка", и делаем сами. Все равно вся Grafana не нужна, нужно что-то конкретное.
А основное в другой плоскости. Я понимаю, что температура в доме особо ничего не требует - ни сложной обработки, ни какой-то необычной статистики. А когда она появляется, программные инструменты внезапно становятся какими-то... одинаковыми. На всех приходится работать на низком уровне. И вот тут выигрывает такой инструмент, который будет
1) иметь более короткий цикл "кодирование-запуск-отладка"
2) управляемым и прогнозируемым (конкатенативная компиляция вполне прогнозируема, пусть даже и не имеет каких-то волшебных оптимизаций)
3) модифицируемым в сторону предметной области
Очень удобно оперировать шаблоном проектирования "интерпретатор". Вот он очень к месту здесь, пусть Форт и не один в один сюда подходит. Когда нет точного представления о результатах, нужно делать понемногу и уточнять на ходу. В процессе исследования появляется набор слов, которые в целом нужны, но при попытке уложить их в интерфейс дадут перегруженный GUI, который нужно будет еще постоянно поддерживать (иначе начнут множиться пустые и несвязанные друг с другом элементы - например, параметр больше не нужен, а поле от него все еще висит на форме). Можно и не GUI,.. и вот мы пришли к консоли, а консоль лучше не по отдельным символам, а по проработанному десятилетиями языку с понятными механизмами работы. К тому же еще и компилирующему на лету.