Блог

Главная - Вопросы по программированию - Как я могу обрабатывать предупреждения о несоответствии процессора, не отключая их или не включая пользовательские копии зависимостей?

Как я могу обрабатывать предупреждения о несоответствии процессора, не отключая их или не включая пользовательские копии зависимостей?

#c #pic #sdcc

#c #рис #sdcc

Вопрос:

У меня есть проект C для PIC, который я создаю с помощью SDCC 3.6.3 и gputils 1.5.0, оба из которых я создал из исходного кода.

При связывании моего проекта я получаю следующие сообщения об ошибках от gplink:

 warning: Processor mismatch in "streams.o".
warning: Processor mismatch in "mullong.o".
warning: Processor mismatch in "divulong.o".
warning: Processor mismatch in "gptrput1.o".
warning: Processor mismatch in "divuint.o".
warning: Processor mismatch in "gptrget1.o".
warning: Processor mismatch in "eeprom16_gptrget1_dispatch.o".
warning: Processor mismatch in "eeprom16_gptrput1_dispatch.o".
warning: Processor mismatch in "eeprom16_gptrput1.o".
warning: Processor mismatch in "eeprom16_gptrget1.o".
warning: Processor mismatch in "eeprom16_write.o".

Существует определенный флаг для отключения этих предупреждений (-w ), но мне не нравятся какие-либо предупреждения при сборке моих проектов. Некоторые поиски привели меня к короткому разговору 2007 года, в котором рассматривалась эта проблема: библиотеки, включенные в SDCC, по умолчанию будут созданы для PIC 18f452. В моем проекте используется 18f26k22, вызывающий эти предупреждения.

Приведенный выше разговор включал инструкции о том, как перестроить библиотеки pic16 для другой цели. Они устарели, но я понял это, прочитав сценарий настройки. Я выполнил эти шаги для перекомпиляции библиотек:

  1. Измените файл device/lib/pic16/configure . Обратите внимание, что вы также можете указать переменную среды ARCH в оболочке, как описано в приведенной выше ссылке. ( ARCH=18f26k22 make )

     # The default architecture can be selected at configure time by setting the
# environment variable ARCH to the desired device (18fxxx).
ARCH=${ARCH:-18f452}
  2. Запустите файл конфигурации, который вы только что изменили: ./configure
  3. make clean
  4. make
  5. Поднимитесь на уровень до каталога lib: cd ..
  6. Удалите старую сборку, если она присутствует: rm -rf build/pic16
  7. make

Возможно, вам потребуется повторить это для несвободного кода, если вы его используете. Он живет внутри device/non-free/lib/pic16 .

После того, как вы его создали, вы можете изменить параметры gplink, чтобы флаги -I указывали на каталоги сборки, в которых содержатся библиотеки, которые вы только что создали. Пример: -I/home/username/sdcc/device/lib/build/pic16 -I/home/username/sdcc/device/non-free/lib/build/pic16

К сожалению, gplink использует первую найденную библиотеку. Это означает, что вы не можете создавать библиотеки для каждого используемого вами pic, хранить их все по разным путям и иметь -I путь к каждому из них. gplink выберет первое и будет использовать его, даже если в других путях есть другие версии, которые не выдают ошибку несоответствия процессора.

Кроме того, запуск make install копирования библиотек, созданных для определенного чипа, в /usr/local/ sdcc не поможет, если вы разрабатываете для более чем одного чипа.

Есть ли более чистый способ справиться с этим, кроме как включить пользовательскую копию всего, что требуется моему проекту, или использовать флаг -w?

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

1. использование -W флага ничего НЕ исправляет, оно просто скрывает предупреждения. Почему библиотеки для разных процессоров находятся в одном каталоге? поместите их в разные каталоги и ссылайтесь на правильные каталоги при компиляции / связывании ваших проектов для конкретных процессоров PIC. -ИЛИ- дайте каждой библиотеке имя, включающее процессор, затем передайте операторам link правильное имя процессора, чтобы оно ссылалось на правильную библиотеку.

2. @user3629249 Я действительно не хочу скрывать предупреждения. Чтобы ответить на ваш вопрос, я не знаю наверняка. Вот как SDCC организует свои библиотеки. SDCC работает на многих различных типах оборудования, а не только на PICs. У них есть отдельный каталог для библиотек pic16 и pic14, что приятно. Может быть, они не хотели иметь отдельный каталог для всех разных изображений? Их много . Переименование возможно, но я действительно не хочу изменять все библиотеки каждый раз, когда выходит новая версия sdcc, в дополнение к их компиляции для каждого чипа.