VLLV (31.01.2022 15:18, просмотров: 10192)-
- Я для себя после нескольких попадалов сделал такой вывод. Основное
по полностью отвязано от мк, все темы работы с переферией вынесены
в bsp уровень. Функции bsp Всех мк имеют одинаковые названия и
аргументы. Очень удобно! - Aleksey_75(01.02.2022 16:28)
- Это только часть проблемы, сейчас будем портировать с STM32 на LPC, эту часть обкатаем. - VLLV(01.02.2022 16:39)
- ПО - фиг с ним. Как это в схемах по госту узаконить? symbions(2 знак., 01.02.2022 00:14)
- Проблем то, выпустить отдельную схему. Сейчас на пакет ПО из 16
проектов имеется 8 плат с разными схемами, есть на одной плате 3
проекта, есть на одной плате 1 проект. В спецификации переменные
данные для исполнений, включая версию ПО. - VLLV(01.02.2022 10:51)
- Это хорошо. Но вот у меня прибор - один и тот же, только в
зависимости от цены (а теперь и доступности) на МК ставится разный
МК (+ пара пассивных компонент). Вот вечная проблема - заказцик
заказал какой-нибудь АБВГ103, а он может на тиньки быть или пике12.
И как схему сделать-то? symbions(293 знак., 01.02.2022 10:56)
- Да, такая проблема тоже есть - наименование прибора одно, а начинки
разные. Я самоустранился, производство, снабженцы и контрактор
как-то договариваются. - VLLV(01.02.2022 11:20)
- Плюниуть на всё и уехать к вам в Кацапетовку :) - symbions(01.02.2022 19:20)
- ...только тщательно вымыть сапоги. чтобы не принести с собой цивилизацию :) - Cкpипaч(01.02.2022 19:24)
- Плюниуть на всё и уехать к вам в Кацапетовку :) - symbions(01.02.2022 19:20)
- Да, такая проблема тоже есть - наименование прибора одно, а начинки
разные. Я самоустранился, производство, снабженцы и контрактор
как-то договариваются. - VLLV(01.02.2022 11:20)
- Это хорошо. Но вот у меня прибор - один и тот же, только в
зависимости от цены (а теперь и доступности) на МК ставится разный
МК (+ пара пассивных компонент). Вот вечная проблема - заказцик
заказал какой-нибудь АБВГ103, а он может на тиньки быть или пике12.
И как схему сделать-то? symbions(293 знак., 01.02.2022 10:56)
- Проблем то, выпустить отдельную схему. Сейчас на пакет ПО из 16
проектов имеется 8 плат с разными схемами, есть на одной плате 3
проекта, есть на одной плате 1 проект. В спецификации переменные
данные для исполнений, включая версию ПО. - VLLV(01.02.2022 10:51)
- К примеру, STM32F207VGT6 стоит сейчас дешевле чем F205, код переписывать не пришлось, а мне пришлось смириться с тем, что раз в год штук 5 плат переразвести надо. - Visitor(31.01.2022 20:09)
- Ультимативно уведомить руководство что "утоптать ПО из 240 К в 128
К" = полностью новое изделие со всеми вытекающими последствиями. А
если нет комплектующих - пусть закрывают бизнес. А чо,
автосборочные производства по всему миру встают и никто не жужжит.
(я после года истерик от руководства "то того нет то сего нет" в
полном офигении. Так что "нет компонетов" --> идите нахуй). - 3m(31.01.2022 20:00)
- 1. Спокойно, уже 150 к, правда последние майнятся все дольше и
дольше. 2. Сейчас самая выигрышная стратегия для меня - делать вид,
что работаю (все равно никто не разберется), а не ультиматумы
устраивать. - VLLV(31.01.2022 20:11)
- История одного байта [] NeoPower(1 знак., 01.02.2022 00:42, ссылка)
- 1. Спокойно, уже 150 к, правда последние майнятся все дольше и
дольше. 2. Сейчас самая выигрышная стратегия для меня - делать вид,
что работаю (все равно никто не разберется), а не ультиматумы
устраивать. - VLLV(31.01.2022 20:11)
- Проекты на одном железе в одном воркспайсе, если много - делю по
типам. Oman(1643 знак., 31.01.2022 17:35)
- Спасибо - VLLV(31.01.2022 20:12)
- два разных прибора - это всегда два разных проекта. LordN(792 знак., 31.01.2022 16:15)
- Может есть смысл сделать общие библиотеки и уже их подключать на
разных ветках устройств. При изменении библиотеки все изменения
отразятся сразу во всех проектах. - PeterD(31.01.2022 16:09)
- При изменении библиотеки прошивка перестает влезать в Stm32f030. Привет общим библиотекам! - 3m(31.01.2022 20:06)
- Цитата: "При изменении библиотеки все изменения отразятся сразу во
всех проектах". Cкpипaч(219 знак., 31.01.2022 16:48)
- Так в этом и смысл.. глюк ловится в одном конкретном месте. - PeterD(31.01.2022 17:03)
- вопрос, что ты будешь делать если обнаружишь багу в общей части
всех ста своих проектах? Будешь в каждый проект копипастить
изменения и тестировать каждый проект полностью? - abivan(31.01.2022 16:58)
- Цитата: "without warranty of any kind". Cкpипaч(287 знак., 31.01.2022 17:08)
- Ничего он не будет делать, так как заказчики тех ста проектов за это не заплатили. - symbions(31.01.2022 17:05)
- Конечно, думаю над этим. Сдерживает 1) нехватка человеческих ресурсов 2) перевод всего в исполняемый код зацепит и ресурс контроллера. - VLLV(31.01.2022 16:18)
- Каждый *.c файл содержит обвязку типа LightElf(790 знак., 31.01.2022 15:56)
- Что вы делаете если функциональность вариантов не полностью идентична ? - 3m(31.01.2022 20:31)
- Между прочим, вменяемый тулчейн умеет выкидывать из прошивки объекты, которые нигде не используются. То есть зачастую можно закомментировать один вызов функции, который тянет за собой тонны кода, и прошивка сильно сдувается. Возможно, так можно уменьшить кол-во #if/#endif. - SciFi(31.01.2022 15:41)
- Каждый проект - отдельно. Ни грамма "общего" кода. Если какая-то
библиотека используется в двух проектах, она храниться в двух
независимых копиях. - Cкpипaч(31.01.2022 15:39)
- Может хранить библиотеку в гите, а в проект фетчить конкретную
ревизию библиотеки? - LightElf(31.01.2022 15:59)
- Можно и так. Главное - никакое изменение "внутри проекта" не дожно иметь ни малейшего шанса повлиять на другие проекты. Cкpипaч(191 знак., 31.01.2022 16:10)
- Это точно тупик. Сейчас образовались два таких пакета для приборов
с разными интерфейсами, и 50 процентов времени уходит на
копирование изменений из одного пакета в другой :( - VLLV(31.01.2022 15:46)
- Сколько из этих пресловутых 50% уходит на ТЕСТИРОВАНИЕ? :о) - Cкpипaч(31.01.2022 15:58)
- Проблему "общего кода" решает система контроля версий. В каждом
проекте используется своя проверенная с данным проектом версия
библиотеки. Исправление ошибок и доработка библиотеки выполняется
при этом в "одном экземпляре". А добавить эти исправления в старый
проект можешь по своему желанию. il-2(1 знак., 31.01.2022 16:08, ссылка)
- У каждого свой путь. Можно "контроля версий", а можно просто проектные папки. Которые тоже запихнуть под контроль версий, но в виде строго отдельных проектов. Cкpипaч(239 знак., 31.01.2022 16:16)
- Просто проблема перейдет в другую плоскость - какую ревизию
библиотеки использовать ? - VLLV(31.01.2022 16:13)
- Расслабься, умные люди уже за тебя все придумали :-) В Mercurial
эта штука называется subrepositories, в git - submodules(могу
соврать - поправьте). Нормальная система контроля версий сама
следит, какая версия библиотеки (субрепозитория) будет привязана к
текущему коммиту основного репозитория проекта. Так что на бумажке
ничего не прийдется записывать :-) - il-2(31.01.2022 16:24)
- Работаю с external svn, про бумажку знаю :) Смотри, имеется два
проекта. В одном проекте нужно поменять общую библиотеку, в другом
не обязательно, не меняем. А потом вдруг нужно в той же библиотеке
поменять для проекта, в котором не менялось. Выбор: то ли дробить
библиотеки, то ли вводить ненужные изменения. В максиме Скрипача о
раздельных проектах есть рациональное зерно, только у него проекты
трудоемкостью не 5 человеко-лет. - VLLV(31.01.2022 17:07)
- Библиотеки (субрепозитории) у каждого проекта свои (как любит
Скрипач). Но внешний репозиторий библиотек у всех проектов один.
Через него и идет обмен. il-2(890 знак., 01.02.2022 05:56)
- Вот на этом: "не забывать обновлять" и надо отбросить этот способ -
редко не забывает. - symbions(01.02.2022 08:18)
- Я использую оба способа. В старых проектах - первый (т.к. там
исторически либы были скопированы в каталог проекта, а с недавнего
времени делаю ссылки в новых проектах. Дискомфорта не наблюдаю.
Может потому, что при переключении на другой проект, первое и
естественное движение - это глянуть в его репозиторий, чтобы узнать
какой коммит в данный момент в рабочей директории. - il-2(02.02.2022 05:49)
- Нет. ПРосто Вы очень собранный и самодисциплинированный человек. Тут в институте ввели цифровую подпись, на каждом собрании говорили, что имя файла после подписывания менять нельзя, иначе файл не откроется. И что? Как минимум 30% вторых подписантов подписывают файл не "подписать_отчёт.odt.p2s" а файл "подписать_отчёт.odt (1)" - а автоматической системе учёта потом мозги сносит. И у нас в отделе (бывшем, правда) из 5 программистов, трое будут забывать всегда, 1 - через раз, symbions(97 знак., 02.02.2022 08:41)
- Я использую оба способа. В старых проектах - первый (т.к. там
исторически либы были скопированы в каталог проекта, а с недавнего
времени делаю ссылки в новых проектах. Дискомфорта не наблюдаю.
Может потому, что при переключении на другой проект, первое и
естественное движение - это глянуть в его репозиторий, чтобы узнать
какой коммит в данный момент в рабочей директории. - il-2(02.02.2022 05:49)
- Вот на этом: "не забывать обновлять" и надо отбросить этот способ -
редко не забывает. - symbions(01.02.2022 08:18)
- Библиотеки (субрепозитории) у каждого проекта свои (как любит
Скрипач). Но внешний репозиторий библиотек у всех проектов один.
Через него и идет обмен. il-2(890 знак., 01.02.2022 05:56)
- Работаю с external svn, про бумажку знаю :) Смотри, имеется два
проекта. В одном проекте нужно поменять общую библиотеку, в другом
не обязательно, не меняем. А потом вдруг нужно в той же библиотеке
поменять для проекта, в котором не менялось. Выбор: то ли дробить
библиотеки, то ли вводить ненужные изменения. В максиме Скрипача о
раздельных проектах есть рациональное зерно, только у него проекты
трудоемкостью не 5 человеко-лет. - VLLV(31.01.2022 17:07)
- В новый проект - самую свежую. В старый проект - ту, с которой оно
раньше работало. Если нужно перенести в старый проект фичи из
свежей ревизии - втыкаешь свежую ревизию и смотришь что получилось. - LightElf(31.01.2022 16:17)
- А когда "новый" с минимальными правками получается из сделанного
семь лет назад? - Cкpипaч(31.01.2022 16:29)
- На выбор. Можешь оставить старую, с которой заведомо работает. Можешь подтянуть новую и перетестировать проект, раз уж все равно в него залез. - LightElf(31.01.2022 17:03)
- В отдельной ветке. Главное - ты должен знать чего откуда растёт.
Знать а не помнить. Т.е. иметь возможность в любой момент проверить
этот факт одной командой. - =AlexD=(31.01.2022 16:31)
- Нет уж. Лучше сто независимых проектов. - Cкpипaч(31.01.2022 16:42)
- Да хоть миллион. Речь вообще не про проекты. - =AlexD=(31.01.2022 16:44)
- Нет уж. Лучше сто независимых проектов. - Cкpипaч(31.01.2022 16:42)
- А когда "новый" с минимальными правками получается из сделанного
семь лет назад? - Cкpипaч(31.01.2022 16:29)
- Расслабься, умные люди уже за тебя все придумали :-) В Mercurial
эта штука называется subrepositories, в git - submodules(могу
соврать - поправьте). Нормальная система контроля версий сама
следит, какая версия библиотеки (субрепозитория) будет привязана к
текущему коммиту основного репозитория проекта. Так что на бумажке
ничего не прийдется записывать :-) - il-2(31.01.2022 16:24)
- Да не тестируем мы ни хрена! :) - VLLV(31.01.2022 16:02)
- Мы - тоже! :) - Cкpипaч(31.01.2022 16:23)
- Проблему "общего кода" решает система контроля версий. В каждом
проекте используется своя проверенная с данным проектом версия
библиотеки. Исправление ошибок и доработка библиотеки выполняется
при этом в "одном экземпляре". А добавить эти исправления в старый
проект можешь по своему желанию. il-2(1 знак., 31.01.2022 16:08, ссылка)
- Сколько из этих пресловутых 50% уходит на ТЕСТИРОВАНИЕ? :о) - Cкpипaч(31.01.2022 15:58)
- Может хранить библиотеку в гите, а в проект фетчить конкретную
ревизию библиотеки? - LightElf(31.01.2022 15:59)
- Знакомая ситуация ;-) Чтобы этого избежать, надо делить
функциональность на уровне исходных файлов. Это относится и к
функционалу, и к контроллерам, и к компиляторам (среде разработке).
Вобщем - сделать можно, красивость результата зависит от мозгового
напряжения. Сильно перенапрягаться тоже не стоит :-) - il-2(31.01.2022 15:39)
- Для этого нужно что-бы исходный код не зависел от аппаратной платформы, компилятора, используемой OS и т.д. Это помимо мозгов программиста зачастую требует и дополнительных накладных расходов процессорного времени, если конечно не использовать шаблонную магию, что влечёт за собой уже другие проблемы. - =AlexD=(31.01.2022 15:45)
- Вообще не понял проблемы. Разная функциональность распихивается в
разные *.c файлы, которые просто не подключаются к некоторым
проектам, не компилируются и не линкуются. Что не так? - =AlexD=(31.01.2022 15:32)
- А вызовы этой функциональности? Может быть десяток - разные
обработчики, декларирование данных где-нибудь в общей EEPROM, их
инициализация, и т.д. - VLLV(31.01.2022 15:57)
- Ну main же у каждого проекта свой, там и подключаются необходимые
функции. - =AlexD=(31.01.2022 16:25)
- У меня так не получается, функциональность влияет на все -
например, на набор команд в протоколе, - VLLV(31.01.2022 17:41)
- если бы знал заранее про такое, то наверное бы писал так, что каждый добавляемый модуль имеет функцию init, которая в свою очередь вызывает инициализацию и модификацию базовой неизменной основы, то есть init_module_A вызывает add_new_command(u8 *cmd, *cmd_callback) и тому подобную систему конфигурации на лету. Mahagam(144 знак., 01.02.2022 13:18)
- Поэтому тебе и писали, что нужно напрягать мозги. Если ты хочешь
версионировать прошивки по функциональности, то и модульность
должна проистекать отсюда же, и добиться этого наверняка можно. - =AlexD=(31.01.2022 17:47)
- Дык с мозгами каждый дурак может :) А вообще спасибо за твердо выраженное мнение. - VLLV(01.02.2022 11:50)
- У меня так не получается, функциональность влияет на все -
например, на набор команд в протоколе, - VLLV(31.01.2022 17:41)
- Ну main же у каждого проекта свой, там и подключаются необходимые
функции. - =AlexD=(31.01.2022 16:25)
- А вызовы этой функциональности? Может быть десяток - разные
обработчики, декларирование данных где-нибудь в общей EEPROM, их
инициализация, и т.д. - VLLV(31.01.2022 15:57)
- Я для себя после нескольких попадалов сделал такой вывод. Основное
по полностью отвязано от мк, все темы работы с переферией вынесены
в bsp уровень. Функции bsp Всех мк имеют одинаковые названия и
аргументы. Очень удобно! - Aleksey_75(01.02.2022 16:28)