Открыть список
Как стать автором
Обновить

Комментарии 12

Во-первых, насколько мне известно, U-Boot не поддерживает dsPIC.
А во-вторых, вопрос был не в том какой загрузчик брать, а о том, как этот загрузчик скомпоновать в одной прошивке с основным проектом.
Про Линукс тоже не сказано, что он поддерживает ту или иную программно-аппаратную архитектуру, в которую его портируют «умелые руки»)) На мой взгляд, у Вас неправильный подход к разработке… Во-первых, U-Boot — загрузчик с открытыми исходниками и модульный — позволяет портировать нужные компоненты под любой МК (все зависит от квалификации разработчика). Во-вторых, на моей практике не встречался еще аппаратно-программный проект, в котором отсутствовала бы фаза тестирования-отладки-настройки и железа и ПО — на этом этапе приходится часто перепрошивать МК и перекраивать железо. В процессе же уже серийного производства загрузчик прошивается на «железном» этапе и с помощью его происходит сначало загрузка технологического и тестового ПО для проверки аппаратной части и сдаче ОТК, а уж потом шьется боевое ПО.
При чем здесь Linux и архитектура МК? На мой взгляд, у Вас недостаточно опыта работы на серьезных предприятиях. Особенно если судить по нижеследующему комментарию.

Процесс разработки изделия и серийное производство — два кардинально различающихся этапа в производственном цикле. Естественно, что на этапе разработки собираются и проверяются десятки прошивок. Но когда изделие уходит в серию интересна только одна — та которая является финалом разработки. Если для прохождения ОТК требуется особое тестовое ПО — то это просто немыслимая глупость. Нормальное производство, выпуская изделие, собирает изделие с финальной прошивкой, а затем проводит «техпрогон» и другие проверки предписанные в технической документации, созданной разработчиками. Если это не так, то как минимум это не соответствует международным нормам, включая пресловутый ISO 9001.
Кажется мне, что это Вы как раз не разрабатывали и не запускали в серию ни одного изделия. На серийном производстве из каждой партии выбирают определенное кодличество изделий (или все, если изделие «серьезное») и «прогоняют» их по ТУ (Технические Условия, если не в курсе). Так вот чтобы эти проверки (в данном случае затрагивающие «специальные свойства» изделия и его аппаратную часть) осуществить, зачастую требуется перевести изделие в «необычное» состояние, для этого и необходимы и технологическое оборудование и технологические прошивки. А еще чаще бывает, что Заказчик даже заводу-изготовителю не предоставляет реальных прошивок требуемых алгоритмов, требуя, чтобы они вводились на месте эксплуатации. Так то.
Это все справедливо только для промежуточных изделий-полуфабрикатов. Например, у завода заказывается только собранная плата, а заказчик монтирует ее и заливает ПО. В таком случае, возможно, на заводе и сделают какую-то тестовую прошивку.

Но изготовление изделий-полуфабрикатов — это не серьезное создание конструктивно законченного изделия. И уж точно это никак не связано с темой публикации.
С Вами все ясно… Оставайтесь при своем мнении… Вы, наверное, каждый день клепаете изделия для ВПК и «регуляторов»…
Тогда у меня возникает следующий вопрос: «Знакомы ли Вы с процессом разработки аппаратно-программных комплексов — от макетирования до серийного производства?» В моем опыте еще ни разу не встречалось ни одно устройство, которое бы не проходило этапы отладки-тестирования-корректировки. Поэтому наличие отладочных и технологических интерфейсов просто необходимо, чтобы те же тестеры, настройщики и программисты не проклинали Вас))) А раз так, то использование проверенного и гибкого в настройках загрузчика — это еще одна необходимость. Есть исходники U-Boot, так вот гораздо проще портировать нужный Вам его функционал, чем писать свой «велосипед» с присущими «велосипедными багами». Еще U-Boot спроектирован так, что позволяет легко менять (обновлять) Вашу прошивку на уже работающем (проданном, находящимся у Заказчика) оборудовании (конечно, если вы предусмотрели это «правило хорошего тона»). Еще хочется добавить, что даже в серийном производстве (приемо-сдаточные испытания все прошли, Ваше изделие получило литеру «О1») есть этапы промпежуточного контроля, на которых в устройство зашивается тестовое (технологическое) ПО, чтобы, например, получить печать ОТК.
Эти утверждения, как минимум, — спорные:
[quote]Это вполне приемлемо для опытных образцов изделий или для мелкосерийного производства. А что делать, если производство крупносерийное? Или сборка проводится автоматами (а может людьми с функционалом автоматов) — прошил, впаял? Тогда разумно убрать из алгоритма 3го пункт — объединить в одной прошивке и основную программу и загрузчик.[/quote]
В начале этапа «In circuit test» полностью автоматически заливается ПО и всё заверте… Вариантов это сделать — масса. Начиная от прошивки через JTAG, через «bootloader» через JTAG — остальное через «bootloader» и высокоскоростной интерфейс, до использования «default bootloader» от производителя микроконтроллера.
[quote]Первое, что хотелось бы отметить: загрузчик не должен быть самостоятельной программой. Конечно, в процессе отладки загрузчика его можно реализовать как самостоятельную программу. Но как только Вы планируете его встроить в другую программу его необходимо специально подготовить.[/quote]
Каковы Ваши доказательства? Почему не «программу надо специально подготовить для работы с „bootloader'ом“?
Еще раз обращу Ваше внимание, что цель следующая — вынул МК из упаковки, сунул в программатор, прошил один раз, впаял в плату, все работает. Нужно избежать припаивания дополнительного разъема для внутрисхемного программирования (JTAG, SWD например) или дополнительных шагов по загрузки прошивки через bootloader.

Каковы Ваши доказательства? Почему не «программу надо специально подготовить для работы с „bootloader'ом“?

Все просто: в МК не может быть больше одного набора конфигурационных бит и векторов прерываний. Естественно, что приоритет у основной программы.
На первый абзац уже дали достаточно развёрнутые ответы. Разъёмы (хотя-бы в виде контрактных площадок и иголок) были, есть и будут. Эти правила хорошего тона называются «Design for manufacturing» и «Design for testability»
При чем здесь контактные площадки для отладочного разъема и предмет статьи? Если нечего сказать — так и не говорите.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.