kostya-m 0 23 января, 2017 Опубликовано 23 января, 2017 · Жалоба FreeRTOS распространяется по лицензии GNU General Public License (version 2). Правильно ли я понимаю, что, если прошивка контроллера реализована с использованием FreeRTOS, то и на код программы, который не модифицирует исходный код ОС, а только использует его как библиотеку, все равно распространяется лицензия GNU GPLv2, что означает, что покупатель устройства с этим контроллером вправе запросить и получить полный исходный текст всей прошивки? Так же, поскольку у контроллера есть дисплей, то прошивка обязана выводить лицензионную информацию: FreeRTOS и авторство, ссылка на лицензию или это не обязательно? Последний вопрос, как внутри кода считать версию ОС, что бы не вписывать ее руками при обновлениях? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 23 января, 2017 Опубликовано 23 января, 2017 · Жалоба У них не совсем GPL, у них с модификациями. В общем, код можно не показывать. Плюс к этому, нельзя сравнивать FreeRTOS с другими осями:) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kostya-m 0 24 января, 2017 Опубликовано 24 января, 2017 · Жалоба У них не совсем GPL, у них с модификациями. В общем, код можно не показывать. Плюс к этому, нельзя сравнивать FreeRTOS с другими осями:) Спасибо! А на счет сравнивать. Как я понял сравнивать можно, но надо взять разрешение на публикацию, что бы они проверили корректность. Да, а по поводу считывания из FreeRTOS ее версии? И еще один вопрос. У многих тулчейнов есть возможность автоматического ведения номера билда - инкрементация при запуске. Я не нашел такого у IARа. Неужели нет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Quasar 20 26 января, 2017 Опубликовано 26 января, 2017 · Жалоба Да, а по поводу считывания из 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 есть возможность запускать внешнее приложение перед сборкой. С помощью этого приложения я считаю билды. Кривовато, но работает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kostya-m 0 27 января, 2017 Опубликовано 27 января, 2017 · Жалоба В 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 есть возможность запускать внешнее приложение перед сборкой. С помощью этого приложения я считаю билды. Кривовато, но работает. Спасибо! Да, видимо то же придется делать нашлепку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 28 января, 2017 Опубликовано 28 января, 2017 · Жалоба . . . . И еще один вопрос. У многих тулчейнов есть возможность автоматического ведения номера билда - инкрементация при запуске. Я не нашел такого у IARа. Неужели нет? Можете воспользоваться внешней сист. контроля версий, напр. SVN - ОНО содержит макро-переменные, которые можно вписывать в исходник в требуемом месте. В IAR есть Project-->VersionControlSystem. Которое, по всей видимости, для этого и предназначена. Но я пользуюсь внешней SVN+Tortoise. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 3 февраля, 2017 Опубликовано 3 февраля, 2017 · Жалоба И еще один вопрос. У многих тулчейнов есть возможность автоматического ведения номера билда - инкрементация при запуске. Я не нашел такого у IARа. Неужели нет? я во всех тулчейнах прикручиваю макрос, который запускается перед/после сборки и в хидоре инкреметирует номер билд. Также в СИ есть макросы __DATE__ — дата компиляции; __TIME__ — время компиляции, можно ими вместо номера билда пользоваться. Было бы удобно, если такой функционал был бы встроен в тулчейн. В каких именно тулчейнах есть такой функционал? Пользуюсь разными, но ни в одном его не использую. Может он есть, а я не знаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 3 февраля, 2017 Опубликовано 3 февраля, 2017 · Жалоба я во всех тулчейнах прикручиваю макрос, который запускается перед/после сборки и в хидоре инкреметирует номер билд. А какой смысл считать сборки? Когда вставляется номер ревизии (или какая-то подобная информация), то тут профит ясен - узнав номер ревизии, можно посмотреть по логу системы управления версиями, что реально прошито. А номер билда говорит только о количестве запусков тулчейна. Или тут что-то другое имеется в виду? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kostya-m 0 3 февраля, 2017 Опубликовано 3 февраля, 2017 · Жалоба я во всех тулчейнах прикручиваю макрос, который запускается перед/после сборки и в хидоре инкреметирует номер билд. Также в СИ есть макросы __DATE__ — дата компиляции; __TIME__ — время компиляции, можно ими вместо номера билда пользоваться. Было бы удобно, если такой функционал был бы встроен в тулчейн. В каких именно тулчейнах есть такой функционал? Пользуюсь разными, но ни в одном его не использую. Может он есть, а я не знаю. Да, Дата у IAR есть, но они вместо цифрового кода, печатают строку в американском убогом формате. В Микрософтовском я пользовался, еще были в других, но все это для больших машинок. А какой смысл считать сборки? Когда вставляется номер ревизии (или какая-то подобная информация), то тут профит ясен - узнав номер ревизии, можно посмотреть по логу системы управления версиями, что реально прошито. А номер билда говорит только о количестве запусков тулчейна. Или тут что-то другое имеется в виду? А затем, что когда собираешь, то забываешь перевести ручные счетчики. Путь номер билда идет бытрее релизов, это не страшно. Вон, номера билдов ОС у мелкомягких идут явно быстрее чем один в сутки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 5 февраля, 2017 Опубликовано 5 февраля, 2017 · Жалоба А затем, что когда собираешь, то забываешь перевести ручные счетчики. Путь номер билда идет бытрее релизов, это не страшно. Вон, номера билдов ОС у мелкомягких идут явно быстрее чем один в сутки. Вот я и интересуюсь, что за счётчики и зачем они нужны? Вот собрал я проект, например, получил номер 100, тут же собрал ещё раз, получил 101. Собрал ещё 10 раз, ничего не меняя, получил 111. Какая полезная информация в этом счётчике? Кому, чему и в какой ситуации это может помочь? Какая разница, сколько раз собрали, если 101 и 111 билды по содержанию ничем не отличаются? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kostya-m 0 5 февраля, 2017 Опубликовано 5 февраля, 2017 · Жалоба Вот я и интересуюсь, что за счётчики и зачем они нужны? Вот собрал я проект, например, получил номер 100, тут же собрал ещё раз, получил 101. Собрал ещё 10 раз, ничего не меняя, получил 111. Какая полезная информация в этом счётчике? Кому, чему и в какой ситуации это может помочь? Какая разница, сколько раз собрали, если 101 и 111 билды по содержанию ничем не отличаются? Важно то, что когда собрал и она пошла в производство, она точно будет по билду выше прошлой. А на сколько - уже не важно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 6 февраля, 2017 Опубликовано 6 февраля, 2017 · Жалоба Важно то, что когда собрал и она пошла в производство, она точно будет по билду выше прошлой. А на сколько - уже не важно А какая в этом практическая польза, если вы не знаете, чем оно отличается? Вот у вас номер билда прошлой версии в производстве 100, а текущий счётчик показывает 105 - какая в этом полезная информация, кроме той, что просто проект ещё пять раз собрали - может там ровно а же версия, что и в производстве? Или одна версия в производстве имеет ревизию 200, а следующая - 250, но по факту это может быть одна и та же версия. От количества сборок качество кода не меняется, ошибки не исправляются, фичи не появляются. Другой подход - когда вставляется ревизия (тег) из системы управления версиями - вот тут всегда можно быстро посмотреть (по логу системы управления версиями), что конкретно прошито. Вот такой вариант представляется очень полезным и удобным, решает и обозначенную вами задачу. Почему не использовать этот подход? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 6 февраля, 2017 Опубликовано 6 февраля, 2017 · Жалоба Вот я и интересуюсь, что за счётчики и зачем они нужны? Вот собрал я проект, например, получил номер 100, тут же собрал ещё раз, получил 101. Собрал ещё 10 раз, ничего не меняя, получил 111. Какая полезная информация в этом счётчике? Кому, чему и в какой ситуации это может помочь? Какая разница, сколько раз собрали, если 101 и 111 билды по содержанию ничем не отличаются? у меня номер билда обновляется только в релизной сборке. Профит такой: пользователь жалуется, что есть проблема... я её решил. на билде 101 проблемы нет (или на билде от 06.02.2017). отправил пользователю.... потом другой пользователь или тотже пользователь опять кричит - у меня проблема. Первый вопрос - назови билд или дату сборки. бывает так, что пользователь не обновил прогу.... бывает, что он обновил на десктопе, а на ноуте не обновил.... бывает, что другой пользователь не знает про обновление.... вобщем без билда я начинал искать в новом коде старую проблему..... а по номеру - я сразу понимал что он не обновился, вот проблема и не исчезла. причем такая ситуация часто возникает. бывает даже так, что отправил билд 101.... пользоыватель кричит - у меня проблема... выходит так, не то что он запустил не обновил билд 95 до 101, он вообще может откопать билд 75.... древний.. от куданить с флешки или с архива почты.... А по поводу номер ревизии и свн.... не всегда проект прикручен в системе контроля, когда к гиту, когда к свн-у... да и в гите или в меркуле номер ревизии такой вроде 734713bc047d87bf7eac9674765ae793478c50d3, а у пользователя такой d921970aadf03b3cf0e71becdaab3147ba71cdef. какой из них раньше? ещё есть ветки... как ревизия с разных веток будет приходить.... может какнить можно это приготовить и я его готовить не умею... у меня работает автобилд и дата сборки... этого более чем достаточно для моих задач. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kostya-m 0 6 февраля, 2017 Опубликовано 6 февраля, 2017 · Жалоба Я не противопоставляю одно другому. Генерация билдов по чекиненному коду - привилегия командной работы. По проектам, которые ведешь сам, это не очень удобно. В документации точно так же ведется список фич и пофиксенных багов по билдам и информативность такая же Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
johnshadow 1 6 февраля, 2017 Опубликовано 6 февраля, 2017 (изменено) · Жалоба да и в гите или в меркуле номер ревизии такой вроде 734713bc047d87bf7eac9674765ae793478c50d3, а у пользователя такой d921970aadf03b3cf0e71becdaab3147ba71cdef. какой из них раньше? ещё есть ветки... как ревизия с разных веток будет приходить.... может какнить можно это приготовить и я его готовить не умею... У меня из git обычно забирается такой командной, которая выполняется автоматом перед компиляцией: git log --pretty=format:"(%ad %h)" --abbrev-commit --date=short -1 результат потом попадает в h-файл. Получается в итоге: #define GITHASH "(2017-02-03 db74878)" в итоге и дату видно и не нужен длинючий hash. По дате можно определить "новизну" билда, а по hash найти конкретный коммит Изменено 6 февраля, 2017 пользователем johnshadow Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться