[Sergey_Aleksandrovi4 0]

Здравствуйте.

Синопсис. Потребовалось поиграться с кодировками текста в исходниках проекта. В gcc это делается ключами компилятора 

-finput-charset=UTF-8

-fexec-charset=cp1251

За преобразование кодировок отвечает утилита iconv из библиотеки libiconv. Она отсутствует в стандартной сборке "из коробки" Atmel Studio 7, хотя сам компилятор эти ключи понимает и пытается обрабатывать.
 

Quote

no iconv implementation, cannot convert from UTF-8 to cp125

Скачал исходники libiconv https://www.gnu.org/software/libiconv/#downloading, собрал под Windows с помощью mingw. На выходе получился исполняемый iconv.exe и его библиотека libiconv-2.dll. Само по себе приложение запускается.

Скопировал оба файла в директорию тулчейна \Atmel Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin  т.е. туда, где лежат все исполняемые exe-файлы: avr-gcc.exe, avr-size.exe и др.

Проблема. Не знаю как сообщить студии что у неё теперь есть недостающая библиотека libiconv.

• Нашёл в make-файле упоминания exe-файлов, попробовал вручную прописать путь к iconv.exe. Не помогло, студия сообщает об его отсутствии. Возможно надо было какие-то ключи ещё указать.

Quote

 

........

$(OUTPUT_FILE_PATH): $(OBJS) $(USER_OBJS) $(OUTPUT_FILE_DEP) $(LIB_DEP) $(LINKER_SCRIPT_DEP)
    @echo Building target: $@
    @echo Invoking: AVR/GNU Linker : 5.4.0
    $(QUOTE)C:\Programs\Atmel Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe$(QUOTE) -o$(OUTPUT_FILE_PATH_AS_ARGS) $(OBJS_AS_ARGS) $(USER_OBJS) $(LIBS) -Wl,-Map="TEST_Project.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=atxmega256a3u -B "C:\Programs\Atmel Studio 7\7.0\Packs\atmel\XMEGAA_DFP\1.1.68\gcc\dev\atxmega256a3u" -Wl,--relax  
    @echo Finished building target: $@
    "C:\Programs\Atmel Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "TEST_Project.elf" "TEST_Project.hex"
    "C:\Programs\Atmel Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "TEST_Project.elf" "TEST_Project.eep" || exit 0
    "C:\Programs\Atmel Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "TEST_Project.elf" > "TEST_Project.lss"
    "C:\Programs\Atmel Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "TEST_Project.elf" "TEST_Project.srec"
    "C:\Programs\Atmel Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\iconv.exe.exe"
    "C:\Programs\Atmel Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "TEST_Project.elf"

........

 

• Перерыл все возможные настройки среды и проекта, не нашёл где бы можно было путь к утилите прописать.
• Изучил внутренности SW4STM32 - System Workbench for STM32 (из того-же gcc-зоопарка) чтобы сделать по аналогии, он с ключами -finput и -fexec проект собирает без ругани. Не нашёл в недрах директорий ни exe, ни dll относящихся к libiconv.

Вопрос. Кто-нибудь имеет опыт или знает, как к Atmel Studio подключать дополнительные утилиты? По правильному пути я иду или для поставленной задачи надо весь тулчейн пересобирать-перекомпилировать?

[xvr 12]

Во первых почему у вас в iconv.exe.exe с двумя exe?

Во вторых туда, куда вы его прописали, прописывать не стоит. Его должен вызывать сам gcc при работе. Так, как написано (после исправления .exe.exe) будет просто вызываться iconv без параметров

В третьих попробуйте положить ваш iconv.exe (вместе с dll) в каталог, перечисленный в переменной окружения PATH. Возможно заработает

 

[Sergey_Aleksandrovi4 0]

@xvr, спасибо что откликнулись. exe.exe - глаз замылился под вечер. Впрочем и после правок не помогло, удалил этот вызов из makefile.

Директория в которую я размещал .exe  и .dll как раз и является директорией Си-тулчейна. Или Вы про тот PATH, который в настройках "переменных среды" Windows?

[xvr 12]

14 hours ago, Sergey_Aleksandrovi4 said:

Или Вы про тот PATH, который в настройках "переменных среды" Windows?

Он самый

 

[Sergey_Aleksandrovi4 0]

