F("") и русский язык, как сэкономить память?

Хранение строк в PROGMEM
Строка в виде обычного текста:

const char message1 PROGMEM = “Привет”;

В этом случае компилятор будет хранить каждый символ строки в кодировке UTF-8 (если вы используете стандартный Arduino IDE), что может занять больше места, так как каждый русский символ может занимать 2 байта (в UTF-8).
Строка с использованием escape-последовательностей:

const char message1 PROGMEM = “\317\360\350\342\345\362”; // “Привет”

Здесь вы явно указываете кодировку Windows-1251, и каждый символ будет занимать 1 байт. Таким образом, эта запись будет более компактной.

Объем памяти:
Если вы используете обычную строку “Привет” в кодировке UTF-8, то она может занять 12 байт (6 символов по 2 байта).
Если вы используете escape-последовательности в кодировке Windows-1251, то строка займет 6 байт (6 символов по 1 байту).

такое ощущения что в закрытую дверь стучусь))) вот еще добавлю, библиотеку вроде можно полностью выпилить… а если не помог и ладно…

через Escape последовательности не читаемо потом, да и кучу текста проконвертить…Кстати то, что цифери в ESC-посл это 8-ричное для меня было новостью. Можно просто в HEX коды писать типа \0xE0 Можно мини-прогу написать вцелом для конвертации…

Чтобы изобретать собственную кодировку и с ней работать, у ТС явно недостаточно квалификации.
А при недостатке квалификации он постоянно будет наступать на грабли.
Поэтому намного лучше в его случае пользоваться одной из стандартных кодировок.
То есть подсовывать компилятору исходник в стандартной однобайтовой кодировке.
А раз так, остается единственная проблема: Arduino IDE работает в utf-8, следовательно, непосредственно можно работать либо с кодами символов (что неудобно), либо как-то перенастраивать IDE, чтобы прямо на экране видеть нужный текст.
Это можно сделать, минимум, двумя способами:

  1. Между редактором и компилятором добавить препроцессор-перекодировщик (например, из utf-8 в 1251).
  2. Заставить сам редактор работать с 1251.

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

А адаптировать библиотеку под эту “стандартную однобайтовую кодировку” у него хватит квалификации? Ну, тогда, не вопрос.

Да, и Вы опоздали со мною это обсуждать, я уже ушёл из темы, так что мне без разницы как именно ТС решит эту проблему.

нашел компромис - т.к. в чарсете кодировка Win1251 (правда с вырезаным куском посередине на 65 символов) - убрал перекодирование из UTF-8 и добавил условие пропуска того вырезаного куска (все в функции getFont(uint8_t font, uint8_t row)). И в #define`ах определил строки в виде \xкодсимволаWin1251 с коментами в виде читаемого вида.
Всем спасибо, памяти стало побольше

1 лайк

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