Comments 12
Чем Вам U-Boot не нравится?
0
Во-первых, насколько мне известно, U-Boot не поддерживает dsPIC.
А во-вторых, вопрос был не в том какой загрузчик брать, а о том, как этот загрузчик скомпоновать в одной прошивке с основным проектом.
А во-вторых, вопрос был не в том какой загрузчик брать, а о том, как этот загрузчик скомпоновать в одной прошивке с основным проектом.
0
Про Линукс тоже не сказано, что он поддерживает ту или иную программно-аппаратную архитектуру, в которую его портируют «умелые руки»)) На мой взгляд, у Вас неправильный подход к разработке… Во-первых, U-Boot — загрузчик с открытыми исходниками и модульный — позволяет портировать нужные компоненты под любой МК (все зависит от квалификации разработчика). Во-вторых, на моей практике не встречался еще аппаратно-программный проект, в котором отсутствовала бы фаза тестирования-отладки-настройки и железа и ПО — на этом этапе приходится часто перепрошивать МК и перекраивать железо. В процессе же уже серийного производства загрузчик прошивается на «железном» этапе и с помощью его происходит сначало загрузка технологического и тестового ПО для проверки аппаратной части и сдаче ОТК, а уж потом шьется боевое ПО.
0
При чем здесь Linux и архитектура МК? На мой взгляд, у Вас недостаточно опыта работы на серьезных предприятиях. Особенно если судить по нижеследующему комментарию.
Процесс разработки изделия и серийное производство — два кардинально различающихся этапа в производственном цикле. Естественно, что на этапе разработки собираются и проверяются десятки прошивок. Но когда изделие уходит в серию интересна только одна — та которая является финалом разработки. Если для прохождения ОТК требуется особое тестовое ПО — то это просто немыслимая глупость. Нормальное производство, выпуская изделие, собирает изделие с финальной прошивкой, а затем проводит «техпрогон» и другие проверки предписанные в технической документации, созданной разработчиками. Если это не так, то как минимум это не соответствует международным нормам, включая пресловутый ISO 9001.
Процесс разработки изделия и серийное производство — два кардинально различающихся этапа в производственном цикле. Естественно, что на этапе разработки собираются и проверяются десятки прошивок. Но когда изделие уходит в серию интересна только одна — та которая является финалом разработки. Если для прохождения ОТК требуется особое тестовое ПО — то это просто немыслимая глупость. Нормальное производство, выпуская изделие, собирает изделие с финальной прошивкой, а затем проводит «техпрогон» и другие проверки предписанные в технической документации, созданной разработчиками. Если это не так, то как минимум это не соответствует международным нормам, включая пресловутый ISO 9001.
0
Кажется мне, что это Вы как раз не разрабатывали и не запускали в серию ни одного изделия. На серийном производстве из каждой партии выбирают определенное кодличество изделий (или все, если изделие «серьезное») и «прогоняют» их по ТУ (Технические Условия, если не в курсе). Так вот чтобы эти проверки (в данном случае затрагивающие «специальные свойства» изделия и его аппаратную часть) осуществить, зачастую требуется перевести изделие в «необычное» состояние, для этого и необходимы и технологическое оборудование и технологические прошивки. А еще чаще бывает, что Заказчик даже заводу-изготовителю не предоставляет реальных прошивок требуемых алгоритмов, требуя, чтобы они вводились на месте эксплуатации. Так то.
0
Это все справедливо только для промежуточных изделий-полуфабрикатов. Например, у завода заказывается только собранная плата, а заказчик монтирует ее и заливает ПО. В таком случае, возможно, на заводе и сделают какую-то тестовую прошивку.
Но изготовление изделий-полуфабрикатов — это не серьезное создание конструктивно законченного изделия. И уж точно это никак не связано с темой публикации.
Но изготовление изделий-полуфабрикатов — это не серьезное создание конструктивно законченного изделия. И уж точно это никак не связано с темой публикации.
0
Тогда у меня возникает следующий вопрос: «Знакомы ли Вы с процессом разработки аппаратно-программных комплексов — от макетирования до серийного производства?» В моем опыте еще ни разу не встречалось ни одно устройство, которое бы не проходило этапы отладки-тестирования-корректировки. Поэтому наличие отладочных и технологических интерфейсов просто необходимо, чтобы те же тестеры, настройщики и программисты не проклинали Вас))) А раз так, то использование проверенного и гибкого в настройках загрузчика — это еще одна необходимость. Есть исходники U-Boot, так вот гораздо проще портировать нужный Вам его функционал, чем писать свой «велосипед» с присущими «велосипедными багами». Еще U-Boot спроектирован так, что позволяет легко менять (обновлять) Вашу прошивку на уже работающем (проданном, находящимся у Заказчика) оборудовании (конечно, если вы предусмотрели это «правило хорошего тона»). Еще хочется добавить, что даже в серийном производстве (приемо-сдаточные испытания все прошли, Ваше изделие получило литеру «О1») есть этапы промпежуточного контроля, на которых в устройство зашивается тестовое (технологическое) ПО, чтобы, например, получить печать ОТК.
0
Эти утверждения, как минимум, — спорные:
[quote]Это вполне приемлемо для опытных образцов изделий или для мелкосерийного производства. А что делать, если производство крупносерийное? Или сборка проводится автоматами (а может людьми с функционалом автоматов) — прошил, впаял? Тогда разумно убрать из алгоритма 3го пункт — объединить в одной прошивке и основную программу и загрузчик.[/quote]
В начале этапа «In circuit test» полностью автоматически заливается ПО и всё заверте… Вариантов это сделать — масса. Начиная от прошивки через JTAG, через «bootloader» через JTAG — остальное через «bootloader» и высокоскоростной интерфейс, до использования «default bootloader» от производителя микроконтроллера.
[quote]Первое, что хотелось бы отметить: загрузчик не должен быть самостоятельной программой. Конечно, в процессе отладки загрузчика его можно реализовать как самостоятельную программу. Но как только Вы планируете его встроить в другую программу его необходимо специально подготовить.[/quote]
Каковы Ваши доказательства? Почему не «программу надо специально подготовить для работы с „bootloader'ом“?
[quote]Это вполне приемлемо для опытных образцов изделий или для мелкосерийного производства. А что делать, если производство крупносерийное? Или сборка проводится автоматами (а может людьми с функционалом автоматов) — прошил, впаял? Тогда разумно убрать из алгоритма 3го пункт — объединить в одной прошивке и основную программу и загрузчик.[/quote]
В начале этапа «In circuit test» полностью автоматически заливается ПО и всё заверте… Вариантов это сделать — масса. Начиная от прошивки через JTAG, через «bootloader» через JTAG — остальное через «bootloader» и высокоскоростной интерфейс, до использования «default bootloader» от производителя микроконтроллера.
[quote]Первое, что хотелось бы отметить: загрузчик не должен быть самостоятельной программой. Конечно, в процессе отладки загрузчика его можно реализовать как самостоятельную программу. Но как только Вы планируете его встроить в другую программу его необходимо специально подготовить.[/quote]
Каковы Ваши доказательства? Почему не «программу надо специально подготовить для работы с „bootloader'ом“?
0
Еще раз обращу Ваше внимание, что цель следующая — вынул МК из упаковки, сунул в программатор, прошил один раз, впаял в плату, все работает. Нужно избежать припаивания дополнительного разъема для внутрисхемного программирования (JTAG, SWD например) или дополнительных шагов по загрузки прошивки через bootloader.
Все просто: в МК не может быть больше одного набора конфигурационных бит и векторов прерываний. Естественно, что приоритет у основной программы.
Каковы Ваши доказательства? Почему не «программу надо специально подготовить для работы с „bootloader'ом“?
Все просто: в МК не может быть больше одного набора конфигурационных бит и векторов прерываний. Естественно, что приоритет у основной программы.
0
На первый абзац уже дали достаточно развёрнутые ответы. Разъёмы (хотя-бы в виде контрактных площадок и иголок) были, есть и будут. Эти правила хорошего тона называются «Design for manufacturing» и «Design for testability»
0
Sign up to leave a comment.
Загрузчик для dsPIC33