billidean 0 5 июня, 2012 Опубликовано 5 июня, 2012 · Жалоба Создал систему Qsys в квартусе 11.1: 1. НИОС 2. on_chip_RAM - озу для НИОСа 3. сис.таймер 4. PIO - выходы, подключенные к лампочкам RAM инициализирую hex-файлом по-умолчанию. Компилю проект, получаю .sof-файл. В NIOS II IDE создаю проект с использованием uC/OS, компилю, все ок. Программирую квартусовским программером кристалл, заливаю из NIOS II IDE в НИОС программу, все тоже хорошо, лампочки мигают. Задача: получить такой .sof-файл, чтобы не нужно было запускать программу НИОСа из NIOS II IDE. Из доки "Developing NiosII Software" вычитал, что нужно расставить галочки в BSP Settings определенным образом, используя скрипт "elf2hex <myapp>.elf <start_addr> <end_addr> --width=<data_width> <hex_filename>.hex" получить .hex-файл из .elf-файла, в Qsys выставить инициализацию RAM своим сгенеренным .hex-ом, скомпилить, получить .sof-файл, и вроде как все. Сделал все как там сказано, НО НИОС не заработал, лампочки не мигают. <start_addr> и <end_addr> взял из Qsys, как begin и end для RAM-а. Если после всех этих манипуляций я пытаюсь компилить проект в NIOS II IDE, то вылезает ошибка типа "multiple target ..." в файле mem_init.mk. И тут я ваще ни.. не понимаю, что делать. Кто занимался такими вещами ПЛЗЗЗ подскажите, в чем может быть мой косяк? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
StewartLittle 41 5 июня, 2012 Опубликовано 5 июня, 2012 · Жалоба Сделал все как там сказано, НО НИОС не заработал, лампочки не мигают. <start_addr> и <end_addr> взял из Qsys, как begin и end для RAM-а. Это делается на совсем так. В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build. Там выбираете mem_init_generate и жамкаете кнопку "Build". Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе. После заливки вновь полученного sof'а проект должен сразу завестись. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Desh_ 0 6 июня, 2012 Опубликовано 6 июня, 2012 · Жалоба Это делается на совсем так. Там выбираете mem_init_generate и жамкаете кнопку "Build". Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе. После заливки вновь полученного sof'а проект должен сразу завестись. У меня в версии 9.1 такого пункта не было. Создал его вручную, в окне Create a new Make target в поле Target Name прописал mem_init, в поле Make Target прописал mem_init_generate. В поддиректории ..\mem_init создался файл .hex, но файла с расширением .qip нет. Подскажите, пожалуйста, в чем ошибка? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Копейкин 0 6 июня, 2012 Опубликовано 6 июня, 2012 · Жалоба В 9.1 этот файл .hex и нужно подставить для квартуса, вместо созданного ранее. И перекомпилировать проект. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
billidean 0 6 июня, 2012 Опубликовано 6 июня, 2012 · Жалоба Это делается на совсем так. В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build. Там выбираете mem_init_generate и жамкаете кнопку "Build". Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе. После заливки вновь полученного sof'а проект должен сразу завестись. Спасибо большое! Ваши рекомендации рабочие (а Альтеровские - нет :( ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FLTI 0 31 мая, 2014 Опубликовано 31 мая, 2014 · Жалоба Это делается на совсем так. В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build. Там выбираете mem_init_generate и жамкаете кнопку "Build". Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе. После заливки вновь полученного sof'а проект должен сразу завестись. Предыдущие свои вопросы удалил, наверное дальше сам разберусь. P.S. Да разобрался. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FLTI 0 1 июня, 2014 Опубликовано 1 июня, 2014 · Жалоба Мне в этой теме непонятно - насколько данный HEX-файл, описывающий программную часть проекта, является зависимым или независимым от аппаратной части всего проекта, ведь он получен в Эклипсе с использованием .sof конкретного проекта. Но при этом из этого проекта в BSP используется только .sopcinfo. Значит ли это, что я без проблем могу пользоваться данным HEX-файлом для любого проекта, в котором имеется та же самая программная часть при условии, что если я не буду менять QSYS-часть проекта ( в которой и находится On-chip Memory )? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
StewartLittle 41 2 июня, 2014 Опубликовано 2 июня, 2014 · Жалоба Мне в этой теме непонятно - насколько данный HEX-файл, описывающий программную часть проекта, является зависимым или независимым от аппаратной части всего проекта, ведь он получен в Эклипсе с использованием .sof конкретного проекта. Но при этом из этого проекта в BSP используется только .sopcinfo. В создании elf-файла (и, соответственно, hex-а) sof никоим образом не участвует. Информацию об аппаратном составе системы компилятор получает из sopcinfo (как справедливо отмечено). А sof предназначен только для конфигурации FPGA. Значит ли это, что я без проблем могу пользоваться данным HEX-файлом для любого проекта, в котором имеется та же самая программная часть при условии, что если я не буду менять QSYS-часть проекта ( в которой и находится On-chip Memory )?Что-то я не постиг глубину мысли. Если у Вас не изменяется ни программная, ни аппаратная части, то о каком "любом проекте" тут может идти речь??? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FLTI 0 2 июня, 2014 Опубликовано 2 июня, 2014 · Жалоба Что-то я не постиг глубину мысли. Если у Вас не изменяется ни программная, ни аппаратная части, то о каком "любом проекте" тут может идти речь??? Судя по названию .sopcinfo описывает только QSYS (SOPC) часть проекта где и находится NIOS, для программы которого получен .hex файл. Если программная часть не меняется, QSYS (SOPC) часть проекта тоже не меняется, а меняется только та часть проекта, которая не затрагивает QSYS (SOPC), то значит ли это что я могу использовать полученный .hex файл не меняя его, хотя сам проект в целом поменялся? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
StewartLittle 41 2 июня, 2014 Опубликовано 2 июня, 2014 · Жалоба Судя по названию .sopcinfo описывает только QSYS (SOPC) часть проекта где и находится NIOS, для программы которого получен .hex файл. Если программная часть не меняется, QSYS (SOPC) часть проекта тоже не меняется, а меняется только та часть проекта, которая не затрагивает QSYS (SOPC), то значит ли это что я могу использовать полученный .hex файл не меняя его, хотя сам проект в целом поменялся? Правильно ли я понимаю, что в Вашем квартусовском проекте есть система с ниосом, и кроме нее еще какие-то другие цифровые блоки? И Вас интересует, можн ли использовать имеющийся hex для ниосовской системы при внесении изменений в эти другие блоки? Если я правильно протелепатировал, то таки да - имеющийся hex использовать можно, т.к. ни состав, ни распределение адресного пространстав в ниосовской системе не изменилось. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
krux 8 2 июня, 2014 Опубликовано 2 июня, 2014 · Жалоба для корректной работы вашего hex он должен быть собран с соответствующим вашей системе BSP., полученным из sopcinfo. т.е. если вы пересобрали sof с добавлением каких-то ещё блоков, но при этом не переделывали qsys-компонент, то следовательно sopcinfo и BSP будут те же. И, соответственно, уже собранный до этого hex "сломаться" не может. Это если код программы в On-chip Memory. если есть EPCS Flash Controller то это отдельная история Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FLTI 0 2 июня, 2014 Опубликовано 2 июня, 2014 · Жалоба Правильно ли я понимаю, что в Вашем квартусовском проекте есть система с ниосом, и кроме нее еще какие-то другие цифровые блоки? И Вас интересует, можн ли использовать имеющийся hex для ниосовской системы при внесении изменений в эти другие блоки? Да, именно так. Если я правильно протелепатировал, то таки да - имеющийся hex использовать можно, т.к. ни состав, ни распределение адресного пространстав в ниосовской системе не изменилось. Большое спасибо! для корректной работы вашего hex он должен быть собран с соответствующим вашей системе BSP., полученным из sopcinfo. т.е. если вы пересобрали sof с добавлением каких-то ещё блоков, но при этом не переделывали qsys-компонент, то следовательно sopcinfo и BSP будут те же. И, соответственно, уже собранный до этого hex "сломаться" не может. Это если код программы в On-chip Memory. Да, код программы в On-chip Memory. Спасибо, я понял! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FLTI 0 27 февраля, 2015 Опубликовано 27 февраля, 2015 · Жалоба Это делается на совсем так. В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build. Там выбираете mem_init_generate и жамкаете кнопку "Build". Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе. После заливки вновь полученного sof'а проект должен сразу завестись. А если выполняемая программа хранилась бы не в OnChip Memory, а в EPCS, то приведённая Вами процедура остаётся такой же, только вектора NIOSа будут направлены не на OnChip Memory, а на EPCS Flash Controller? И ещё вопрос - в чём разница хранения выполняемой программы в OnChip Memory и в EPCS с точки зрения расходования блочной памяти ПЛИС ( M9K )? Ведь даже если выполняемую программу хранить в EPCS, то для непосредственного выполнения она всё равно будет загружаться в OnChip Memory и расход блочной памяти ПЛИС ( M9K ) в обоих случаях будет одинаковым? Если так, то как сделать, чтобы выполняемую программу хранить в EPCS и при этом не выделять OnChip Memory размером с эту программу? Другими словами, можно ли выполняемую программу хранить в EPCS и оттуда же её и запускать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 27 февраля, 2015 Опубликовано 27 февраля, 2015 · Жалоба почему обязательно в ончип? программу можно и в ДДР перетолкать, и работать оттуда. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FLTI 0 27 февраля, 2015 Опубликовано 27 февраля, 2015 · Жалоба почему обязательно в ончип? программу можно и в ДДР перетолкать, и работать оттуда. У меня нет на плате ДДР, поэтому такой вариант не рассматриваю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться