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 найти конкретный коммит

+1. И совсем дело в командной или не командной разработке. Всё автоматизировано. Кроме того, если версия отдаётся в продакшн, то её (я про git) желательно пометить меткой, в этом случае можно использовать имя метки, которое можно сделать максимально осмысленным.

спор о том, что лучше PAL или SECAM. Правостороннее движение или левостороннее. На вкус и цвет товарищей нет.

ps ну вот мне не понятно что было раньше... например 2017-02-03 или 2017-03-02? И во вторых.... как по db74878 найти в гите 734713bc047d87bf7eac9674765ae793478c50d3?
в 3-их: у пользователя (или у наладчика на флешке) есть две сборки "(2017-02-03 db74878)" и "(2017-02-03 df56a87)" - какая свежея?

я пробовал прикрутить контроль версий.... не вкатило.... не понравилось. Системы контроля версий (СКВ) вообще может не быть, а автобилд нужен... да и с автобилдом тоже всё автоматизировано. ведётся журнал ревизий, по номеру билда и дате сборки можно быстро найти нужную ревизию (если есть СКВ).
+1

А как вы в оффлайне определяете такое написание? Например на сроке годности продуктов?
в readme проекта можно указать формат интерпретации даты yyyy-dd-mm или yyyy-mm-dd - для новых
участников проекта. Там же можно указать и стили оформления кода и т.п.

Уверяю вас - это возможно. Вы же не думаете, что короткий hash создатели git придумали just for fun?
И еще момент - "db74878" это первые символы полного hash.

Два варианта:
1) выводить в переменную и время. для избегания разночтений - в UTC.
2) в логе git посмотреть полную дату-время коммитов.
Контроль версий, как и баэкапы можно не любить, но жизнь вынуждает их применять... рано или поздно.

Ни как. На продуктах пишут 07.02.2017, другого написания не встречал. 2017.07.02 - такое написание не определяется.

в каком логе? ещё раз... вводная.... наладчик/пользователь поехал на обновление ПО в устройстве. на флешке две прошивки... какая свежея? Нету ни проетка, ни клиента гит, ни инета....

какое ридми? пользователь должен зайти в эбаут приложения и должен увидеть номер сборки и/или дату и время сборки, и/или номер версии. И должен понять, на сколько программа свежая.

вы так говорите, какбудь-то я вас убеждаю не использовать версирование сборок. Я предложил свой вариант. Они ни чем не хуже вашего. По мне, так он удобнее, чем брать его из СКВ. на вскидку.... откройте в хроме chrome://help/ - Версия 55.0.2883.87. Нету ни каких диких хэшей из гита, нет даты... Объясните гуглу, что они не правильно версию пишут, и скажите им Контроль версий, как и баэкапы можно не любить, но жизнь вынуждает их применять... рано или поздно.
По мойму в qip было Версия 2005 build 8095.... Firefox - 51.0.1, FreeCommander XE 2016 Build 715, в нотепад++ версия и время сборки.... во всех программах версия/сборка/время сборки.... привязки к номерам ревизий из СКВ не встречал.... хотя не значит что их нет, и не значит, что это плохой способ... просто мне удобней автобилдом контролировать номера релизов.

Вы с этим проектом один работаете? Как без систем контроля версии выполняете модификацию кода?
Т.е. каким образом разделяете релизную копию и копию в которой сейчас вносите изменения?

По поводу билдов. Зайдите в FireFox в about:buildconfig и обнаружите:

Аналогично для Хрома в about:version:

