Чтобы хранить-распространять приложение - лучше завести отдельный репо в папке applications_user под него. В итоге получится папка которая может быть собрана как FBT, будучи склонированной в applications_user, так и uFBT отдельно. Под uFBT есть даже гитхаб-экшены, которые собирают приложение в облаке на каждый коммит.
Например вот как приложение выглядит на гитхабе, и вот так оно расположено в applications_user.
applications_user
собрано под v0.70, работает после обновления на v0.71
Для внешних приложений у Флиппера своя версия, указана в api_symbols.csv и увеличивается только при изменении API.
Флиппер официально сертифицирован для ввоза большинством стран (а в те которые не сертифицировали - мы просто не подавали запросы), в основных странах даже имеет сертификацию из служб безопасности, плюс постоянно на таможне проходит проверки функционала и вопросов к нему нет. Единственная проблема с которой мы столкнулись - вопросы к частотному диапазону.
Что же тут может демотивировать писать статьи? Мое предположение тут скорее нехватка документации и слишком злые правила написания под эмбед (которые мы еще ужесточили строгими проверками в компиляторе).
Сейчас проблема (и она упомянута в статье) в том, что мы очень часто переделываем API или систему сборки, и пока мы не поймем что все работает как нужно, заморозим API и скажем что прошивка достигла версии 1.0 любая документация по сборке приложений преждевременна и замедлит нашу работу.
Из хорошего - мы начали писать примеры использования функций, а так как актуальность их покрывается компиляцией прошивки, и отсутствует необходимость общаться с отделом документации, то это почти не сказывается на скорости нашей работы.
Да, флиппер понимает только свой формат изображений, heatshrink-compressed xbm image. Из минусов - все нужно конвертировать. Из плюсов - изображения занимают очень мало места.
Моё уважение разработчикам стандартной библиотеки за удачное применение такого известного приема, как реализация в C самописной таблицы виртуальных функций (как в высокоуровневых языках).
Спасибо, приятно слышать.
просто задать несколько параметров, а на выходе готовая основа для приложения
Что-то подобное есть в недавно зарелизившемся uFBT (standalone система сборки приложений для флиппера). Наверное перенесем это и в обычный FBT.
заставить VS Code видеть моё приложение и подсвечивать ошибки у меня почему-то не получилось
./fbt firmware_cdb делали? Это генерация compile_commands.json, без которого vscode не знает как процессить файлы через intellisense. Постараемся хотя бы основные тонкости описать в документации.
вопрос эффективности чтения байт файловой системы
На самом деле кроме кеширования на уровне стрима, есть еще кеширование на уровне блочного устройства (сд-карты), последние 8 запрошенных секторов всегда кешируются. Иногда это приводит к тому что буферизированные стримы медленнее чем работа через storage_file_xxx.
Можно. Только документации нет ни на второе ядро, ни на радиомодем, ни на способ прошивки второго ядра (оно шьется через криптозагрузчик и ключей шифрования естественно нет).
В этом вся особенность. Заменить компонент на другой в документации возможно и несложно. Сложно проверить как эта замена повлияла на всё, от процесса пайки и сборки до работы конечного устройства.
Завод не у нас под боком, и он не принадлежит только нам.
>Тогда нужно использовать стандарт abi для ARM. Вы не понимаете что такое abi.
Я продолжу диалог после того как вы приведете пример кода приложения которое бы вызывало функцию printf из ядра ОС и могло быть как вкомпилировано в ядро, так и запущено извне.
Как обычно, слинковавшись с этими функциями/переменными на этапе загрузки в оперативную память.
У нас на устройстве реализован полноценный ELF загрузчик, и всё работает как на большой взрослой ОС, за исключением изоляции процессов.
А что пришлось додумывать?
Я пробовал разные концепты, все они или не влезают в память, или ты пишешь на Си без компилятора, что сложнее чем писать с компилятором.
Кстати, скомпилировать и запустить приложение на Флиппере быстрее, либо эквивалентно по времени "закинуть скрипт в папку".
Чтобы хранить-распространять приложение - лучше завести отдельный репо в папке applications_user под него. В итоге получится папка которая может быть собрана как FBT, будучи склонированной в applications_user, так и uFBT отдельно. Под uFBT есть даже гитхаб-экшены, которые собирают приложение в облаке на каждый коммит.
Например вот как приложение выглядит на гитхабе, и вот так оно расположено в applications_user.
applications_user
Для внешних приложений у Флиппера своя версия, указана в api_symbols.csv и увеличивается только при изменении API.
Флиппер официально сертифицирован для ввоза большинством стран (а в те которые не сертифицировали - мы просто не подавали запросы), в основных странах даже имеет сертификацию из служб безопасности, плюс постоянно на таможне проходит проверки функционала и вопросов к нему нет. Единственная проблема с которой мы столкнулись - вопросы к частотному диапазону.
Что же тут может демотивировать писать статьи? Мое предположение тут скорее нехватка документации и слишком злые правила написания под эмбед (которые мы еще ужесточили строгими проверками в компиляторе).
Сейчас проблема (и она упомянута в статье) в том, что мы очень часто переделываем API или систему сборки, и пока мы не поймем что все работает как нужно, заморозим API и скажем что прошивка достигла версии 1.0 любая документация по сборке приложений преждевременна и замедлит нашу работу.
Из хорошего - мы начали писать примеры использования функций, а так как актуальность их покрывается компиляцией прошивки, и отсутствует необходимость общаться с отделом документации, то это почти не сказывается на скорости нашей работы.
Да, флиппер понимает только свой формат изображений, heatshrink-compressed xbm image. Из минусов - все нужно конвертировать. Из плюсов - изображения занимают очень мало места.
Спасибо, приятно слышать.
Что-то подобное есть в недавно зарелизившемся uFBT (standalone система сборки приложений для флиппера). Наверное перенесем это и в обычный FBT.
./fbt firmware_cdbделали? Это генерация compile_commands.json, без которого vscode не знает как процессить файлы через intellisense.Постараемся хотя бы основные тонкости описать в документации.
На самом деле кроме кеширования на уровне стрима, есть еще кеширование на уровне блочного устройства (сд-карты), последние 8 запрошенных секторов всегда кешируются. Иногда это приводит к тому что буферизированные стримы медленнее чем работа через storage_file_xxx.
Уже делалось на хакатоне, это вполне себе работает
Не нашли ничего распространенного (что можно было бы купить в текущей ситуации) и универсального.
Конечно. Флешка у ядер общая.
Можно. Только документации нет ни на второе ядро, ни на радиомодем, ни на способ прошивки второго ядра (оно шьется через криптозагрузчик и ключей шифрования естественно нет).
В этом вся особенность. Заменить компонент на другой в документации возможно и несложно. Сложно проверить как эта замена повлияла на всё, от процесса пайки и сборки до работы конечного устройства.
Завод не у нас под боком, и он не принадлежит только нам.
На чехле тоже перевод слетел, поправьте.
>Тогда нужно использовать стандарт abi для ARM.
Вы не понимаете что такое abi.
Я продолжу диалог после того как вы приведете пример кода приложения которое бы вызывало функцию printf из ядра ОС и могло быть как вкомпилировано в ядро, так и запущено извне.
Невозможно будет написать приложение которое можно вкомпилить и в ядро и в озу. Точнее можно будет, но выглядеть это будет очень грязно и небезопасно.
Плюс механизм верификации совместимости abi в этом случае будет очень не гибким.
А зачем это может быть нужно? В любом случае, в чем проблема?
Сотни килобайт в RAM? Даже в ROM оно не всегда помещается.
А библиотека-то где хранится?
Нет, код компилируется в нулевой адрес, при загрузке релоцируется.