Отпишусь, что ли по результатам: безуспешно. В Path никаких упоминаний Atmel Studio не было. Нашёл топик в котором человеку так же понадобился libiconv в составе avr-gcc http://we.easyelectronics.ru/JustMoose/pro-gcc-i-kodirovki.html. Он, в свою очередь, нашёл  собранный под windows avr-gcc с поддержкой libiconv. Правда, avr-gcc там старый: 4.9.2 против последнего 5.4.0. https://andybrown.me.uk/2015/03/08/avr-gcc-492/ Установил ради интереса - преобразование кодировок работает.

Изучил в hex-редакторе тело файлов avr-gcc.exe из состава Atmel Studio и из сторонней сборки. Штатный из состава студии про библиотеку libiconv-2.dll даже не знает в отличие от стороннего. При этом строки с ключами -finput-charset= и -fexec-charset= в нём присутствуют. Не удивительно, что у меня ничего не вышло при подсовывании dll в директорию тулчейна. Предположу, что в коде компилятора при обнаружении ключа запроса преобразования кодировки срабатывает "заглушка", она останавливает сборку с ошибкой. 

Затея с самого начала была обречена на провал. Придётся что-то придумывать с декодированием текста в UTF-8 силами самого МК. xvr, спасибо за содействие.

[Darth Vader 0]

19.11.2021 в 22:32, Sergey_Aleksandrovi4 сказал:

Придётся что-то придумывать с декодированием текста в UTF-8 силами самого МК

Под текстом понимается весь текст исходника? Содержимое всего текстового файла? Если да, то попробуйте конвертировать редактором notepad++ В нем есть встроенный конвертер кодировки текста.

[Sergey_Aleksandrovi4 0]

Нет, только строковые литералы (строковые константы), текст исходников по-прежнему должен быть в ASCII. Изначально была идея прогнать текст через внешние редакторы чтобы получить 8-битные символы, но "крякозябры" в исходниках не допустимы.

[xvr 12]

1 hour ago, Sergey_Aleksandrovi4 said:

Изначально была идея прогнать текст через внешние редакторы чтобы получить 8-битные символы, но "крякозябры" в исходниках не допустимы.

А текстовые литералы в виде "\211\233\148" допустимы?

 

[Sergey_Aleksandrovi4 0]

Тоже малоприменимо, спасибо за совет. У меня в устройстве GUI в которое потребовалось добавить поддержку нескольких языков. Хочется видеть в исходниках именно текст в том виде, в котором он выводится на экран. Если строковые константы будут записаны "крякозябрами" или через подобные литералы, то управлять и модифицировать проект в дальнейшем будет проблематично. Разве что оставлять после каждой строки комментарий в человекочитаемом виде. Но это на потом, если с юникодом не получится.

[xvr 12]

Помню когда то очень давно у меня была такая же задача. Я вставил скрипт, который перекодировал текстовые литералы в сорцах прямо в процесс компиляции  - в makefile. Он перед запуском сишного компилятора вызывал перекодировщик который делал временный файл, который и подавался компилятору. Потом в сообщениях об ошибках от компилятора заменял все вхождения имени временного файла на оригинальный (что бы поиск ошибок в IDE не ломался)

 

Хотя в вашем случае наверное будет проще самому собрать тулчейн с включенной поддержкой libiconv и подсунуть его в AS

 

[Sergey_Aleksandrovi4 0]

On 12/3/2021 at 12:48 PM, xvr said:

Хотя в вашем случае наверное будет проще самому собрать тулчейн с включенной поддержкой libiconv

Вы слишком высоко оценили мои способности :D Линуксовый мир мне чужд, на банальную сборку одного лишь libiconv по инструкции ушла большая часть рабочего дня. И дело ещё в другом. Все эти исходники должны компилироваться на "ванильных" сборках Atmel Studio. Т.е. если разработчик после меня захочет что-то поправить в коде, то он просто скачает и установит дистрибутив студии с сайта и откроет в ней мой проект, а не будет рвать на себе волосы в надежде собрать рабочий тулчейн из исходников. Было бы дело в одной лишь dll библиотеке, её можно бы было положить в репозиторий с проектом и написать readme как и куда её подключать. По этой же причине отказался от идеи что-либо править руками в make-файле, пусть автоматически генерируется по настройкам из GUI студии.

Поэтому буду писать поддержку юникода. По флэш-памяти у меня, грубо говоря, ограничений нет.