Проблема с ASCII в STM32CubeIDE

Добрый всем день уважаемые программисты инженеры. Столкнулся с не понятной проблемой. При попытки откомпилировать проект вылазит предупреждения по переменной char strr = 'Щ'; но если эту переменную поместить в отдельный хидер то всё компелируется без предупреждения и символ 'Щ' как положено имеет код в ASCII 217 и правильно отображается на дисплее да и любой другой символ отображается из хидера как положено. В самом STM32CubeIDE везде установил кодировку CP1251 да и если я перевожу дисплей в режим знакогенератора то правильная передача символов именно только кириллицы возможно только из хидера НО английские буквы проходят нормально как из хидера так и из листа main.c.

../Core/Src/main.c:79:13: warning: multi-character character constant [-Wmultichar] 79 | char strr = 'Р В©'; | ^~~~ ../Core/Src/main.c:79:13: warning: unsigned conversion from 'int' to 'char' changes value from '53417' to '169' [-Woverflow]

0

там где ругается, у вас файл кода в utf-8. сконвертируйте его в cp-1251

0

Сообщение от Alex1126 там где ругается, у вас файл кода в utf-8. сконвертируйте его в cp-1251

можно файл main.c конвертировать? У него максимум есть Properties и всё, и то в настройках этого main.c стоит CP1251.

0

Сообщение от BigSten У него максимум есть Properties и всё и то в настройках этого main.c стоит CP1251.

а по факту там какая кодировка?

0

Сообщение от Alex1126 а по факту там какая кодировка?

0

не. Если файл открыть блокнотом, нотепадом или или чем нить

1

Alex1126, ха и то верно, надо было оказывается всё таки выбрать Other CP1251 выходит файл main.c нужно отдельно настраивать под кодировку. Я то просто в свойствах самого проекта настраивал и думал что все его объекты унаследуют настройки но видать не все.

0

Учитесь работать с юникодом. Файлы в однобайтовой это откладывание проблемы на будущее.

1

Сообщение от Rius Файлы в однобайтовой это откладывание проблемы на будущее.

Именно в МК это иногда оправдано. Нарисовать знакогенератор на 256 идущих подряд символов все-таки проще, чем на 180, но с дырами между ними. Плюс конвертор сначала из юникода в (скорее всего) utf-16, а потом в индекс массива.
А вообще, учитывая, что иногда применяется даже HD44780, у которого своя, извращенная кодировка... cp1251 еще не худший выбор.

0

Иногда - да.

И до некоторых пор это проще.
Но потом ты начинаешь откладывать варианты, которые не вписываются в эту простоту.
Потом начинаешь их избегать.
И вот ты уже ходишь по форумам и хаешь не осиленный юникод в каждой теме, на который незаметно перешёл весь остальной мир, и ещё учишь этому детей.

Выбор плох тем, что среды разработки (IDE) и средства совместной разработки (типа Azure) уже юникодовые и без танцев с бубном показывают однобайтовые тексты крякозябрами.

Можно сразу строки в utf-16 держать, там есть строковые литералы u"str" ещё со времён C++11. Ещё проще будет конвертировать.

Смысл в том, чтобы читаемый не специально настроенными средствами (кодировку редактор может определить и сам по BOM) текст показывал человеку то, что будет показано на экране устройства. Даже если в тексте и в бинарной прошивке кодировки разные в целях экономии памяти или извращённой кодировки драйвера.

0

Сообщение от Rius Выбор плох тем, что среды разработки (IDE) и средства совместной разработки (типа Azure) уже юникодовые и без танцев с бубном показывают однобайтовые тексты крякозябрами.

Совсем по фен-шую было бы вынести все ресурсы в отдельный файл. А с ним уже проще. Можно хоть при компиляции конвертировать из файла с нормальной кодировкой.
Но костыли с однобайтными кодировками как раз и делаются чтобы пусть коряво, но с минимумом усилий.

Сообщение от Rius Можно сразу строки в utf-16 держать

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

Сообщение от Rius u"str" ещё со времён

Если бы мы рассуждали о программировании для ПК, я бы, как обычно, поинтересовался какой формат для printf можно использовать для utf-16. Но для МК это не актуально: так и так руками писать. Для любой кодировки.

0

А смысл? В редакторе так и так пришлось бы менять кодировку.

В виде u"str" сам файл мог бы быть в utf-8, а бинарное представление строки получалось уже в utf-16, которое просто (постоянный размер символа) constexpr функциями конвертить в win1251. Пропуская код символа юникода через таблицу соответствия для получения во время компиляции уже кода однобайтовой кодировки. Даже пользовательской.
В случае однобайтовой символов не много, весь зоопарк не нужен, можно и вручную забить таблицу.

И что получается: мы пишем u"str" в коде, сам код в utf-8 и без крякозябр отображается на веб-сервере и в редакторах, а в прошивке уже закодены байтики в кодировке win-1251.

0