Jump to content

    

Вопрос по лицензированию

FreeRTOS распространяется по лицензии GNU General Public License (version 2).

Правильно ли я понимаю, что, если прошивка контроллера реализована с использованием FreeRTOS, то и на код программы, который не модифицирует исходный код ОС, а только использует его как библиотеку, все равно распространяется лицензия GNU GPLv2, что означает, что покупатель устройства с этим контроллером вправе запросить и получить полный исходный текст всей прошивки?

Так же, поскольку у контроллера есть дисплей, то прошивка обязана выводить лицензионную информацию: FreeRTOS и авторство, ссылка на лицензию или это не обязательно?

Последний вопрос, как внутри кода считать версию ОС, что бы не вписывать ее руками при обновлениях?

Share this post


Link to post
Share on other sites

У них не совсем GPL, у них с модификациями.

В общем, код можно не показывать.

Плюс к этому, нельзя сравнивать FreeRTOS с другими осями:)

Share this post


Link to post
Share on other sites
У них не совсем GPL, у них с модификациями.

В общем, код можно не показывать.

Плюс к этому, нельзя сравнивать FreeRTOS с другими осями:)

Спасибо!

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

 

Да, а по поводу считывания из FreeRTOS ее версии?

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

Share this post


Link to post
Share on other sites
Да, а по поводу считывания из FreeRTOS ее версии?

 

В task.h

 

#define tskKERNEL_VERSION_NUMBER "V8.2.3"
#define tskKERNEL_VERSION_MAJOR 8
#define tskKERNEL_VERSION_MINOR 2
#define tskKERNEL_VERSION_BUILD 3

 

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

 

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

 

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

 

 

Share this post


Link to post
Share on other sites
В task.h

 

#define tskKERNEL_VERSION_NUMBER "V8.2.3"
#define tskKERNEL_VERSION_MAJOR 8
#define tskKERNEL_VERSION_MINOR 2
#define tskKERNEL_VERSION_BUILD 3

 

 

 

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

 

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

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

Share this post


Link to post
Share on other sites
. . . .

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

Можете воспользоваться внешней сист. контроля версий, напр. SVN - ОНО содержит макро-переменные,

которые можно вписывать в исходник в требуемом месте.

В IAR есть Project-->VersionControlSystem. Которое, по всей видимости, для этого и предназначена.

Но я пользуюсь внешней SVN+Tortoise.

 

 

Share this post


Link to post
Share on other sites
И еще один вопрос. У многих тулчейнов есть возможность автоматического ведения номера билда - инкрементация при запуске. Я не нашел такого у IARа. Неужели нет?

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

__TIME__ — время компиляции, можно ими вместо номера билда пользоваться.

 

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

Share this post


Link to post
Share on other sites
я во всех тулчейнах прикручиваю макрос, который запускается перед/после сборки и в хидоре инкреметирует номер билд.

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

Share this post


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

__TIME__ — время компиляции, можно ими вместо номера билда пользоваться.

 

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

Да, Дата у IAR есть, но они вместо цифрового кода, печатают строку в американском убогом формате.

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

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

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

Share this post


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

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

Share this post


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

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

Share this post


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

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

 

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

Share this post


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

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

А по поводу номер ревизии и свн.... не всегда проект прикручен в системе контроля, когда к гиту, когда к свн-у... да и в гите или в меркуле номер ревизии такой вроде 734713bc047d87bf7eac9674765ae793478c50d3, а у пользователя такой d921970aadf03b3cf0e71becdaab3147ba71cdef. какой из них раньше? ещё есть ветки... как ревизия с разных веток будет приходить.... может какнить можно это приготовить и я его готовить не умею... у меня работает автобилд и дата сборки... этого более чем достаточно для моих задач.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
да и в гите или в меркуле номер ревизии такой вроде 734713bc047d87bf7eac9674765ae793478c50d3, а у пользователя такой d921970aadf03b3cf0e71becdaab3147ba71cdef. какой из них раньше? ещё есть ветки... как ревизия с разных веток будет приходить.... может какнить можно это приготовить и я его готовить не умею...

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

git log --pretty=format:"(%ad %h)" --abbrev-commit --date=short -1

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

#define GITHASH "(2017-02-03 db74878)"

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

Edited by johnshadow

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this