[Arlleex 131]

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

Тоже не вижу проблемы: есть устройство, поддерживающее все варианты работы...

Хорошо, когда о том, что оно должно поддерживать все варианты работы, известно еще в начале разработки ПО. Далеко не всегда так бывает.

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

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

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

[jcxz 184]

Предлагаю вернуться к исходной теме треда. 

Кто-нить может поделиться успешной историей переезда на новый МК из-за текущей ситуации? С какого и на какой МК мигрировали?

Что-то я сейчас смотрю: из более-менее известных и не китайских МК, в наличии с некоторым разнообразием представлены только EFM32 (Silicon Labs). Судя по моузеру. Мигрировал ли кто на них? Расскажите!

[mantech 34]

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

Все это звучит и выглядит гладко ровно до того момента, когда все эти внутренние "проверки на совместимость" не начнут влиять на работу алгоритмов.

Ну тат-то он как раз описал вполне годный алгоритм оценки кол-ва уст. памяти и пр...

3 минуты назад, jcxz сказал:

в наличии с некоторым разнообразием представлены только EFM32 (Silicon Labs).

И еще тут у кого-то проскакивала мысль про кортексы от микрочипа, или уже усе, сдулись...

[Arlleex 131]

Некоторое время назад, по моему мнению, у многих была некая "аллергия" на чипы в уродских корпусах QFN и BGA, и определенная номенклатура годных привычных МК еще держалась в продаже по вполне низким ценам. Ну то есть я видел, что TQFP-шки смели первыми. QFN вслед за ними, а вот BGA еще иногда держатся - не все готовы к заморочкам с монтажом, видимо.

[aaarrr 63]

39 minutes ago, jcxz said:

было: "v1.11", что как бы намекает на как минимум сотню(!) версий

Отнюдь. Мало кто последовательно нумерует версии от 0.00 с шагом 0.01; Видя железку с версией 1.11 я бы скорее предположил один из двух вариантов:

- версия 1.10 была сугубо внутренней

- изменения 1.10->1.11 минимальны, вряд ли вообще требуют разных версий встраиваемого софта

Т.е. это, скорее всего, только третья версия 1.00->1.10->1.11

 

28 minutes ago, jcxz said:

Кто-нить может поделиться успешной историей переезда на новый МК из-за текущей ситуации? С какого и на какой МК мигрировали?

У меня пока под замену пошел только источник PoE на Si3402. МК остались те же, не пришлось ничего спешно переделывать.

[Ruslan1 16]

2 hours ago, Arlleex said:

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

Если это так сложно получается и реально влияет на надежность работы- то, конечно, так делать не нужно.

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

[Ruslan1 16]

3 hours ago, Arlleex said:

Этот пример как раз затрагивает изменение логики (ведь взаимодействие по USB с модемом будет уже не такое, как с UART-модулем).

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

 

 

Quote

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

Не вижу совсем проблемы. Конфигугируете в своем устройстве что тут протокол#1, там- протокол#2, и вперед. Как сконфигурируете- ту часть кода и запустит. А прошивка одна и та же.

Если же не код раздут и перестал помещаться в память- то да, нужно делить. Других причин множить прошивки не вижу.

3 hours ago, Arlleex said:

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

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

2 hours ago, Arlleex said:

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

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

Про "распараллеливание саппорта" вообще жестоко, это ж как Вас достали "умельцы", если Вы это благом считаете....

 

[Ruslan1 16]

2 hours ago, jcxz said:

Предлагаю вернуться к исходной теме треда. 

Кто-нить может поделиться успешной историей переезда на новый МК из-за текущей ситуации? С какого и на какой МК мигрировали?

Что-то я сейчас смотрю: из более-менее известных и не китайских МК, в наличии с некоторым разнообразием представлены только EFM32 (Silicon Labs). Судя по моузеру. Мигрировал ли кто на них? Расскажите!

Нет. Обычно дешевле купить старый МК в 10 раз дороже чем все переделывать.

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

[jcxz 184]

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

Нет. Обычно дешевле купить старый МК в 10 раз дороже чем все переделывать.

"Обычно" это вы говорите про себя. У вас видимо серия маленькая или вообще штучно. А кто-то ведь делает и тысячи шт. в год и больше. И "в 10 раз" для них будет равносильно разорению. Или хорошим стимулом переезда.

У меня вот один знакомый (у них объёмы около 1000/год) думает как раз на что переехать. Перспектива покупать на порядок дороже для него не вариант.

И ещё важно: какова доля стоимости эл.комплектации в стоимости всего изделия. Тоже бывает по-разному.

Так что "обычно" - у всех разное.

[Ruslan1 16]

4 hours ago, jcxz said:

"Обычно" это вы говорите про себя. У вас видимо серия маленькая или вообще штучно. А кто-то ведь делает и тысячи шт. в год и больше. И "в 10 раз" для них будет равносильно разорению. Или хорошим стимулом переезда.

У меня вот один знакомый (у них объёмы около 1000/год) думает как раз на что переехать. Перспектива покупать на порядок дороже для него не вариант.

И ещё важно: какова доля стоимости эл.комплектации в стоимости всего изделия. Тоже бывает по-разному.

Так что "обычно" - у всех разное.

Все всегда  упирается в деньги и время. Если посчитали, что переход на новый МК (или ПЛМ) выгоден- то да, его нужно делать. И чем сложнее изделие, тем проблематичнее такой переход. Но чем больше тираж- тем больше  вероятность перехода.  Эти кривые где-то пересекаются, и вот эта точка у каждого изделия своя.

[blackfin 16]

11 hours ago, Ruslan1 said:

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

Хорошую тему затронули. Ожидаю 100500 страниц бессмысленного и беспощадного трёпа на ближайшие пол-года.. 

Quote

"Чем меньше женщину мы больше, тем больше меньше она нас.." ©© Поэт..

[Ruslan1 16]

20 minutes ago, blackfin said:

Хорошую тему затронули. Трепать - не перетрепать. Ожидаю 100500 страниц бессмысленного и беспощадного трепа на ближайшие пол-года.. 

Так этта... Нету деталей- есть время  потрепаться, есть детали- нету времени.... Опять же две кривые.... 

[vladec 7]

19 часов назад, aaarrr сказал:

У меня пока под замену пошел только источник PoE на Si3402.

Извиняюсь, что не в тему, а что случилось с Si3402, а то мы их много используем?

[Arlleex 131]

35 минут назад, vladec сказал:

Извиняюсь, что не в тему, а что случилось с Si3402, а то мы их много используем?

В ЧиД-е 87 штук лежат пока что - забирайте, пока есть.

[aaarrr 63]

37 minutes ago, vladec said:

Извиняюсь, что не в тему, а что случилось с Si3402, а то мы их много используем?

Кончились вдруг.

 

2 minutes ago, Arlleex said:

В ЧиД-е 87 штук лежат пока что - забирайте, пока есть.

Это Si3402A