shan (12.10.2022 20:51, просмотров: 412) ответил my504 на Откуда взялась странная мысль о совместимости на уровне кода? Из
пин2пин совместимости, да и то неполной? Совершенно разная
периферия, хоть местами и похожая. Там и DMA другой... Я драйверы
все переписываю заново. Прежним остается только аппаратно
независимый код. Совместимость по пинам позволяет достаточно легко
войти на рынок, вытеснив конкурента ценой и отсутствием
необходимости дорабатывать печатные платы. Но никто прежний код не
обещал - это не клоны.-
- Меня в таких делах больше волнует объём тестирования. Универсальную
прошивку нужно тестировать на двух (в вашем случае) вариантах
железа. Если у вас тестирование делается тривиально, — отлично,
повезло. - SciFi(13.10.2022 15:29)
- зачем? если код выбора будет не зависим и не подлежал изменению?
Особенно при не "тривиальном")))) тестирование, а, например,
автоматизированном. Oman(119 знак., 13.10.2022 15:35)
- Что зачем? Тестирование? Теоретически любое изменение прошивки
может сломать любую функцию на любом варианте железа.
Соответственно, если функций N, вариантов железа M, то тестировать
нужно N*M комбинаций. Это в общем случае. Но вам виднее, конечно. - SciFi(13.10.2022 15:41)
- я молчу про TDD. Но если ваш код не тестируется как черный ящик(кроссплатформенность, модульность, независимость и т.д.) вы просто себе же геморрой делаете, вопрос к вашей архитектуре. Платформозависимый код можно проверять на любой плате, где такой проц или такая микруха. Боитесь, что пишет не туда - ну делаете дампы до и после, анализируете map. При желание все можно автоматизировать. Уж точно не проверять, то что было не изменено. - Oman(13.10.2022 16:15)
- Абсолютное большинство функций используется на всех вариантах железа, поэтому изменение функции требует точно такое же количество проверок. - AlexBi(13.10.2022 16:15)
- Что зачем? Тестирование? Теоретически любое изменение прошивки
может сломать любую функцию на любом варианте железа.
Соответственно, если функций N, вариантов железа M, то тестировать
нужно N*M комбинаций. Это в общем случае. Но вам виднее, конечно. - SciFi(13.10.2022 15:41)
- зачем? если код выбора будет не зависим и не подлежал изменению?
Особенно при не "тривиальном")))) тестирование, а, например,
автоматизированном. Oman(119 знак., 13.10.2022 15:35)
- "Доработка вылилась всего лишь в добавлении 10-15"... POV(53 знак., 13.10.2022 14:43)
- SDK, SPL не применял и думаю в даном случае (прошивка одновременно для STM и ARtery) это невозможно. Работаю напрямую с регистрами. Чтобы не конфликтовали имена регистров и битов для АТ с такими же для STM, подправил .h файлы для АТ(вложил ранее). Например USART1 на USART1_AT, структуру регистров USART на USART_AT. - shan(14.10.2022 08:58)
- У меня тоже самое, но я не вижу смысла в совместимом коде хотя бы
потому, что всегда есть возможность автоматического выбора прошивки
при загрузке. А переход на АТ не кратковременный и если даже с АТ
придется уйти, то это будет точно не STM. - my504(13.10.2022 08:32)
- Смысл в том, чтобы поддерживать большое количество пользователей с изделиями с запаянными STM и новыми с АТ. Реализованный более 10 лет назад алгоритм смены прошивок не предусматривал автоматический выбор прошивок и наличие прошивок для разных МК. Сегодня оказалось проще сделать универсальные прошивки, чем изменить алгоритм смены прошивок. Тем более у заказчиков в основном корпоративные сети без выхода в Интернет и полностью автоматическая смена прошивок запрещена shan(119 знак., 14.10.2022 09:09)
- Злые языки пишут, что пиндосы скупили СТМ. И вовсе не для того,
чтоб микросхемы делать. - Kpoк(13.10.2022 09:05)
- Где об этом можно почитать? - AndreasW(13.10.2022 11:14)
- Сорока на хвосте принесла - Kpoк(13.10.2022 11:16)
- Где об этом можно почитать? - AndreasW(13.10.2022 11:14)
- Меня в таких делах больше волнует объём тестирования. Универсальную
прошивку нужно тестировать на двух (в вашем случае) вариантах
железа. Если у вас тестирование делается тривиально, — отлично,
повезло. - SciFi(13.10.2022 15:29)