[Ruslan1 16]

On 12/11/2021 at 10:43 PM, jcxz said:

А как это возможно? У ПО вроде версия всегда одна и та же. Как она может стать больше или меньше? 

Ну, это вообще легко. ПО одно и то же (новое), но если железо не позволяет- то нектрорые функции не стартуют и, соответсвенно не занимают ресурсов.  Динамическое выделение памяти, запуск задач по условиюи прочее. То есть оно всегда есть в прошивке, но работать будет не везде. А если новое ПО физически не может быть размещено на старом железе- то об этом должен думать бутлоадер на этапе замены прошивки (или на этапе загрузки)

On 12/11/2021 at 7:18 AM, mantech said:

Да тут больше не разработчик озадачится, а это ад для снабженца...

Ад для снабженца- если низкое качество разработки приводит к большому количеству ремонтов. При чем тут количество версий?

[Arlleex 131]

Что-то не вяжется у меня какой-то непросветный лес прошивок и версий в устройствах на МК. Не линукс или андроид в конце концов. И все эти танцы с "новое ПО должно работать на старом железе; если тут так, то этот код не выполняем, а если сяк - то выполняем, но если тут вот так... и т.д." в конечном счете только кратно усложняют ПО и его поддержку, нафиг-нафиг. Новое устройство есть новое устройство, и для него отдельная папка в репозитории. А вот разные версии ПО для одного и того же устройства (одного и того же железа) вполне нормальное явление. У меня, например, устройство всегда умеет сообщать версию железа и версию ПО. Если железо было переделано, но прошивка под него полностью совместима с предыдущей версией железа (например, просто изменили габариты платы), в загрузчике можно "переопределить" налету версию железа, которая прошьется в МК, несмотря на то, что шьется бинарь от "старого" железа.

[aaarrr 68]

5 minutes ago, Arlleex said:

И все эти танцы с "новое ПО должно работать на старом железе; если тут так, то этот код не выполняем, а если сяк - то выполняем, но если тут вот так... и т.д." в конечном счете только кратно усложняют ПО и его поддержку, нафиг-нафиг.

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

[mantech 36]

4 минуты назад, aaarrr сказал:

но лучше заложить отдельный механизм изначально.

Тут-то как-раз все просто, версия железа закладывается в бутлоадере.

[Arlleex 131]

7 минут назад, aaarrr сказал:

Всего-то нужна возможность определить версию железа изнутри...

Ага, а потом везде где функционал отличается городить static-флаги этих самых "версий" железа, и код начнет обрастать лесом из if(isHwADCExternal) (типа железо с внешним SPI-АЦП), будет куча веток управления, куча вариантов драйверов и т.д. Оно того стоит?

[mantech 36]

1 час назад, Ruslan1 сказал:

При чем тут количество версий?

Если в разных версиях железа используется разная комплектация, причем в одно и то же устройство могут воткнуть блоки с разными аппаратными версиями... 

7 минут назад, Arlleex сказал:

будет куча веток управления, куча вариантов драйверов и т.д. Оно того стоит?

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

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

Изменено 13 декабря, 2021 пользователем mantech

[aaarrr 68]

9 minutes ago, mantech said:

Тут-то как-раз все просто, версия железа закладывается в бутлоадере.

Лучше в железе.

 

8 minutes ago, Arlleex said:

Оно того стоит?

Стоит: у пользователя нет головняка. А раз нет у пользователя, то нет и у производителя.

[Arlleex 131]

Только что, aaarrr сказал:

Стоит: у пользователя нет головняка. А раз нет у пользователя, то нет и у производителя.

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

[aaarrr 68]

4 minutes ago, Arlleex said:

кучи разных

Сколько - две, три? У меня обычно больше аппаратных версий не возникает за все время жизни изделия.

 

5 minutes ago, Arlleex said:

логики

Логики? У нас ведь одно устройство.

 

7 minutes ago, Arlleex said:

тяжелее отлаживать, а значит потенциально проще вносить в такой код баги

Да ничем не тяжелее. Те же баги будут и при создании отдельной прошивки для каждой версии железа.

 

А новые программные фичи добавлять в N разных прошивок сильно удобнее и безопаснее в плане "багов"?

[Arlleex 131]

1 час назад, aaarrr сказал:

Сколько - две, три? У меня обычно больше аппаратных версий не возникает за все время жизни изделия.

