FreeRTOS распространяется по лицензии GNU General Public License (version 2).
Правильно ли я понимаю, что, если прошивка контроллера реализована с использованием FreeRTOS, то и на код программы, который не модифицирует исходный код ОС, а только использует его как библиотеку, все равно распространяется лицензия GNU GPLv2, что означает, что покупатель устройства с этим контроллером вправе запросить и получить полный исходный текст всей прошивки?
Так же, поскольку у контроллера есть дисплей, то прошивка обязана выводить лицензионную информацию: FreeRTOS и авторство, ссылка на лицензию или это не обязательно?
Последний вопрос, как внутри кода считать версию ОС, что бы не вписывать ее руками при обновлениях?

У них не совсем GPL, у них с модификациями.
В общем, код можно не показывать.
Плюс к этому, нельзя сравнивать FreeRTOS с другими осями

Спасибо!
А на счет сравнивать. Как я понял сравнивать можно, но надо взять разрешение на публикацию, что бы они проверили корректность.

Да, а по поводу считывания из FreeRTOS ее версии?
И еще один вопрос. У многих тулчейнов есть возможность автоматического ведения номера билда - инкрементация при запуске. Я не нашел такого у IARа. Неужели нет?

В task.h





Я не нашел такой функции в кеил в свое время, не удивлюсь если и в IAR её нет.

В keil есть возможность запускать внешнее приложение перед сборкой. С помощью этого приложения я считаю билды. Кривовато, но работает.

Спасибо! Да, видимо то же придется делать нашлепку.

Можете воспользоваться внешней сист. контроля версий, напр. SVN - ОНО содержит макро-переменные,
которые можно вписывать в исходник в требуемом месте.
В IAR есть Project-->VersionControlSystem. Которое, по всей видимости, для этого и предназначена.
Но я пользуюсь внешней SVN+Tortoise.

я во всех тулчейнах прикручиваю макрос, который запускается перед/после сборки и в хидоре инкреметирует номер билд. Также в СИ есть макросы __DATE__ — дата компиляции;
__TIME__ — время компиляции, можно ими вместо номера билда пользоваться.

Было бы удобно, если такой функционал был бы встроен в тулчейн. В каких именно тулчейнах есть такой функционал? Пользуюсь разными, но ни в одном его не использую. Может он есть, а я не знаю.

А какой смысл считать сборки? Когда вставляется номер ревизии (или какая-то подобная информация), то тут профит ясен - узнав номер ревизии, можно посмотреть по логу системы управления версиями, что реально прошито. А номер билда говорит только о количестве запусков тулчейна. Или тут что-то другое имеется в виду?

Да, Дата у IAR есть, но они вместо цифрового кода, печатают строку в американском убогом формате.
В Микрософтовском я пользовался, еще были в других, но все это для больших машинок.

А затем, что когда собираешь, то забываешь перевести ручные счетчики. Путь номер билда идет бытрее релизов, это не страшно. Вон, номера билдов ОС у мелкомягких идут явно быстрее чем один в сутки.

Вот я и интересуюсь, что за счётчики и зачем они нужны? Вот собрал я проект, например, получил номер 100, тут же собрал ещё раз, получил 101. Собрал ещё 10 раз, ничего не меняя, получил 111. Какая полезная информация в этом счётчике? Кому, чему и в какой ситуации это может помочь? Какая разница, сколько раз собрали, если 101 и 111 билды по содержанию ничем не отличаются?

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

А какая в этом практическая польза, если вы не знаете, чем оно отличается? Вот у вас номер билда прошлой версии в производстве 100, а текущий счётчик показывает 105 - какая в этом полезная информация, кроме той, что просто проект ещё пять раз собрали - может там ровно а же версия, что и в производстве? Или одна версия в производстве имеет ревизию 200, а следующая - 250, но по факту это может быть одна и та же версия. От количества сборок качество кода не меняется, ошибки не исправляются, фичи не появляются.

Другой подход - когда вставляется ревизия (тег) из системы управления версиями - вот тут всегда можно быстро посмотреть (по логу системы управления версиями), что конкретно прошито. Вот такой вариант представляется очень полезным и удобным, решает и обозначенную вами задачу. Почему не использовать этот подход?

у меня номер билда обновляется только в релизной сборке. Профит такой: пользователь жалуется, что есть проблема... я её решил. на билде 101 проблемы нет (или на билде от 06.02.2017). отправил пользователю.... потом другой пользователь или тотже пользователь опять кричит - у меня проблема. Первый вопрос - назови билд или дату сборки. бывает так, что пользователь не обновил прогу.... бывает, что он обновил на десктопе, а на ноуте не обновил.... бывает, что другой пользователь не знает про обновление.... вобщем без билда я начинал искать в новом коде старую проблему..... а по номеру - я сразу понимал что он не обновился, вот проблема и не исчезла. причем такая ситуация часто возникает. бывает даже так, что отправил билд 101.... пользоыватель кричит - у меня проблема... выходит так, не то что он запустил не обновил билд 95 до 101, он вообще может откопать билд 75.... древний.. от куданить с флешки или с архива почты....
А по поводу номер ревизии и свн.... не всегда проект прикручен в системе контроля, когда к гиту, когда к свн-у... да и в гите или в меркуле номер ревизии такой вроде 734713bc047d87bf7eac9674765ae793478c50d3, а у пользователя такой d921970aadf03b3cf0e71becdaab3147ba71cdef. какой из них раньше? ещё есть ветки... как ревизия с разных веток будет приходить.... может какнить можно это приготовить и я его готовить не умею... у меня работает автобилд и дата сборки... этого более чем достаточно для моих задач.

Я не противопоставляю одно другому. Генерация билдов по чекиненному коду - привилегия командной работы. По проектам, которые ведешь сам, это не очень удобно. В документации точно так же ведется список фич и пофиксенных багов по билдам и информативность такая же

У меня из git обычно забирается такой командной, которая выполняется автоматом перед компиляцией:

результат потом попадает в h-файл. Получается в итоге:

в итоге и дату видно и не нужен длинючий hash. По дате можно определить "новизну" билда, а по hash найти конкретный коммит

Сообщение отредактировал johnshadow - Feb 6 2017, 07:33