Давайте отделим мух от котлет. Я свой код контролирую либо с помощью svn, либо с помощью git (есть и cvs). Я использую систему контроля версий. Хотя не во всех проектах. если программа простая... её дольше в СКВ заносить, чем писать.
Что касается сборок.... не ревизий, а именно сборок. Есть задача - точно знать, какую версию использует пользователь и какую версию заливает. Для этого я во всех проектах применяю номер сбрки и/или время и дату сборки. номер сборки автоматически инкримитируется при компиляции. К СКВ номер сборки не привязан, как и СКВ к номеру сборки. Релизная копия отделена от проекта.... собирается релиз и выкладывается в общее хранилище, от куда релиз могут взять производство и служба сервиса. В хранилище лежат все релизные сборки... от 1 до 1234. Релизу задается имя name_1234.hex, 1234 - номер сборки. Там же в хранилище ведётся редми, с указанием изменений.

ps допустим пользователь обнаружил проблему.... говорит, что у него сборка 1201. Я вижу, что текущая 1234. Если проблема новая... то я буду эту проблему искать и устранять в 1234 и если найду, то выпущу 1235 и отправлю пользователю. Если проблема была.... то она решена гденить в 1220.... я просто отправлю ему 1234.

1)зачем по билду искать в репозитории релиз сборки 1201?
ну допустим вы захотите откатиться на 1201 и поискать там проблему и потом проверить есть ли она в 1234.... допустим.... но
2)вам чтоб откатится до билда 1201, от пользователя нужен хэш от гита? если он вам сообщит, что он пользуется хромом версии 55.0.2883.87, вы от него потребуете сообщить версию ad0be09aa3ca814168d079b52825f6f80e22f0e8-refs/branch-heads/2883@{#723}? Не думаю.... я думаю вы по 55.0.2883.87 сами найдете нужный релиз и нужный срез. тогда вопрос - зачем пихать в ПО этот жуткий хэш? Как говориться: в чем профит?

Так ведь в распределенных СКВ нет возможности проводить сквозную нумерацию билдов\коммитов.
Допустим я создал ветку от вашего проекта и работаю с ней, параллельно с вами.
У меня свои номера билдов теперь, у вас свои. И как их дальше сравнивать?
На mercurial пытались прикрутить сквозную нумерацию, но по моему это отход от идеологии распределенных СКВ.
А так как есть дата коммита, то полный hash для однозначного определения конкретного коммита и не нужен.

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

ps да даже если и возникнет конфликт билда.... например 2 чела работают в стволе и оба собрали релиз. ну и что? во время комита будет конфликт с 1 строчкой.... #define BUILD 715 и #define BUILD 720.... при слиянии используй #define BUILD 720. Это не проблема.

pps только у руководителя проекта в IDE происходит вызов скрипта pre-build или post-build, который инкреметирует билд.... поэтому хоть 100 чел делают релиз.... только руководитель его автоматом проинкреметирует.

Вот где у нас идеологическая разница - у меня в master попадает только проверенный код, который прошел
тестирование в том числе и на группе реальных устройств у клиентов (которые согласились стать бета-тестерами). Таким образом в любой
момент из master всегда можно собрать "стабильный" релиз. И как у релизов, так и у бета-сборок
однотипный вывод версии - типа "XX.YY дата коммита и короткий hash". Где XX.YY это мажорные и минорные значения версии,
которые правятся руками (может быть и тэгом и git).
В вашем же случае, если возникает необходимость проверить бету на оборудовании клиента, но клиент столкнется с двумя разными стилями указания версии:
1) Релизная, вида: "XX.YY.buil_num"
2) Бета, вида: "commit_hash" или что-то подобное
Т.е. имеем две сущности (два вида), хотя фактически можно обойтись одной: только второй, так как первая не может быть универсальной,
ведь она поддерживается только в master ветке. Стоит ли плодить сущности без их необходимости?

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

ну не понимаю я зачем нужен хэш конечному юзеру... не понимаю. ))) Это какой-то оверинженеринг. И ни в одной проге я не видел хэшей в Эбаутах. даты сборок есть, билды есть, минор.мажор - есть, но хэшЫ!!! Открыл версию прошивки на смартфоне - %имя_тела%_20160630. Нет ни каких хэшей.

беру свои слова обратно. Вы меня убедили, что хэши точно в номерах версий/сборок не нужны. )))

Поддерживаю.