Если разговор идет, например, о том, какой из UART-ов использовать для внешнего RS-485 (основываясь на версии железа), то это одно дело. Получили при старте версию, настроили нужный UART, все ок: да, будет удобно. Другое дело, когда новая ревизия платы концептуально влияет на ПО: например, модем, работающий по UART-у, не нашли в продаже, и в новых ревизиях заложили USB-шный, у которого и протокол общения совершенно иной, а некоторые возможности (функционал) старого модема вовсе отсуствуют и их нужно эмулировать программно. Этот пример как раз затрагивает изменение логики (ведь взаимодействие по USB с модемом будет уже не такое, как с UART-модулем). Другой пример: к устройству подключается датчик давления. Причем датчик с аналоговым выходом, т.е. девайс внутренним АЦП оцифровывает сигнал, проводит некоторую обработку (ту же фильтрацию) и использует результат для внутренних алгоритмов работы. Проходит совещание, принимается решение на новых рабочих местах установить цифровые датчики, которые работают по CAN-у. Они почти сразу выдают результат в попугаях, которые нужно лишь перевести в свои. И надо же: в устройстве как раз торчит CAN-интерфейс. Только одна загвоздка: датчик работает по CANOpen, а по CAN-у девайса ходит "свой" протокол, и менять его на CANOpen на уже работающих местах (старых) нельзя, а на новых - пожалуйста. ИМХО, это уже целое поле с граблями - проще вести 2 версии ПО.

[Ruslan1 16]

1 hour ago, mantech said:

Если в разных версиях железа используется разная комплектация, причем в одно и то же устройство могут воткнуть блоки с разными аппаратными версиями... 

Да, именно так. И пользователь даже не знает какая версия платы у него стоит, это задача разработчика софта сделать так, чтоб переход прошел безболезненно.

Например, у меня в одной конструкции уже давно ставится 32МБ RAM, но для совместимости со старым железом всегда используются только первые 8 МБ (стараемся, хватает). Инициализация, конечно, разная. Таким образом, очень старая прошивка (которая не знала о версии плат с 32МБ) не будет работать на новых платах- напишет RAM Error на дисплее. А новая версия на старых платах работать будет, потому что она поймет что там за память.

Или вот еще пример- подключаются платы с двумя разными модемами. Конечно, это задача софта определить какой модем подключен и правильно с ним работать.

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

Я долго еще трындеть на эту тему могу, у меня историй много :)

 

Тут принципиальный момент- софт должен иметь возможность однозначно определить, какая из поддерживаемых версий железа используется, косвенно (по отклику системы на подаваемые сигналы, как в случае с изменением аналоговой части) или напрямую (если железо выдает какой-то идентификатор, например в случае с модемами).  Кстати, в одном сложном проекте изначально, с самой первой версии,  заложили на каждую из разрабатываемых плат I2C флешку 2 кбита и общую шину, чтобы хранить, например, версию железа, которую центральный процессор может прочитать. Флешки паяются, но до сих пор ни разу эта фича не использовалась- обходимся без подсказок.

1 hour ago, aaarrr said:

Сколько - две, три? У меня обычно больше аппаратных версий не возникает за все время жизни изделия.

 

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

[Arlleex 131]

8 минут назад, Ruslan1 сказал:

И пользователь даже не знает какая версия платы у него стоит, это задача разработчика софта сделать так, чтоб переход прошел безболезненно.

Все это звучит и выглядит гладко ровно до того момента, когда все эти внутренние "проверки на совместимость" не начнут влиять на работу алгоритмов. Особенно, например, в приложениях с моторами с их контурами обратных связей или каким-нибудь прикладным ЦОС в реальном времени.

[aaarrr 68]

8 minutes ago, Arlleex said:

Только одна загвоздка: датчик работает по CANOpen, а по CAN-у девайса ходит "свой" протокол, и менять его на CANOpen на уже работающих местах (старых) нельзя, а на новых - пожалуйста. ИМХО, это уже целое поле с граблями - проще вести 2 версии ПО.

Тоже не вижу проблемы: есть устройство, поддерживающее все варианты работы, есть конфигурация, указывающая, в каком режиме и с кем работает CAN в конкретном случае.

[Ruslan1 16]

1 hour ago, Arlleex said:

Что-то не вяжется у меня какой-то непросветный лес прошивок и версий в устройствах на МК. Не линукс или андроид в конце концов. И все эти танцы с "новое ПО должно работать на старом железе; если тут так, то этот код не выполняем, а если сяк - то выполняем, но если тут вот так... и т.д." в конечном счете только кратно усложняют ПО и его поддержку, нафиг-нафиг.

"Непросветный лес прошивок" как раз и есть ночной кошмар саппорта. Прошивка-одна, поддерживающая все что эксплуатируется под этим названием.

[jcxz 191]

1 час назад, aaarrr сказал:

Сколько - две, три? У меня обычно больше аппаратных версий не возникает за все время жизни изделия.

2,3 - как раз нормально. Но в том посте, с которого пошёл сыр-бор, было: "v1.11", что как бы намекает на как минимум сотню(!) версий. Сотня версий железа???