Да, именно так
потому что текущее максимальное значение 255 (FF)- это разделитель пакета данных для разных кадров.
и чтобы не было всякого рода коллизий от получения двух разделителей (FF FF 00 00 00 AA AA AA ...), лучше убавить до 254 (FF FE 00 00 00 AA AA AA ...)
Может быть и будет работать со значением 255, можно например на первое время оставить 255, потестировать, а там уже принять окончательное решение.
Сомневаюсь что в ближайшее время кто-нибудь себе сделает эмбилайт на 255 зон. Это какой же телек надо иметь?
Если 32зоны на метр, 255зон, получаем периметр телека 8 метров
считаем, считаем, считаем
Получаем телек диагональю чуть меньше 3метров - 116дюймов
Чтоб я так жил
Но если использовать проектор ...
Другое ограничение, но я этот момент еще опять же не исследовал, - это размер оперативной памяти в контроллере.
Используемая на текущий момент библиотека создает в памяти массив размером количество_зон*3 байт.
Т.е. для 255 зон надо чтобы в ОЗУ контроллера было место для массива как минимум 765байт.
В АТМеге 328 и покруче, в которых 2048 байт оперативки, наверное найдется место, а вот в АТМеге 168 оперативки всего 1024 байт, часть из которой будет тратится на рабочие переменные. Тонкости использования оперативки надо спрашивать у Chipa - гуру по микроконтроллерам
Опять же, у кого такой телек или проектор и кто купит такую длиннющую ленточку, наверное найдет чуть чуть деньжат и на контроллер чуть покруче чем АТМега 168![]()