createChar под лупой: типы массивов и слот-хамелеон

Прибор включается полторы секунды: экран показывает название прошивки и колонку, заполняющуюся снизу вверх. Восемь стадий заливки — и восемь слотов CGRAM, из которых шесть уже заняты значками интерфейса: градус, стрелка меню, огонёк нагрева. Моё первое решение — по слоту на каждый кадр колонки — проработало до первого же запуска: createChar в setup перезаписал байты чужих слотов, и вместо градуса на экране красовалась половинка колонки. Слоты я раздал дважды, а раскладку не сохранил — классический промах после урока про свои символы и значок градуса, где бюджет из восьми ячеек только начинался.

Ответ прячется в слове оперативная. CGRAM — не альбом картинок, а шестьдесят четыре байта памяти, которые вы перезаливаете когда хотите; слот — ячейка, а не портрет. У колокольчика из урока про байтовые иконки два кадра жили в двух слотах, и это честная цена за мгновенное переключение. Восемь стадий колонки в восемь слотов вместе с интерфейсом не влезут, зато в один слот влезают по очереди: одна перезаливка — девять байтов по шине, порядка миллисекунды при 100 кГц.

Разбор начну с синтаксиса: половина затыков с глифами случается на этапе объявления массива, до всякого экрана. Дальше — битовая бухгалтерия сетки 5×8, приём слот-хамелеон на живом сплэше и граница применимости: когда перезаливать слот выгодно, а когда честнее завести второй.

Сигнатура библиотеки жёсткая: createChar(uint8_t nomer, uint8_t massiv[]). Второй аргумент — указатель на массив байтов, и компилятор следит за типом не хуже контроллера. Массив int, объявленный по привычке, код не пройдёт: указатель на двухбайтовые ячейки не превращается в указатель на байт молча, IDE выпишет cannot convert int* to uint8_t* ещё до прошивки. Чинится одним словом — byte stolb[8] вместо int stolb[8]. Значения от этого не меняются, меняется честность описания: каждый байт здесь — восемь точек, а не число. Про массивы байтов вообще я писал в уроке про массивы и журналы, там же — про то, как их держать в порядке.

С char история тоньше. По битам char и byte — одно и то же восемь раз, и после явного приведения слот получит ровно те же биты. Но байты выше 127 в знаковом типе читаются как минус: сплошная колонка 0b11111111 превращается в -1. Я потратил на это вечер, отлаживая рамку панели: монитор порта сыпал отрицательными числами, хотя экран рисовал правильные столбики. Вывод тот же, что и с int: глифы — это byte, без вариантов.

Отдельная ловушка — PROGMEM. Соблазн понятен: на проекте с жирным Serial-журналом экономить даже шестьдесят четыре байта — святое дело. Но createChar читает указатель в RAM, а PROGMEM-массив лежит во flash, и без memcpy_P во временный буфер в слот уедет мусор из случайных байтов — значок соберётся, но не тот, что вы рисовали. Контекст для масштаба: вся SRAM у ATmega328P — два килобайта, и CGRAM-бюджет в 64 байта — это три процента всей памяти платы. Цена одной длинной строки журнала. Я в итоге перестал заморачиваться: держу глифы в обычных массивах, а если проект упирается в RAM всерьёз, копирую кадр в буфер перед заливкой — две строки кода.

И последнее по типам: размер массива. Восемь байтов — обязательная норма; библиотека скопирует в слот ровно восемь штук, лишние игнорирует, недостающие прочтёт из соседней памяти. Массив из семи байтов собирается без предупреждения и рисует мусор в нижней строке — поэтому я ставлю индекс [8] в объявление машинально, как скобки.

Байт — восемь бит, глиф 5×8 съедает пять. Живут они в младшей половине: бит 4 — левая колонка, бит 0 — правая, а биты 5, 6 и 7 контроллер читает и молча игнорирует — механика такого общения разобрана в уроке про устройство HD44780 и продолжается в разборе команд без библиотеки. Я рисовал первый значок на сетке восемь на восемь, честно заполняя правый край, и не мог понять, почему у глифа обрублена сторона. Проверка занимает минуту: залейте байт 0b11100000 — экран останется пустым; байт 0b00010000 — даст один столбик слева.

Отсюда привычка, которую я тащу через все проекты: нижнюю строку значка в текстовой строке держать пустой. Курсор ввода рисуется в той же строке, что и символ, и глиф без воздуха снизу слипается с подчёркиванием. У клеток бара из урока про прогресс рамка снизу закрывает вопрос; у одинокой колонки загрузки — я просто оставляю восьмую строку свободной, если значок стоит рядом с текстом.

Битовая запись 0b экономит не память, а минуты: кривой значок ловится на бумажке до прошивки, потому что нули и единицы видны глазами. Шестнадцатеричный 0x04 — язык даташита, удобный для дампы ROM; десятичная четвёрка — язык арифметики стадий. А вот 00100 без префикса — ловушка языка C: ведущий ноль означает восьмеричную запись, и в слот уедет 64, не 4. Я наступил на это, копируя раскладку из статьи, где биты печатались строкой без 0b, — потом час искал пропавшую колонку, пока не напечатал массив в Serial и не увидел чужие числа.

Дешёвая страховка — дамп перед заливкой: цикл из восьми строк, каждая печатает байт и его 0b-версию через Serial. Пять секунд на написание, полминуты на прогон — и раскладка глифов подтверждена не глазами на экране, а числами в мониторе. К строкам с ведущими нулями в статьях я с тех пор отношусь как к чужому коду без тестов.

Механика стадий проще, чем кажется. Колонка стоит в средней колонке глифа — это бит 2, байт 0b00100. Стадия k должна залить k строк снизу: строка с номером r закрашена, если r >= 8 - k. Ни массивов на восемь кадров, ни отдельных значений — один буфер из восьми байтов, который перед каждой перезаливкой пересчитывается циклом из восьми шагов. Заодно исчезает соблазн хранить восемь одинаковых почти массивов: код короткий, и ошибиться в одной строке из восьми труднее, чем в восьми строках.

Цена вопроса — девять байтов по шине за перезаливку: номер слота плюс восемь байтов раскладки. При 100 кГц это порядка миллисекунды; сплэш с кадром раз в 100-300 миллисекунд тратит на глиф меньше процента времени. Альтернатива — держать все кадры в слотах сразу — стоит восемь ячеек бюджета и оправдана только для коротких циклов из двух-трёх кадров, где переключение должно быть мгновенным и бесплатным. Рамка применимости, на которой я настаиваю: перезаливка — для редких кадров (меньше десятка в секунду); живой анимации на 20-30 кадрах в секунду через createChar не делайте — упрётесь в шину раньше, чем в глаза зрителя.

Второй бонус перезаписи — смена глифа не трогает DDRAM: ячейка экрана, где напечатан слот, остаётся на месте и обновляет содержимое сама. Не надо ни setCursor, ни повторной печати — экран живёт своей жизнью, а буфер меняется под ним. Это дешевле и по шине, и по коду.