Вообще-то, это (массив указателей) я Вам подсказал ещё в самом первом ответе в теме (№2). Не читатель?
Доходило долго 
А вы имеете представление, что это вообще обозначает? Или тоже реализацию ИИ отдадите? Просто так обрадовались, что ваше решение имеет название, как будто бы уже решение написано.
нулями, вестимо. а в примере у ТСа - ноль используется как валидный элемент. Не заметил, как точка с запятой прокралась. Накопипастил, судя по всему. Бывает.
ну пушто это не код для компиляции. это код для иллюстрации, который конечно же никто компилировать и не будет в здравом уме, ну разве что кроме буквоедов разных.
… и вот еще что, господа искатели точек с запятыми.. Вы не подумали о том, что делать массив указателей - это сжирать минимум два байта (16 бит на дрес у вас там, насколько я понимаю). У автора массив - из байтиков. Правильным решением будет определить средний и максимальные размеры массивов, и если они, как в примере автора, не превышают 4 байт, то выгоднее будет нарастить все массивы до 4-х элементов а не городить еще и массив указателей. Да и работать будет чуть быстрее :).
А так чем плохо?
uint8_t xArray_Hour_00[] = PROGMEM { 44, 43, 42, 41 };
uint8_t xArray_Hour_01[] = PROGMEM { 0, 1, 2, 3 };
uint8_t xArray_Hour_02[] = PROGMEM { 40, 39, 38 };
uint8_t xArray_Hour_03[] = PROGMEM { 54, 55, 56 };
uint8_t xArray_Hour_04[] = PROGMEM { 31, 30, 29, 28, 27, 26 };
uint8_t xArray_Hour_05[] = PROGMEM { 16, 17, 18, 19 };
uint8_t xArray_Hour_06[] = PROGMEM { 8, 7, 6, 5, 4 };
uint8_t xArray_Hour_07[] = PROGMEM { 22, 23, 24, 25 };
uint8_t xArray_Hour_08[] = PROGMEM { 20, 21, 22, 23, 24, 25 };
uint8_t xArray_Hour_09[] = PROGMEM { 48, 49, 50, 51, 52, 53 };
uint8_t xArray_Hour_10[] = PROGMEM { 37, 36, 35, 34, 33, 32 };
uint8_t xArray_Hour_11[] = PROGMEM { 0, 1, 2, 3, 57, 58, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_12[] = PROGMEM { 47, 46, 45, 57, 58, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_13[] = PROGMEM { 54, 55, 56, 57, 58, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_14[] = PROGMEM { 26, 27, 28, 29, 30, 57, 58, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_15[] = PROGMEM { 16, 17, 18, 57, 58, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_16[] = PROGMEM { 8, 7, 6, 5, 57, 58, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_17[] = PROGMEM { 22, 23, 24, 57, 58, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_18[] = PROGMEM { 20, 21, 22, 23, 24, 57, 58, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_19[] = PROGMEM { 48, 49, 50, 51, 52, 57, 58, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_20[] = PROGMEM { 40, 39, 38, 59, 60, 61, 62, 63 };
uint8_t xArray_Hour_21[] = PROGMEM { 40, 39, 38, 59, 60, 61, 62, 63, 79, 78, 77, 76 };
uint8_t xArray_Hour_22[] = PROGMEM { 40, 39, 38, 59, 60, 61, 62, 63, 75, 74, 73 };
uint8_t xArray_Hour_23[] = PROGMEM { 40, 39, 38, 59, 60, 61, 62, 63, 72, 71, 70 };
/* Массив указателей */
uint8_t* pArray_Hours[] = { xArray_Hour_00, xArray_Hour_01, xArray_Hour_02, xArray_Hour_03, xArray_Hour_04, xArray_Hour_05,
xArray_Hour_06, xArray_Hour_07, xArray_Hour_08, xArray_Hour_09, xArray_Hour_10, xArray_Hour_11,
xArray_Hour_12, xArray_Hour_13, xArray_Hour_14, xArray_Hour_15, xArray_Hour_16, xArray_Hour_17,
xArray_Hour_18, xArray_Hour_19, xArray_Hour_20, xArray_Hour_21, xArray_Hour_22, xArray_Hour_23 };
/* Массив размеров */
uint8_t xArray_Hours_Lenght[24] = { sizeof(xArray_Hour_00), sizeof(xArray_Hour_01), sizeof(xArray_Hour_02),sizeof(xArray_Hour_03),
sizeof(xArray_Hour_04), sizeof(xArray_Hour_05), sizeof(xArray_Hour_06),sizeof(xArray_Hour_07),
sizeof(xArray_Hour_08), sizeof(xArray_Hour_09), sizeof(xArray_Hour_10),sizeof(xArray_Hour_11),
sizeof(xArray_Hour_12), sizeof(xArray_Hour_13), sizeof(xArray_Hour_14),sizeof(xArray_Hour_15),
sizeof(xArray_Hour_16), sizeof(xArray_Hour_17), sizeof(xArray_Hour_18),sizeof(xArray_Hour_19),
sizeof(xArray_Hour_20), sizeof(xArray_Hour_21), sizeof(xArray_Hour_22),sizeof(xArray_Hour_23) };
нам-то зачем об этом думать? Это автор должен решать, что как ему лучше сделать. И тот и тот вариант имеют право на жизнь.
опять подставляетесь?
Массив с размерами разве в PROGMEM не перемещается?
И я могу предположить, что вам нигде в алгоритмах именно количество элементов для каждого часа не нужно. Все можно заменить на граничный элемент - перебирать от начала и до него.
OK, принято. Массив с размерами уйдет в PROGMEM
В алгоритмах количество элементов для каждого часа необходимо.
С граничным элементом думал - не получится. У меня матрица WS2812 16x16. 256 лампочек, номера от 0 до 255
как раз в uint8_t помещаются
Хм… не могли бы подробнее рассказать о проекте ? Зачем нужно зажигать десяток пикселей на большой матрице в зависимости от часа?
Не секрет. Часы из слов.
Идея здесь
…иии алгоритм которому нужно количество элементов для такой задачи, где нельзя обойтись без размера массива?
Кстати, если уж делать оптимально под вашу матрицу, то каждая минута в сутках - это 32 байта фиксировано. Каждый бит отвечает за один светодиод. Определяются два массива коротких размеров для часов и для минут, объединяются побитово по или для получения 32 байт на карту подсветки. Объяснять подробно не буду - вы или способны это осилить, или нет. Третьего не дано (ибо если бы знали это технику, и вопросов бы не было).
Но это прием чисто для маленьких МК, где память важна. Когда вся программа - это только часы и она влезает в память, то такое - это просто уж выпендреж.
Подумали. Почитайте самый первый ответ в теме и посмотрите какие вопросы были заданы ТС. То, что он на них не ответил, – сам себе Буратино.
Жесть! Ну, собственно лицевая панель там именно из жести и сделана
ТС, дорогой! Я позволю себе несколько замечаний.
- Твое решение из последнего поста вполне нормальное. Для пет-проекта важно то, что оно работает и все хейтеры могут спокойно курить в сторонке.
- С профессиональной точки зрение у него есть некоторые недостатки, но есть и достоинства.
2.1. первое достоинство - простота. Ты получил то, на что настроен твой алгоритм.
2.2. часть со строки 26 (массив указателей) уже не зависит от данных. Следовательно данные можно менять не трогая отлаженный код. - но есть и недостатки.
3.1. основной недостаток в том, что такое трудно сопровождать. Это Главный. Можно сделать комментарии к магическим числам, чтобы через год-два вспомнить о том, что ты хотел ими сказать.
3.2. второй недостаток называется “из пушки по воробьям”. То есть излишняя экономия памяти. Размер твоего массива настолько мал, что можно забить как угодно, не ограничивая себя. У нормального контроллера хватит ресурсов. Очень плохой стиль программирования - экономить ресурсы без нужды. Это не олимпиада по программированию и не задача на экзамене. Экономить ресурсы микроконтроллера нужно исключительно тогда, когда их не хватает и нет возможности в ТЗ Проекта заменить МК на другой. Жалобы в интете на Виндоус, который “жрёт все больше и больше” написаны дилетантами. Любая экономия ресурсов происходит или за счет скорости или за счет рабочего времени программиста и саппорта. МК стоят очень дешево. Кроме того нет того процесса, в пользу которого ты экономишь. У тебя весь камень для одной задачи. Сэкономленную память на привозе не продашь. - Я бы выбрал путь задавать картинки часа просто битмапами, с указанием в комментарии инструмента на ПК, которым битмап создан. 256 LEDs по 24 бита это 768 байт, на 24 часа дают 18 КилоБайт, полная фигня даже для AVR с его 30КБ флеша. А если взять МК из этого, 21 века, то вообще не о чем говорить.
В релизной сборке вроде не гарантируется заполнение нулями неинициализированных значений, не? ХЗ что там у МК после перезагрузки, может он сам себе обнуляет, а вот в больших компьютерах полнейший мусор.
Сдается мне, не от размера компа это зависит.
а если так сделать Serial.println(xArray_Hour_00_SIZE); какую цифру покажет ?